The first sign wasn't dramatic. On a Tuesday morning, the receptionist at a regional distribution company — three sites, roughly 120 employees, the kind of operation that lives and dies by whether a customer can reach dispatch — noticed that inbound calls to the main line were dropping after a single ring about a third of the time. By Thursday, the on-premises PBX in the back-office closet was rebooting itself twice a day, and the vendor's best answer was a used line card sourced off eBay. That was the moment the conversation shifted from "patch it" to a zoom phone migration. What follows is a composite — an anonymized blend of engagements we've run for mid-market clients, with rounded, plainly illustrative numbers rather than any single customer's books — but every step here is one we've walked more than once.

The trigger: when "it still works" stops being true

The chassis in that closet was a decade-old platform that had quietly aged into a manufacturer end-of-support timeline — the same story we lay out in our guide to ShoreTel and Mitel end-of-life. It technically still routed calls, which is exactly why it had survived three budget cycles. But "still works" was hiding real exposure: failing hardware with no warranty path, a PRI circuit costing several hundred dollars a month, and a dial plan only one semi-retired technician fully understood. When the dropped-call problem started costing the company reorders, the finance side finally agreed that the cheapest option on paper had become the most expensive one in practice.

Discovery: map what the old system actually does

The mistake teams make here is treating a phone system as a black box you swap out. It isn't. Before we priced anything, we spent two days documenting how the current environment actually behaved — not how the original install guide said it should. For a distributed business, that discovery covers a predictable set of items.

  • The dial plan. Every extension, hunt group, and speed dial, including the three "temporary" routes added years ago that nobody could explain but everyone quietly relied on.
  • The call flows. What happens to a call at 8:59 a.m., at noon, at 5:01 p.m., and during a holiday — because those transitions are where callers actually get lost.
  • The numbers. The main line, each site's local DIDs, the fax lines still tied to a compliance workflow, and the toll-free number printed on the side of every truck.
  • The endpoints. Which desk phones stay, which get replaced, and who genuinely needs a physical handset versus a softphone on a laptop or a mobile app.
  • The network. Whether each site's LAN, switching, and internet circuits can carry voice cleanly, which is a question of QoS for VoIP long before it's a question of licensing.

Discovery is also where you decide whether the destination is right at all. We walked the client through the same trade-offs in our cloud phone buying guide — seats versus concurrent calls, contact-center features they didn't need, and the difference between a platform price and a delivered-and-supported price. Zoom Phone fit because the team already lived in Zoom for meetings, and one login for calls, video, and chat removed friction rather than adding a new silo.

Designing call flows and auto-attendants

Simplify before you rebuild

A migration is the rare chance to delete complexity instead of carrying it forward. The old system had eleven auto-attendant options, several pointing to departments that had merged or moved. We rebuilt around what callers actually pressed, reading the old platform's own reports to see which menu paths carried real traffic. The new main menu had four choices, each routing to a call queue with a named backup so a call never dead-ended in a voicemail box nobody checked. Extensions were preserved wherever possible; muscle memory is a real cost, and there's no reason to make the warehouse relearn the shipping desk's number.

Business hours, holidays, and the "who actually answers" question

We built explicit business-hours schedules per site, a shared holiday calendar, and an after-hours flow that routed urgent dispatch calls to an on-call cell phone while everything else took a message and emailed a transcript. This is the part clients underestimate: the technology is trivial, but the decisions — who covers the queue, how long a call rings before it overflows, what the closed greeting actually says — are operational, and they belong to the business, not the installer.

Porting numbers without going dark

Number porting is the step with the least room for improvisation. We submitted letters of authorization to the losing carrier, matched the billing name and service address exactly to avoid a rejection, and locked a firm order-completion (FOC) date. Critically, we kept the old PRI and the legacy PBX fully live until the port actually completed — porting is not the moment to save a month's circuit fee. The toll-free number, which routed differently, was scheduled as its own port so a hiccup on one couldn't take down the other.

The parallel run

For about two weeks, both systems ran side by side. New Zoom Phone licenses were provisioned, softphones installed, and a pilot group of ten users — a mix from each site, including the receptionist and a warehouse lead who would find every rough edge — used the new platform for real calls while the old system still carried the main lines. That parallel run surfaced exactly what we wanted it to: one site's switch wasn't prioritizing voice traffic, producing choppy audio under load. We fixed the QoS configuration then, in a controlled window, instead of discovering it live in front of every customer on cutover morning.

Cutover weekend

The actual switch happened on a Saturday, following a written runbook rather than anyone's memory — the structure we detail in our legacy PBX migration cutover plan. The port completed mid-morning, calls to the main line began landing on Zoom Phone within the hour, and we validated every path from a checklist: inbound to each queue, outbound caller ID per site, 911 with the correct dispatchable address for all three locations, voicemail-to-email, and the after-hours flow. By early afternoon we made test calls from outside numbers to confirm real-world routing, then left the legacy system powered but disconnected for a week as a safety net before decommissioning it.

The outcome

Monday morning was quiet, which is the goal. The dropped-call problem was gone because the failing hardware was gone. Just as valuable, the company had visibility it never had before: dashboards showing call volume by queue, average wait time, and missed calls by hour, so the operations manager could staff the phones against reality instead of guesswork. On cost, retiring the PRI and the aging hardware, and folding voice into a platform they already paid for, landed the monthly spend meaningfully below the old bill — roughly a quarter less, in illustrative terms — while turning an unpredictable repair liability into a flat, supported subscription.

The Bottom Line

A phone-system migration isn't really a hardware swap; it's a chance to document how your business actually communicates, delete the cruft, and land on a platform that gives you both reliability and reporting. The distribution company in this composite didn't succeed because Zoom Phone is magic — it succeeded because discovery was thorough, the network was ready, numbers were ported deliberately, and the cutover followed a plan instead of hope. If your PBX is on borrowed time or your support window is closing, that's the signal to start mapping, not to buy another line card. Our unified communications team runs these migrations end to end, and we're happy to walk your call flows with you before you commit to anything. Reach out through our contact page or call +1 (888) 790-8777, and we'll help you get from an aging PBX to a system that just answers the phone.