A Phone System Cutover Runbook That Doesn't Lose Calls
Phone migrations fail in predictable ways, and almost never in the part everyone worries about. The port completes, the handsets register, calls work. What goes wrong is the alarm line nobody inventoried, the fax that was forwarding to an address that no longer exists, and the number on a vehicle wrap that was never in the project scope.
This is the sequence we use. It is deliberately boring.
Four weeks out: inventory everything that dials
The single highest-value activity in the project, and the one most often skipped.
Every number. Not just the ones on desks. Pull a Customer Service Record from the current carrier — the authoritative list of what you are actually paying for. Expect surprises: numbers for a closed office, a second fax line, a line for a lift phone.
Every device that uses a line. Beyond phones: fax machines, franking machines, alarm panels, lift emergency phones, card terminals, door entry systems, gate intercoms, backup circuits for a till system. Each one needs a decision — migrate, replace, keep an analogue line, or retire.
Alarm panels and lift phones deserve special attention. Many require an analogue line and will not work over a standard VoIP path. Some are contractually required to be monitored. Find out before the old line is cancelled, not after.
Every place a number is published. Website, Google Business Profile, directories, invoices, email signatures, letterhead, vehicles, signage, social profiles, Apple and Google Maps listings, and any print that is already at the printer.
Every forward and routing rule currently in place. Out-of-hours diversions, overflow to a mobile, a number that forwards to a partner organisation.
Three weeks out: design and build in parallel
Build the new system while the old one runs. Nothing about the new platform needs to wait for the port.
- Build call flows, menus, hunt groups and voicemail boxes
- Record prompts
- Configure out-of-hours and the holiday calendar — including next year's
- Set up emergency calling locations for every device and user
- Enter the directory, extensions and user details
- Test internally using temporary numbers the provider supplies
Running both systems in parallel with temporary numbers lets you train staff and find design problems with zero risk.
Two weeks out: submit the port, freeze the old account
Submit with details copied from the bill, not from memory. From this moment, make no changes to the old account — a pending order on the losing carrier's side is one of the most common reasons a port is rejected.
Get the Firm Order Commitment date in writing and schedule the cutover outside business hours.
One week out: train and communicate
- Train staff on the new handsets and apps — short sessions, not documents
- Publish a one-page guide: how to transfer, how to park, how to check voicemail
- Tell customers if anything visible changes. If numbers are unchanged, say so explicitly; people assume a phone migration means new numbers
- Confirm who is on site for the cutover and who is reachable at the provider
The day before
- Confirm the FOC is still on
- Verify every handset is registered and can call internally
- Place a test call from each device type
- Confirm emergency locations are correct
- Take a screenshot of the old system's configuration — forwards, voicemail greetings, routing. You will want it
Cutover
Keep it short and verify in a fixed order:
- Port completes — confirm with the provider
- Inbound test to every ported number from an outside line. Every number, not a sample
- Outbound test from every device type, checking the caller ID presented
- Voicemail: leave one, confirm the notification arrives
- Call flows: walk the menu, confirm each option lands where it should
- Out-of-hours: temporarily shift the schedule to confirm the after-hours path works
- Emergency calling: confirm the location, using the provider's test facility
- Fax, alarm, lift and terminal lines: test each explicitly
The week after
Do not cancel the old service yet. Leave it for a few days as a safety net. Cancelling early is the one irreversible mistake in a phone migration — a released number can be reassigned and may be unrecoverable.
Then:
- Update every published listing from the inventory
- Watch for missed-call patterns that suggest a routing gap
- Collect staff friction and fix the top three
- Review the call data after a fortnight: abandonment, misroutes, after-hours volume. The real usage pattern will differ from what you designed for, and this is the moment to adjust
Only then cancel the old service, in writing, and confirm the final bill.
The three that catch everyone
The forgotten number. Something routes through a line nobody listed. The CSR is the defence.
The analogue dependency. An alarm, lift phone or terminal that needs a real line. Find it in the inventory stage; discovering it after cancellation is expensive and occasionally a safety issue.
The stale forward. A diversion configured years ago, pointing at a number that no longer answers. It works until the day it is the only path, usually out of hours.
Why the boring version wins
Nothing above is clever. The inventory is tedious, the testing is repetitive, and keeping the old service alive for a week feels like waste.
That is the job. A phone migration is not technically difficult; it is an exercise in finding everything that depends on the thing you are changing. The organisations that have bad migrations are not the ones with complicated requirements — they are the ones that discovered a dependency after the old system was gone.
