Most organizations don’t migrate off their PBX because they’re excited about VoIP. They migrate because the system is failing — a lapsing maintenance contract, a manufacturer that stopped making parts, or an IT manager tired of being the only one who can reprogram a hunt group. Whatever the trigger, the migration touches more of the organization than most infrastructure projects: every extension, every call flow, every switch the phones plug into. Handled as a phased process it’s manageable; handled as a weekend cutover, it’s how a front desk can’t answer calls Monday morning.
Start With a Complete Inventory of What You Have Now
Before evaluating any VoIP platform, document what the current system actually does — not the original design, but what’s configured today after years of undocumented changes. Pull a full extension list, map every hunt group and ring group, document auto-attendant menus and after-hours routing, and note which lines handle fax machines, elevator phones, alarm panels, or overhead paging. Those get missed constantly, since they’re rarely thought of as “phone lines” even though they run on the same trunks.
Equally important: talk to the people who use the phones. A facilities director might not know dispatch relies on a specific hold-and-transfer sequence, or that warehouse floor phones feed an overhead paging zone. Front desk staff, call center agents, and department heads carry knowledge about how calls actually flow that won’t show up in any system printout. That inventory becomes the requirements list the new platform has to match — not exceed, match.
Network Readiness: Bandwidth, QoS, and PoE
VoIP doesn’t just need “enough” internet bandwidth — it needs a network built to prioritize real-time voice traffic over everything else competing for the same switch ports and internet connection. This is the step most migrations underestimate, and the root cause behind most “the new phones sound choppy” complaints. Before selecting hardware or a provider, confirm:
- Available bandwidth for the expected number of concurrent calls, based on each phone’s codec
- QoS configured end-to-end — voice traffic tagged and prioritized at every switch and router it passes through, not just at the edge
- A dedicated voice VLAN separating phone traffic from data and guest traffic
- PoE capacity on access switches — the right standard supported, with enough power budget for the full phone count
- Switch age and firmware, since older switches often can’t handle tagged VLANs or modern IP phone PoE draw
- WAN quality — latency, jitter, packet loss — plus redundancy, since hosted VoIP quality depends entirely on the internet staying up
Skipping this step is the most common reason a rollout gets blamed on “bad VoIP” when the real problem is a switch with no QoS policy and a saturated circuit.
Hosted Cloud VoIP vs. On-Premise IP-PBX
There’s no universal answer between hosted (cloud) VoIP and an on-premise IP-PBX — it depends on site count, IT staffing, and growth plans.
Hosted VoIP moves the phone system’s hardware and maintenance off-site to the provider. Updates and most administration become the provider’s job, and adding a location or extensions is usually a configuration change, not a purchase. The tradeoff: call quality depends entirely on the internet connection at each site, plus a predictable per-seat cost that on-premise systems avoid.
An on-premise IP-PBX keeps call-processing hardware in the building or a data center — more configuration control, deeper integration with site-specific systems, and internal calling that survives an internet outage. It also carries the tradeoffs that made the old PBX a problem: hardware needing patching, an eventual lifecycle end, and in-house expertise to maintain it.
For a single site with straightforward needs and predictable costs in mind, hosted VoIP is usually simpler. Multi-site organizations with in-house IT staff, compliance requirements, or heavy integration with other systems — a warehouse’s dispatch software, a clinic’s scheduling system — sometimes get more value from an on-premise or hybrid deployment. Either way, the network readiness work above applies regardless.
Number Porting: Start It Earlier Than Feels Necessary
Porting existing numbers to a new provider is almost always the long pole in a migration timeline, and it’s started too late more often than not. A standard local port typically takes a few weeks once paperwork is submitted correctly — and “correctly” is doing a lot of work there. The losing carrier will reject a request over a mismatched business name, an outdated address, or an account number that doesn’t match exactly, resetting the clock each time. Toll-free numbers or a slow-moving carrier take longer.
The lesson: start porting as soon as a provider is selected, in parallel with network readiness and hardware deployment, not after everything else is ready. Pull a current bill, confirm the exact business name and address on file, and submit the Letter of Authorization with enough lead time that one delayed port doesn’t sink the schedule. It’s also worth confirming what happens to inbound calls during the porting window, since the new system may go live before the numbers move.
Pilot First, Then Phase the Cutover
A full rip-and-replace cutover — disconnecting the PBX and switching every phone over a single weekend — can work if everything’s been tested in advance. In practice it’s riskier than most organizations need, surfacing every configuration gap, network issue, and training gap at once, on a live system, with no fallback.
A phased approach spreads that risk out. Start with a pilot group — one department, floor, or location — on the new system for a couple of weeks while the rest stays on the PBX. A pilot surfaces problems a lab test won’t: a missed call flow, a switch needing a QoS adjustment, a front-desk feature that wasn’t replicated. Once stable, extend to the next group, then the next. Multi-site organizations do best phasing by location, isolating issues instead of surfacing them everywhere at once.
Keeping the old PBX live in parallel, even in a limited capacity, gives everyone a fallback if something in the new environment isn’t working yet. It’s tempting to decommission it quickly to stop paying for two systems, but that decision should come after the new one has proven itself.
Training and the Pitfalls That Sink VoIP Projects
Even a technically flawless migration can fail on adoption if staff aren’t trained before their phones change. VoIP handsets and soft-phone apps behave differently enough from a legacy phone that muscle memory for transferring a call or checking voicemail doesn’t carry over. Short, role-specific sessions held before cutover, plus a one-page reference card at each desk, head off most of the support calls that otherwise land on IT day one.
A handful of other issues come up often enough to call out directly:
- E911 location accuracy: VoIP phones can move between jacks, floors, or buildings, and emergency routing depends on the system knowing each phone’s correct location — configured and tested per device, not assumed.
- Call quality blamed on the phones when the real cause is the network: if QoS wasn’t configured properly, “the new phones sound bad” is usually a switch issue, not a hardware defect.
- Porting delays that weren’t built into the timeline, creating a stretch where the system is ready but the numbers haven’t moved yet.
- Skipping the pilot phase to save time, which tends to cost more time later when problems surface everywhere at once.
Nearly every VoIP migration problem traces back to one of these, and nearly all are avoidable with the same sequence: inventory first, network readiness second, then a phased rollout with training built in.
A PBX-to-VoIP migration is as much a network project as a phone project, which is why it gets approached that way from the start — assessing the switches, cabling, and PoE budget the phones will run on before recommending a platform. Cyber IT Tech’s team carries Cisco, Fortinet, and Microsoft certifications alongside the structured cabling and networking background this work depends on, following the same sequence outlined above: inventory, network readiness, a real pilot, then a phased cutover with training built in.
For organizations across Chicago and the greater Midwest still running an aging on-premise PBX, telecom and network expertise under one roof tends to separate a smooth migration from one that turns into a string of support tickets. Whether the right fit is hosted VoIP, an on-premise IP-PBX, or something in between, getting the network right first is what makes any of those choices work.