UCaaS Migration Checklist: Moving Off Legacy PBX Without Downtime

Why migrations fail, and it is rarely the vendor

Search "PBX to cloud migration" and most of what comes back is vendor comparison content. That misses the actual failure pattern. A 2026 industry writeup on failed UCaaS deployments names the same two root causes across nearly every bad migration: no pilot phase, so unknown issues surface for the first time in front of the whole user base, and no rollback plan, which turns a fixable configuration error into a full outage [techmode.com, "Why So Many UCaaS Deployments Fail," checked 2026-09-16]. Neither of those is about which platform you chose.

The most commonly cited downtime-cost figure, $5,600 per minute, traces back to a 2014 Gartner blog post that has since been taken down, and Gartner's own post described it as the midpoint of a much wider range, roughly $2,300 to $9,000 per minute depending on the business [Gartner, "The Cost of Downtime," 2014, cited via secondary sources since the original is no longer live, checked 2026-09-16]. Treat that number as a reason to plan carefully, not as a precise cost you can budget against. It is more than a decade old and predates how dependent most businesses now are on cloud tools generally.

This guide walks through the parts of a PBX migration that actually determine whether cutover day goes smoothly: what to inventory before you sign anything, how number porting timelines really work, and how to structure a pilot and cutover so a mistake is recoverable instead of a full-office outage. Nextiva shows up in a few places as a concrete example of how one major provider handles a specific step, not as the recommendation. The same checklist applies whether you are moving to Nextiva, RingCentral, 8x8, Vonage, or anyone else.

Before you sign anything: inventory the parts of the PBX nobody thinks about

Start with a full list of every extension, trunk, and call queue on the current system, then go one level deeper: which non-phone devices are riding on those same lines. Fax machines are the single most common miss, particularly in healthcare, legal, and financial offices that still fax regularly, along with alarm-panel circuits, elevator emergency phones, POS credit card lines, and building intercom systems that were wired through the PBX years ago and that nobody currently at the company remembers installing [Altigen, Cloud Contact Center Migration Guide; Mushroom Networks, PBX-to-cloud migration guide, checked 2026-09-16].

The reason this matters is not abstract. The single most common cause of a rough cutover is a business discovering on day one that an extension nobody thought about was actually being used for something important [techmode.com, checked 2026-09-16]. A fax line that stops working on cutover morning is an annoyance if someone notices immediately and an actual compliance problem if it is how the office receives signed patient forms or legal documents and nobody notices for a week.

Pair the device inventory with a network readiness check. Cloud voice and video depend on available bandwidth, QoS configuration, and low latency, and a network that was fine for email and web browsing is not automatically fine for a building full of simultaneous calls [Altigen, checked 2026-09-16]. Get this checked before you schedule a cutover date, not during it.

Number porting: the timeline most people get wrong

Porting a phone number to a new carrier is regulated, and the regulation actually works in your favor for simple cases. Under a 2009 FCC order (FCC 09-41), a "simple port" (single line, no complex switch translations, not tied to a reseller or unbundled network elements) must be completed within one business day of a valid request, codified at 47 CFR § 52.35 [FCC 09-41; eCFR, checked 2026-09-16].

Most business ports are not that simple, which is where the "2 to 4 weeks" timeline commonly quoted for local numbers comes from. Multi-line accounts, PRI circuits, hunt groups, and numbers tied to fax or DSL commonly run 7 to 14 business days in practice, and can take longer if the losing carrier flags a discrepancy [Skyetel LNP guide; Viirtue 2026 porting guide, checked 2026-09-16]. Toll-free numbers follow a different, generally faster track, typically 6 to 10 business days, with the actual cutover ("snapback") completing in as little as 20 minutes to 2 hours once both carriers treat it as a priority [Skyetel; Viirtue, checked 2026-09-16].

Nextiva's own published process is a useful concrete example of what this looks like end to end: the current number owner signs a Letter of Authorization through DocuSign, one LOA per account, and two are required if you are porting both local and toll-free numbers. Nextiva quotes 5 to 10 business days for a typical port-in, extending to 2 to 4 weeks if the losing carrier raises a rejection or discrepancy, and is explicit that port-in requests cannot be expedited because they follow regulatory and carrier-specific timelines rather than the receiving vendor's own schedule [help.nextiva.com, "Porting Your Phone Number to Nextiva," checked 2026-09-16]. Nextiva pairs that porting process with a dedicated implementation specialist who runs the cutover and tracks milestones on a shared customer project dashboard, instead of leaving a business to handle the whole switch on its own [nextiva.com Professional Services page, checked 2026-09-16]. Ask whichever vendor you are moving to for the same specifics, both on porting timelines and on whether onboarding is hands-on or self-serve. The shape of the process is similar across providers, but the exact business-day estimate, LOA requirements, and level of onboarding support all vary.

The practical takeaway: get your Letter of Authorization submitted and your account details verified against what your current carrier has on file (account number, billing address, authorized contact name, matched character for character) as close to day one of the project as possible. Porting delays are the single most common reason a planned cutover date slips, and they are driven by the losing carrier's process, not the new vendor's.

E911: do not treat this as a checkbox

Every phone system with more than one line is subject to Kari's Law and the RAY BAUM'S Act, federal rules requiring direct-dial 911 with no prefix and a dispatchable location precise enough for responders to find the caller inside the building, not just the street address on the account. Both compliance dates passed years ago. The practical question for a migration is not whether your new system can meet these requirements (nearly every legally sold system can); it is whether someone actually configured and tested it correctly at every physical location before cutover. Our full breakdown of what the law requires and who is liable if it is misconfigured is at Kari's Law Compliance Falls on the MLTS Manager.

For a migration specifically: register the dispatchable location for every location before cutover, not as a follow-up task, and place an actual test call using your new provider's test line or a coordinated call to the non-emergency verification number, not a real 911 call. Do this for a branch office or conference room, not just the main line, since that is where dispatchable-location errors are most likely to hide.

Pick a cutover strategy before you pick a date

There are two broad approaches, and the right one depends on how much risk a full-office outage represents for your business. A parallel run keeps the legacy PBX and the new cloud system running simultaneously until the new environment is fully validated, then cuts over once confidence is high [Altigen, checked 2026-09-16]. A wave or canary rollout instead migrates a small, low-risk group first, routing calls between legacy and new users across an interoperability bridge, then expands in batches once that group is stable [Altigen; Enreach, "Legacy to Cloud Migration: Achieving Zero Downtime at Scale," checked 2026-09-16].

Parallel running costs more, since you are paying for two systems at once for the overlap period, but it gives you a real fallback: if the new system has a problem on cutover day, calls can route back to the PBX while it gets fixed. A wave rollout is cheaper and lower-effort to set up, but a business with a single receptionist line and no real redundancy has less room to recover from a bad first wave than a larger office with multiple lines to fall back on. Match the strategy to how much an outage would actually cost you, not to whichever approach sounds more modern.

Whichever you choose, put a written rollback trigger in place before cutover day, not during it: a specific, pre-agreed condition (dropped-call rate above some threshold, a compliance-critical line down, more than some number of user-reported issues within the first hour) that triggers falling back to the old system rather than pushing through and hoping it resolves itself.

Pilot testing: who to pick and what to test

Run internal IT testing first to shake out obvious configuration issues, then hand off to a small, deliberately chosen pilot group, not whichever department happens to be available that week. Good pilot candidates are people who communicate clearly about what is and is not working, since the entire point of the pilot is getting feedback specific enough to act on rather than a vague "it seems fine" [C2XCEL, "UCaaS Migration Checklist: 15 Steps IT Teams Miss," checked 2026-09-16]. Route pilot feedback through a single point of contact, commonly the service desk, so issues get logged and prioritized consistently instead of arriving as scattered messages to whoever happens to be nearby.

Beyond "can people make calls," test inbound routing and IVR menus behaving the way they did on the old system, voicemail delivery (including voicemail-to-email if that was in use), call transfer and hold behavior, any CRM or help desk integration that logs calls, and SMS/MMS if the ported numbers are text-enabled, since text capability on a newly ported number sometimes lags voice activation by a day or more. A pilot that only confirms "the phones ring" misses most of what breaks in a real migration.

Cutover day: the runbook

On the actual cutover date, work through a fixed checklist rather than relying on memory, since cutover day is exactly when things get missed under time pressure. At minimum: confirm inbound calls reach every ported number correctly, confirm outbound caller ID displays the right number, test voicemail and voicemail-to-email delivery, verify SMS/MMS send and receive on any text-enabled lines, walk through call routing and IVR menus end to end, place a coordinated E911 test call using the non-emergency verification line for at least one non-main location, and confirm any CRM or help desk integration is logging calls correctly.

Do not cancel or deactivate the old PBX or carrier account until the port is fully confirmed complete. Cancelling early releases the numbers back to the carrier and can strand an in-flight port, and this is one of the more common self-inflicted failures in an otherwise well-planned migration. Keep the legacy system live and paid through the confirmed cutover, run through the checklist above, and only decommission it once everything on the list has been verified, ideally with a 24 to 48 hour buffer where the old system stays reachable as a fallback.

The first 30 days after cutover

A migration is not done the moment the last call routes correctly. Watch call quality metrics, dropped-call rates, and voicemail delivery for at least the first two to four weeks, since intermittent issues, particularly ones tied to specific network paths or device types, often do not surface until real production volume hits the new system rather than a pilot group. Keep the cutover-day checklist as a recurring spot-check for the first month rather than treating it as a one-time event.

Revisit the E911 dispatchable location for any location where staff or desk arrangements changed during the migration itself, since a location that was accurate on cutover day can drift if desks or extensions moved as part of the broader transition. Confirm with your new vendor who owns keeping this current going forward. The FCC's default liability rule puts that responsibility on the system's manager, not automatically on the vendor, unless your contract says otherwise, covered in more detail in our Kari's Law compliance guide.

Frequently asked questions