The UCaaS Migration Checklist: 12 Things to Get Right Before You Cut Over

Most UCaaS migrations go wrong for the same handful of reasons: porting dates slip, E911 records don't match, key users discover they're missing critical features two days after the old PBX is already turned off, and nobody tested the physical handsets under real-world network conditions. None of these are hard problems to solve — they're just hard to remember if you haven't run a cutover before. This is the checklist we use internally at ITG. Steal it.

Phase 1: Before the contract is signed

1. Build a real extension and DID inventory

Before you pick a platform, make sure you know exactly what you have today. That means a line-by-line list of every direct inward dial (DID) number, main number, fax line, alarm line, elevator line, and extension, along with the user or department assigned to each one. 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. Get the inventory clean first.

2. Decide which features are actually non-negotiable

Every UCaaS vendor will claim feature parity. In practice, the edges matter. Do you need call queues with skills-based routing? Call recording with retention policies? Paging to overhead speakers? Integration with your CRM, your EHR, or your contact center? Visual voicemail to email? Shared line appearances? Physical reception consoles with busy-lamp fields? Make the list before the demo, not after.

3. Map your locations against the E911 requirements

Kari's Law and Ray Baum's Act both apply to UCaaS deployments and both have real teeth. Every user station needs to be associated with a dispatchable location that's accurate enough to get a first responder to the right floor and suite. For multi-site businesses, this is a much bigger project than most vendors admit. Start the address cleanup and location mapping before you sign the contract, not after.

4. Decide on physical devices vs softphone-only

A lot of 2026 deployments go softphone-first, with physical handsets only at reception desks and conference rooms. That's fine — but it's a decision, not a default. Some of your users will absolutely need a physical phone (plant floors, clinical environments, reception). Count them now, spec the devices, and get them ordered. Hardware lead times have gotten better since 2022 but they still aren't same-day.

Phase 2: During implementation

5. Confirm the number porting plan in writing

Number porting is the single most common cause of cutover delays. The losing carrier has every incentive to slow the process down, and the new UCaaS vendor is legally dependent on them. Get the porting plan in writing, include the specific submission dates, and track it weekly. If the losing carrier asks for "account verification" letters, expect to sign at least one, probably two.

6. Audit the LAN and WAN for voice readiness

UCaaS traffic is voice over the internet. That means QoS markings on your switches, enough upstream bandwidth at every location, and a firewall configured to prioritize SIP and RTP correctly. For any site with more than a handful of users, a pre-cutover network readiness assessment is mandatory. We've seen brand-new deployments sound terrible because of a single misconfigured switch port.

7. Build the dial plan and call flows in staging

Before anyone touches production, the entire call flow — auto-attendants, call queues, after-hours routing, holidays, voicemail boxes, hunt groups — needs to be built out and tested in the new system. Build it first, then recruit 3–5 users to run scripted test calls through every branch of the flow. Fix what's broken before cutover day, not during it.

8. Train power users before the rest of the company

Every office has a handful of people who live on the phone — executive assistants, reception, inside sales, dispatchers. Train them a week before cutover, not on cutover day. They will find the gaps that general training missed, and they'll be the ones your less-technical users turn to for help in the first 72 hours.

Phase 3: Cutover day and after

9. Run cutover at the lowest-traffic hour

For most businesses that's overnight Tuesday or early Saturday morning. Never on a Monday. Never the week of a major company event. Never during end-of-quarter or end-of-year. Pick the calm window, even if it means pushing the project by two weeks.

10. Keep the old system alive for 72 hours

Do not turn off the legacy PBX the minute the port completes. Leave it powered on, leave the old circuits hot, and leave a short forwarding plan in place for any rogue calls that route there. You'll almost always find one or two straggler numbers that weren't on the porting list.

11. Run a daylong "voice helpdesk" on day one

Staff a dedicated helpdesk — either internally or via the vendor — for the full first business day after cutover. Most of the issues you'll see will be minor (a hunt group routing to the wrong person, a conference room handset that didn't provision), but they all need to get addressed within hours, not days. Front-load the support and the rest of the week is calm.

12. Validate billing and feature usage after the first month

Three to four weeks after cutover, run a full audit of the first UCaaS invoice against the contract. Look for unprovisioned users being billed, feature bundles that didn't match what was quoted, and any orphan lines that should have been deactivated with the old system. Catch billing drift in month one and it's a quick fix. Catch it in month six and you're asking for retroactive credits.