Most businesses do not delay a cloud phone system migration because they doubt the benefits. They delay because the phone system is the one piece of infrastructure where failure is instantly visible to every customer. A botched email migration produces a support ticket; a botched phone migration produces silence on the main line during business hours. This guide sets out the migration approach we use with customers who cannot tolerate that risk — a phased plan where the old system stays live until the new one has proven itself.
Phase 1: Discovery — Document What You Actually Have
Nearly every migration problem traces back to something nobody documented. Before touching anything, capture:
- Every number you own, including the ones nobody remembers — fax lines, alarm lines, lift lines, the direct dial for the person who left in 2019 but whose number is printed on a sign somewhere.
- Current call flows — what happens to an inbound call at 09:00, at 18:00, on a public holiday, and when the queue is full.
- Extension inventory with the actual human who uses each one, their device type, and their MAC address.
- Integrations — CRM click-to-call, the door entry system, the paging amplifier in the warehouse, the analogue credit card terminal.
- Contract end dates for circuits and maintenance, so you are not paying twice for longer than necessary.
The analogue devices are the ones that bite. Lift emergency phones, fire alarm diallers and some payment terminals expect a real analogue line, and they need an ATA (analogue telephone adapter) or a retained POTS line. Finding them during discovery costs an afternoon; finding them during cutover costs a compliance incident.
Phase 2: Design the New System Before You Build It
A migration is the best opportunity you will get to fix call flows that have accumulated fifteen years of workarounds. Resist the temptation to replicate the old system exactly — but equally, resist redesigning everything at once. The pragmatic middle is to rebuild call flows cleanly while keeping the caller experience recognisable.
Decide up front on your numbering plan (extension length, ranges per department, reserved blocks for growth), your queue strategy per team, your out-of-hours behaviour, and your voicemail policy. Document it, then build to the document.
Phase 3: Build and Test in Parallel — The Key to Zero Downtime
This is the phase that makes downtime avoidable. Your Cloud PBX is provisioned and fully configured while the old system continues to handle all live traffic. Nothing is at risk yet.
Get temporary test numbers — not your real DIDs — pointed at the new platform, and run the entire organisation through it in test: every IVR path, every queue, every out-of-hours condition, every voicemail box, every failover destination. Have real staff make real calls to real mobiles, not just internal extension-to-extension tests, because that is where codec and NAT problems surface.
In parallel, run the network readiness work: QoS policies prioritising voice traffic on every switch and router, adequate uplink headroom (allow roughly 100 kbps per concurrent call), and confirmation that your firewall handles SIP without an ALG mangling the signalling. SIP ALG on consumer-grade firewalls causes more migration problems than any other single factor — turn it off.
Phase 4: Port Numbers with the Old System Still Live
Number porting is the step people fear most, and it is genuinely the least reversible. Three rules keep it safe:
- Do not cancel anything. Cancelling your old service before the port completes releases the numbers back into the pool, and recovering them ranges from difficult to impossible. The old contract terminates after the port, not before.
- Match the losing carrier's records exactly. Most port rejections are caused by a mismatch in the account name, service address or account number on the Letter of Authorisation. Pull a recent bill and copy it character for character.
- Port in waves. Move a small, low-risk group first — a department with a handful of DIDs — confirm it works, then move the rest. Main lines port last, once you have proven the process.
US porting typically completes in 5–10 business days per wave. On port day the transition happens within a defined window, and because the new system is already built and tested, calls start arriving on a platform that is ready for them.
Phase 5: Cutover and the First Week
Schedule cutover for a low-volume window — early morning midweek is usually better than a Friday evening, because you want your people and your provider's engineers available and alert afterwards. Keep the old system powered on and reachable for at least two weeks; if something unexpected surfaces, being able to compare against the old configuration is worth the rental.
In the first week, watch four things: answer rates by queue, abandoned call counts, voicemail boxes that are receiving messages nobody is checking, and any DID that has received zero calls since cutover. That last one is how you find the number that did not route correctly before a customer tells you.
Training Is Not Optional
The most common cause of post-migration dissatisfaction is not technical — it is that nobody showed people how to transfer a call on the new handset. Run short sessions per role rather than one long session for everyone: receptionists need transfer, park and the operator panel; managers need queue reporting and call recording; everyone else needs transfer, hold, voicemail and the mobile app. A one-page cheat sheet taped to the desk outperforms a 40-page manual nobody opens.
Realistic Timelines
For a single site under 50 users, four to six weeks from kickoff to cutover is comfortable. Multi-site deployments of a few hundred users typically run eight to twelve weeks, with sites cut over sequentially rather than together. The porting lead time is usually the critical path, not the technical build — which is why discovery and porting paperwork should start on day one.
PBX SIP Trunking assigns a named migration engineer to every Cloud PBX deployment, handles porting paperwork end to end, and runs the parallel test phase with you rather than handing over a portal login and wishing you luck.