Migrating to Cloud Voice: A UCaaS Migration Playbook

The PBX is not the risk — the cutover is

Most organizations replacing an aging on-premises PBX assume the hard part is choosing a platform. It isn't. The platforms are mature and largely interchangeable at the feature level. The projects that go badly go badly at the seams: a number port that slips, an emergency call that routes to the wrong address, a voice path that sounds fine at 9 a.m. and turns to gravel at 2 p.m. when the office fills up. Unified communications as a service (UCaaS) moves your dial tone into someone else's data center, but it does not move away the physics of real-time media or the regulatory weight of a 911 call.

This is the sequence we run for clients retiring on-prem voice. It treats the migration as a network and identity project that happens to involve phones — not a phone project that happens to touch the network.

Assess the network before you assess the platform

Voice is unforgiving in a way that email and file sync are not. A packet that arrives 200 milliseconds late is useless to a conversation even though it would be invisible to a web page. Before scoping any UCaaS vendor, baseline the transport.

• Bandwidth. Budget roughly 85 to 100 Kbps per concurrent call with common codecs and overhead. Concurrency, not headcount, sets the number — a 200-person office rarely exceeds 40 to 50 simultaneous calls. Size for the busy hour, then add margin for video and screen sharing on the same collaboration client.
• QoS end to end. Mark voice traffic (DSCP EF for media, a separate class for signaling) and honor those markings on every hop you control. QoS that stops at the LAN edge is decorative; the internet does not read your DSCP tags, which is precisely why the underlay matters.
• Jitter and loss. Target latency under 150 milliseconds one way, jitter under 30 milliseconds, and packet loss under one percent. Measure it over days, not minutes, so you catch the afternoon congestion peak rather than the quiet morning.

For multi-site organizations, this is where SD-WAN earns its keep. Application-aware routing steers voice onto the healthiest path in real time, fails a call flow over before users hear it break, and applies consistent QoS policy across circuits from different carriers. Where sites span regions or countries, resilient global network connectivity is the difference between a UCaaS rollout that sounds local everywhere and one that sounds acceptable only near the data center.

Session border controllers: still the boundary you need

The SBC does not disappear because the PBX did. It becomes the controlled edge between your network and the carrier or UCaaS provider — enforcing security, normalizing signaling, and giving you a place to troubleshoot.

• Security. The SBC hides internal topology, rate-limits registration floods, and defends against toll fraud and telephony denial-of-service. An exposed SIP endpoint gets scanned within hours of going live.
• Interoperability. It reconciles SIP dialects, transcodes codecs when two sides disagree, and bridges legacy analog needs — elevator lines, fax, paging, door controllers — that no cloud tenant handles natively.
• Survivability. A local SBC or gateway with survivable branch telephony keeps dial tone and 911 alive at a site even if the WAN link to the cloud drops.

If you are keeping any on-prem endpoints during a phased move, the SBC is also what lets old and new coexist without a hard flag day.

Number porting: start the clock early

Porting is the item most likely to slip your go-live date, because the timeline is controlled by the losing carrier and regulators, not by you.

1. Inventory every number. Main lines, direct-inward-dial ranges, fax, alarm and elevator lines, analog devices, and toll-free numbers each have their own handling. The forgotten fax line is the classic post-cutover outage.
2. Pull a recent bill and CSR. The Customer Service Record must match your port request exactly — company name, service address, account number. A single mismatched field triggers a rejection and restarts the clock.
3. Plan realistic windows. Simple local ports commonly land in one to two weeks; complex or toll-free ports run three to four weeks or longer. Treat any quoted date as conditional until the firm order commitment is confirmed.
4. Port in stages where you can. Move a pilot group's numbers first, prove the flow, then port the bulk. Keep forwarding in place on legacy numbers as a safety net during transition.

Never disconnect the old service until every number is confirmed ported and tested. A ported number cannot be un-ported quickly if something is wrong.

E911: the requirement you cannot treat as an afterthought

Cloud voice decouples a phone number from a physical location, and that is exactly the problem emergency services care about. In the United States, Kari's Law and the RAY BAUM'S Act impose concrete obligations: direct 911 dialing with no prefix, on-site notification when someone calls 911, and a dispatchable location — building, floor, and where practical the room — conveyed with the call.

• Map location, not just number. For fixed desk phones, bind each device or subnet to a validated civic address. For softphones and mobile users, use dynamic location so a laptop calling 911 from a branch does not route dispatchers to headquarters.
• Notify on site. Configure alerts to reception or security when any 911 call is placed, so a human can meet responders at the door.
• Test with the provider's process. Validate addresses through the emergency routing service before cutover, and re-verify after any move-add-change. A wrong E911 record is not a help-desk ticket; it is a life-safety failure.

Phased versus flash cutover

Both approaches are legitimate. The right one depends on your tolerance for coexistence complexity versus event-night risk.

• Phased (parallel run). Old and new systems operate side by side; you migrate by site, department, or user group. Lower blast radius, easier rollback, and real production feedback before the whole company depends on it. The cost is a longer window of running two systems, bridged through the SBC, and the discipline to keep number routing coherent across both.
• Flash cutover. Everyone moves in a single window. Simpler to reason about and cheaper in coexistence effort, but every problem surfaces at once and rollback means porting numbers back. Reserve it for smaller, single-site organizations with clean number inventories.

For anything above roughly 100 seats or more than one location, phased almost always wins. Whichever you choose, rehearse cutover as a written checklist with named abort criteria and a tested fallback.

Adoption and integration decide the ROI

The technical cutover is half the project. The other half is whether people actually use what you bought.

• Train by role, not by feature. Reception, sales, and field staff use voice differently. A 20-minute role-specific session beats a generic feature tour.
• Standardize endpoints and clients. A short list of supported handsets, headsets, and desktop or mobile apps keeps support sane and audio predictable.
• Integrate deliberately. UCaaS earns its cost when it connects to the tools people already live in — calendar presence, click-to-dial from the CRM, chat and meetings in one client. If contact center is in scope, plan CCaaS integration and queue routing as its own workstream, not a checkbox on the UCaaS order.

Where to start

A clean UCaaS migration is five disciplines done in order: baseline the network and QoS, keep an SBC at the edge, start porting early with a matched CSR, get E911 right before go-live, and choose phased or flash deliberately with a tested rollback. Skip any one and it becomes the thing that surfaces on cutover night.

intSignal designs and runs cloud voice migrations end to end, and folds them into complete IT support so the network, security, and help desk that voice depends on are managed as one system rather than three vendors pointing at each other. If you are scoping a move off on-prem PBX and want a candid read on network readiness and cutover risk, talk to our team.