The Complete Guide to Migrating From PBX to Cloud VoIP
A PBX-to-cloud VoIP migration is the process of moving call routing, extensions and number ownership from an on-premise telephone switch to a cloud-hosted platform, without losing call continuity during the transition. Done properly, nobody outside the IT team notices it happened.
The risk in this project is almost never the technology — it is sequencing. Organizations that migrate badly tend to do one of two things: cut over everyone at once, or port numbers before the new system is proven. Both remove your fallback option at the exact moment you need it.
Why do PBX migrations fail?
Most failures trace back to one of three causes:
- Numbers ported too early. Once a number is ported, reverting it is a second porting request, not a switch flip. If the new platform has an unresolved issue, you are stuck routing live calls through it.
- IVR copied instead of redesigned. Call flows built on a PBX twenty years ago often carry dead branches and workarounds nobody remembers the reason for. Replicating them exactly just moves the clutter to a new platform.
- No pilot. Skipping straight from configuration to full cutover means the first time real call volume hits the new system is also the moment every extension in the building depends on it.
Phase 1: Audit your current system
Before touching the new platform, document what the PBX is actually doing:
- Every extension, its user, and whether it is a desk phone, softphone or shared line
- IVR menus, including every branch and the hunt group or voicemail box it terminates in
- Integrations — CRM click-to-dial, call recording, contact center scripting
- Current handset models and whether they are standard SIP or proprietary digital sets
- Peak concurrent call volume, which determines the bandwidth and licensing you need to provision
This audit is tedious and worth doing properly. Gaps found here cost minutes to fix; gaps found during cutover cost hours of downtime.
Phase 2: Provision the cloud platform in parallel
Set up the new system alongside the existing PBX rather than replacing it outright. This means:
- Creating user accounts and extensions on the new platform using placeholder numbers, not your live main lines
- Configuring SIP trunking if you want to keep some PBX infrastructure in place during the transition — see SIP trunking for that interoperable approach
- Re-provisioning reusable handsets to register against the new platform, pointed at placeholder extensions for now
Running both systems simultaneously costs a short period of duplicate administration. It buys you the ability to test without any live-call risk, which is the entire point of this phase.
Which handsets can you reuse?
This is one of the biggest line items in a migration budget, and it depends entirely on what you currently have.
| Handset type | Reusable on cloud VoIP? | Notes |
|---|---|---|
| Standard SIP (Poly, Yealink, Cisco SIP-mode) | Yes | Re-provision firmware to point at the new platform; no hardware cost |
| Proprietary digital (vendor-locked to a specific PBX) | No | These phones speak a proprietary signalling protocol, not SIP, and cannot register elsewhere |
| Analogue sets via ATA gateway | Usually yes | Requires an analogue telephone adapter; works but loses some features |
| Softphone / mobile app | Yes | No hardware dependency at all |
If your current estate is digital proprietary handsets — common with older Avaya Aura and Cisco CallManager deployments — budget for new desk phones or a shift to softphones rather than assuming the existing hardware carries over.
Phase 3: Pilot with one team
Move one department — ideally one that is tolerant of minor friction and vocal enough to report problems clearly — onto the cloud platform for one to two weeks, using the placeholder numbers from Phase 2.
Watch for:
- Call quality under real conditions, not just test calls from your desk
- Whether the IVR redesign actually matches how calls are supposed to flow
- Integration behavior — does click-to-dial, recording or CRM logging work as expected
- Handset re-provisioning issues on anything other than a fresh unit
A pilot that runs clean for two weeks is a reasonable basis for confidence. A pilot that surfaces problems is the entire reason you ran one before porting numbers.
Phase 4: Redesign your IVR, don’t just copy it
Resist rebuilding the old menu tree exactly as it was. Use the audit from Phase 1 to:
- Remove branches that lead nowhere or route to extensions that no longer exist
- Collapse menus that were only deep because of historical PBX limitations the cloud platform doesn’t share
- Rebuild hunt groups and voicemail routing against the new extension numbers, verified in the pilot
Phase 5: Port your numbers
Porting is the step that moves your legally-owned phone numbers from the old carrier to the new one. It is controlled by the losing carrier, not Salamtalk — once a port request is submitted, the timeline is largely out of your hands.
- Local US numbers typically complete in 2–4 weeks.
- International numbers vary considerably by country and carrier, and some jurisdictions require additional documentation before a carrier will release a number.
- Numbers stay live throughout the process. The port itself is a routing change at the carrier level, not a disconnection — calls continue arriving until the switch completes.
Submit porting requests only once the pilot has proven the new platform is configured correctly. Porting early, before you are confident in the setup, removes your ability to fall back cleanly.
Phase 6: Cut over and monitor quality
With numbers ported, move remaining users onto the cloud platform. In the first two weeks after cutover:
- Monitor jitter and packet loss, not just raw bandwidth — voice quality is sensitive to variance in packet arrival, so prioritize voice traffic with QoS on your network
- Check that STIR/SHAKEN caller ID attestation is passing correctly on outbound calls
- Confirm call recording, IVR routing and integrations are behaving identically to the pilot
Phase 7: Decommission the PBX
Keep the PBX powered and reachable as a fallback for a quiet period — 30 days is a reasonable default — before formally decommissioning it. This is your rollback plan: if a serious issue surfaces in week two that wasn’t caught in the pilot, you still have a working system to revert to while it’s fixed.
What can go wrong?
- Porting delays outlast your fallback window. If a losing carrier is slow, you may be running parallel systems longer than planned. Build buffer into your decommission date rather than committing to a hard deadline.
- A proprietary handset estate is bigger than assumed. Teams sometimes discover mid-migration that “most of our phones are SIP” was optimistic. Budget hardware replacement as a contingency, not an afterthought.
- The IVR redesign introduces new gaps. A cleaner menu tree can accidentally drop a routing path that handled an edge case nobody documented. This is what the pilot is for — run it long enough to catch low-frequency call patterns.
- QoS isn’t actually configured on the network. Teams often assume their circuit has “enough bandwidth” and skip QoS entirely, then see call quality degrade the moment general office traffic spikes.
- Rollback is attempted after the PBX is already decommissioned. Once the fallback is gone, there is no clean revert path. Don’t shorten the quiet period to save time.
Next steps: review business VoIP for the platform this migration lands on, check SIP trunking if you want to keep PBX hardware and replace only the lines, or contact us to plan a porting timeline for your specific carriers.