Number porting: the part that can stall the entire cutover
Porting existing phone numbers from a legacy carrier to a new platform’s carrier relationships is frequently the longest lead-time item in a migration, not the shortest. Port timelines vary by number type, carrier, and country, and a botched port can mean dropped inbound calls on cutover day. Start the port process before any other migration work, confirm a specific port date with the losing and gaining carriers in writing, and plan a fallback routing path in case the port slips.
Call flow parity: replicating what the old system actually did, not what it was supposed to do
Legacy IVR and routing logic accumulates undocumented exceptions over years — a specific queue that skips the after-hours message, a routing rule added for one client that nobody remembers why. Before rebuilding call flows in a new platform, audit the live system’s actual behavior (not just its design documentation) across a full business cycle, including holidays and after-hours paths, so the new flows are not missing logic nobody thought to write down.
Agent retraining: the softphone and workflow changes that erode adoption if rushed
A cloud contact center changes the physical and software interface agents use daily — desk phone to softphone, different transfer and hold mechanics, new wrap-up and disposition screens. Underestimating retraining time is one of the most common causes of a rocky go-live: plan hands-on practice time in a sandbox environment before cutover, not just a walkthrough deck, and identify which agent workflows (warm transfer, conference, supervisor escalation) need the most repetition.
Historical data: what carries over and what does not
Call recordings, historical CDRs, IVR analytics, and agent performance history frequently do not migrate automatically between platforms — confirm early whether the legacy system supports a bulk export in a usable format, and whether the destination platform can ingest it or only start a fresh historical record from cutover day. If a compliance or dispute-resolution requirement depends on retaining historical recordings for a defined period, plan to keep the legacy system’s archive accessible (even if read-only) rather than assuming it transfers.
Integration cutover: CRM, ticketing, and reporting connections rarely move cleanly in one step
Screen-pop integrations, click-to-dial, CRM activity logging, and reporting exports are usually built against the legacy platform’s specific API or connector — none of that carries over automatically to a new platform, even one that supports the same downstream CRM. Inventory every integration touching the current telephony system before scoping the migration, not after, since integration rebuild work is frequently the most underestimated line item in a migration timeline.
Where deployment model becomes relevant
None of the five risk areas above are specific to any one vendor — they apply to a PBX-to-cloud migration regardless of destination platform. Where deployment model does matter is what happens after cutover: a platform offered only as cloud-only SaaS locks the compliance boundary to a third-party-operated environment permanently, while a platform built for pluggable deployment — Voz360 runs identically as managed SaaS or private cloud, on the same codebase and tenant-isolation architecture — lets a team choose (or later change) where that boundary sits without a second migration.
Can the vendor tell you — in one sentence — which of their AI capabilities are rule-based, which are generative, and which are still roadmap?