Most cloud PBX migrations that go badly go badly for the same handful of reasons, and almost none of them are technical. Here is the sequence that keeps a cutover uneventful.
1. Audit what you actually have
Before anything else, document the current estate: every number range, every extension, every call flow, and — critically — every integration nobody remembers setting up. The fax line in the warehouse and the alarm dialler in the plant room are the two that get discovered on cutover night.
Ask specifically about:
- Number ranges and which are actually in use
- Extension list with owners and departments
- IVR menus, opening hours and holiday schedules
- Ring groups, queues and escalation paths
- Voicemail boxes worth preserving
- Any device that dials out: lifts, alarms, card terminals, fax
2. Start porting early
Number porting is almost always the longest pole in the tent. It is a regulated process involving your losing provider, who has no commercial incentive to hurry. Submit port requests as soon as the contract is signed, not after the platform build is finished.
The most common rejection reasons are trivial and avoidable: the account name on the port form does not exactly match the losing provider's records, the account has an outstanding balance, or the address on file is out of date. Get a recent bill from the losing carrier and copy details from it verbatim.
3. Build and test in parallel
Build the new call flows while the old system is still live. There is no reason to cut over to an untested dial plan. Route a handful of test DIDs into the new platform and walk every path: main menu, out of hours, holiday, overflow, voicemail, and every escalation branch.
4. Check the network before the phones arrive
Cloud voice is unforgiving of a network that was only ever asked to carry email. Verify:
- Sufficient upstream bandwidth for peak concurrent calls
- QoS marking so voice is prioritised over bulk traffic
- Firewall rules for SIP signalling and RTP media ranges
- SIP ALG disabled — it breaks more calls than it fixes
5. Cut over in stages
Move one department or one site at a time where the number plan allows. Run old and new in parallel with numbers forwarding during the transition window so no inbound call is lost while a port completes.
6. Plan the first week, not just the first day
Book extra support coverage for the week after cutover, not just cutover night. Most issues surface on day three, when someone tries the workflow nobody documented.
Publish a single, obvious route for reporting problems, and triage ruthlessly: a broken call flow is urgent, a preference about ring tone is not.
7. Decommission deliberately
Leave the old system powered but disconnected for a couple of weeks. It costs nothing and it is a genuine safety net when you discover an undocumented dependency. Only then cancel the old circuits — and check the cancellation actually happened, because paying for a decommissioned PRI for eight months is a surprisingly common outcome.
