PBX to Hosted VoIP Migration Checklist: T-8 Weeks to T+1

What does a PBX to hosted VoIP migration involve, and in what order?

A migration fails when work is done in the wrong order. Number porting has the longest lead time and the least control, so it starts early, while network and device work happens in parallel.

The schedule below uses T as cutover day. Each phase has an owner and a pass/fail test, so the checklist can be handed out and tracked as a table.

How do I inventory the old PBX before migrating?

Export everything into one spreadsheet before talking to providers, because every missed item becomes a post-cutover outage. Use one tab per object type so each can be mapped to the new platform.

Draw the call flow as a diagram: inbound number, then time-of-day rule, then IVR or auto-attendant, then queue or ring group, then voicemail. Walking it from the diagram exposes after-hours and holiday routes that nobody remembers.

1. List every DID, with its carrier, destination and whether it is a main number, direct line, fax or toll-free.
2. List extensions with user, device type, MAC address, voicemail box and features such as pickup groups or call forwarding.
3. Record hunt groups, ring groups, queues, IVR menus with recordings, time-of-day and holiday rules, speed dials and music on hold.
4. List every analog line: fax, alarm, elevator, fire panel, card terminals, door phones, paging.
5. Mark unused extensions, dead DIDs and legacy features to drop. Porting and paying for numbers nobody uses is wasted money.
6. Review the contract term and early termination fee on the old PBX and carrier, and note notice periods.

How much bandwidth does hosted VoIP need per call?

Budget about 87 kbps per call each way for G.711 and about 31 kbps for G.729, both including IP, UDP and RTP overhead at 20 ms packetization. Opus is variable, so size it from the provider's stated range.

Calls are symmetric, so upload is usually the bottleneck on cable and DSL. The formula is peak concurrent calls times per-call rate, plus about 25% headroom for registration, provisioning, and other traffic.

Worked example: 20 peak concurrent G.711 calls is 20 x 87 = 1,740 kbps, plus 25% is about 2.2 Mbps of upload and the same of download, reserved for voice. If a 10 Mbps upload link is also used by cloud backups, cap the backup rate or the calls will suffer.

What network quality should I measure before switching?

Measure toward the provider's points of presence over hours or days, including peak times. A single quiet-hour test hides congestion.

Targets: jitter under 30 ms, packet loss under 1%, and one-way latency under 150 ms (roughly 300 ms round trip). Most providers publish a test host or a test tool, so use theirs where offered.

# Path quality over 100 cycles, report mode (loss %, avg and worst latency per hop)
mtr -rwc 100 sip.provider.example

# Sustained UDP jitter and loss test (needs an iperf3 server reachable)
iperf3 -c test.provider.example -u -b 2M -t 60 -R

# Basic latency trend, run during busy hours
ping -c 300 -i 0.5 sip.provider.example | tail -3

How should I set up the router, firewall, VLANs and QoS?

Put phones on a separate voice VLAN so broadcast traffic and PCs do not compete with them, and so you can apply QoS and ACLs cleanly. Check the PoE budget: add up phone wattage (often 2 to 7 W each, more with color screens or expansion modules) and compare with the switch total, not just per-port limits.

Mark RTP as DSCP EF (46) and SIP signaling as CS3 (24) or AF31 (26). Confirm switches and the router trust and queue on these markings. QoS only controls your own link; once packets enter the internet, markings are usually ignored, so it helps most when the WAN uplink is saturated.

On the firewall, disable SIP ALG. It rewrites SIP packets and is a top cause of one-way audio, failed registrations and dropped calls. Then allow the provider's published SIP and RTP ranges (commonly UDP 5060 or TCP/TLS 5061 for SIP, and a large UDP range for RTP; use the provider's exact list).

How long does number porting take, and how do I avoid rejections?

Simple local numbers typically take about 1 to 2 weeks. Complex ports, toll-free numbers and large multi-line ports can take several weeks, so submit at T-7 or T-8 weeks. The provider gives a Firm Order Commitment (FOC) date, which is the scheduled port date; build the cutover around it.

Most rejections are data mismatches. The request must match the old carrier's records exactly: account name, service address, billing telephone number (BTN), account number and PIN. Get a recent bill and a Customer Service Record (CSR) to copy from.

Do not cancel the old carrier until the port completes, because cancelling can release the numbers and lose them. In the meantime, use temporary numbers and forward the old lines to them for testing.

1. Request the CSR and a recent bill from the current carrier.
2. Copy the exact account name, address, BTN, account number and PIN into the port request.
3. Submit the request and order temporary numbers for pilot users.
4. Fix any rejection the same day; each rejection resets the timeline.
5. Confirm the FOC date and schedule a staged port if numbers are numerous.
6. After the port and a one-week soak, cancel the old services.

How do I handle phones, E911, fax and alarm lines?

Check each handset model against the provider's supported list (Poly, Yealink, Cisco and others). Reflash firmware to a supported version, then provision with zero-touch: DHCP option 66 pointing to the provisioning URL, or the manufacturer's redirect service. Analog phones, fax machines and paging systems need ATAs or analog gateways. Plan headsets, conference phones and softphones for remote staff.

For emergency calling, register a dispatchable address for every physical location and every remote user, including floor and suite. In the US, Kari's Law requires direct 911 dialing without a prefix on multi-line systems and notification, and RAY BAUM'S Act requires dispatchable location information. Set up internal notification to security or reception when anyone dials 911, and test using the provider's guidance (many have a test number or process; do not simply place live calls).

Alarm panels, elevator phones, fire panels and card terminals are the lines most often forgotten. Keep them on POTS or a cellular alternative unless the vendor approves VoIP. If you do move them, use a G.711-only ATA, disable echo cancellation and compression on that port, test T.38 for fax, and get the alarm monitoring company to approve in writing.

What cutover and rollback plan should I use?

Features need checking too: call recording and compliance retention, CRM integration, voicemail-to-email, outbound caller ID name and number, 10DLC registration if you send SMS, directory listings, music on hold and after-hours routing.

Run a pilot group first on temporary numbers. Schedule the real cutover in an after-hours or low-volume window, port in stages if the number set is large, and give users quick reference guides and a training session beforehand. Provide hypercare support for the first week with a visible contact.

Cutover test list: inbound to each main number, outbound with correct caller ID, transfers, voicemail and email delivery, IVR and after-hours paths, fax, and a provider-approved emergency call test.

1. Go/no-go one day before: pilot passed, FOC confirmed, E911 loaded, failover tested, staff briefed.
2. Set a rollback time limit, for example 2 hours after cutover begins, and name who decides.
3. If a critical failure appears (inbound calls failing, 911 untested, widespread audio faults) and cannot be fixed within the limit, repoint or forward numbers back to the old PBX.
4. If numbers have already ported, forward them from the new provider to mobile numbers or the old system's lines while fixing.
5. Keep the old PBX and carrier lines live until all ports are complete and the first week is clean.