The Mitel 3300 controller in the wiring closet has a blinking amber LED that nobody can decode, the maintenance contract lapsed eight months ago, and the one technician who understood the dial plan retired to Cape Coral. That is where a legacy pbx migration usually begins at a mid-market business: not as a strategic initiative, but as the slow realization that the box routing every call your company makes is a single point of failure on hardware nobody builds parts for anymore. Moving to a cloud platform is the right answer. The catch is that the phones cannot go dark while you do it. What follows is the mechanics of getting off an on-prem Mitel or ShoreTel system without dropping a single customer call.

Still weighing whether the timing is right? The case for acting before a forced failure is in our breakdown of the Mitel and ShoreTel end-of-life situation. The general version of the destination lives in our guide to cloud phone migration; this one is narrower: decommissioning on-prem hardware, where analog tails, physical trunks, and a hard cutover create risks a greenfield deployment never faces.

Start With a Full Inventory, Not a Vendor Quote

The most dangerous number in any migration is the extension count the vendor quotes from, because it almost never matches what is actually plugged in. Legacy systems accumulate a decade of undocumented connections. Before anyone talks pricing, walk the building and the configuration and account for:

  • Extensions and DIDs. Export the full user list and the block of direct-inward-dial numbers, then reconcile it against your carrier's records. Disconnected DIDs still on the account cost money every month and complicate the port later.
  • Call flows and after-hours behavior. Auto-attendant menus, hunt groups, ring-no-answer paths, holiday schedules, and the "press 0 reaches the front desk" logic all have to be rebuilt by hand. Screenshot every menu tree before you lose access to the admin console.
  • Analog endpoints. Fax machines, credit-card terminals, fire and burglar alarm panels, elevator emergency phones, gate callboxes, and postage meters. These are the lines that get forgotten and then fail an inspection. An elevator phone that goes silent is a life-safety violation, not a help-desk ticket.
  • Paging and overhead. Warehouse, retail, and school sites often wire an overhead speaker system into a specific analog port on the PBX. Note the port, the amplifier model, and whether it uses a loud-ringer trigger or a zone-paging interface.
  • Voicemail and greetings. Cloud platforms do not import legacy voicemail boxes or recorded prompts. Decide what needs saving, re-record the greetings that matter, and set a date after which old messages are gone.

Number Porting Is the Long Pole

Porting your main number and every DID away from the old carrier is the single item most likely to blow a timeline, so it drives the schedule. Local number ports commonly take one to four weeks once accepted, and a request is only accepted when the Letter of Authorization matches the losing carrier's account record exactly. A mismatched service address, an outdated authorized contact, or a pending account change gets the whole port rejected, and the clock restarts. Our number porting guide covers how to pull a current Customer Service Record and clean these details up before you submit.

Avoiding the Porting Gap

The failure mode everyone fears is the porting gap: the old system is torn out on Friday, the port completes Monday, and calls to your main line vanish over the weekend. Avoid it by never letting the two events collide: keep the legacy system and its trunks fully live until the port confirmation lands, and provision your new cloud numbers as temporary DIDs so the platform is already answering calls. On port-completion day the number follows the routing you already tested. Nothing gets decommissioned until the port is confirmed in writing.

The Devices That Cannot Move

A cloud phone platform speaks SIP over your data network. Fax machines, alarm panels, and overhead paging do not, and bridging that gap separates a clean cutover from outages two weeks later.

  • Analog telephone adapters (ATAs). Each stranded analog device connects to an ATA or a multi-port analog gateway, which presents a standard RJ11 jack on one side and registers to the cloud platform on the other. Size it to your port count with room to spare, and confirm the platform certifies the model. Faxing over IP is notoriously fragile; where a machine must stay, use a T.38-capable ATA and test real documents, or move the workflow to a dedicated e-fax service instead.
  • SIP trunks and on-prem survivability. Most sites move fully to the carrier-hosted platform, but if you keep an on-prem session border controller or an analog gateway for life-safety lines, those ride SIP trunks you must provision, size, and secure. If that plumbing is unfamiliar, our explainer on how SIP trunking works covers registration, concurrent-call sizing, and where trunks fit a fully cloud deployment.

Fix the Network Before You Touch the Phones

Legacy PBX audio traveled on dedicated station wiring, isolated from your data traffic by design. Cloud voice shares the same LAN and internet circuit as everything else, so a network that was "fine" for email will produce choppy audio, one-way calls, and dropped connections the moment it carries voice. Finish this before go-live, not after complaints start. Verify enough upstream bandwidth for peak concurrent calls, mark voice traffic with DSCP, and set your switches and firewall to honor priority queuing so a large file upload cannot starve a live call. Our guide to QoS for VoIP details the marking and queuing; treat it as a prerequisite, not a tuning step for later.

Run Both Systems in Parallel

The lowest-risk cutover overlaps the two platforms instead of swapping them in one motion. Deploy new handsets alongside the old ones, point temporary DIDs and a pilot group at the cloud system, and let a real department run its daily calls on it for a week. This flushes out the misconfigured hunt group and the paging port wired to the wrong zone while the legacy system still stands behind you as a fallback. Users also get hands-on time before their extension depends on it, turning training into muscle memory.

The Cutover Weekend Runbook

Schedule the final cutover for your lowest-traffic window and work from a written runbook with named owners and rollback triggers. The sequence that holds up: confirm the port has completed, repoint main-line routing to the cloud platform, place test calls inbound and outbound from every site, verify each analog gateway leg one device at a time, and only then power down the legacy controller. Two things get people hurt if skipped. First, register E911 for every location and every remote user so an emergency call reports the correct dispatchable address; a softphone in a branch office will otherwise route a 911 call to the wrong county. Second, keep the old system powered and its trunks intact for several days, so if something critical breaks you revert routing to the legacy PBX in minutes. Decommission the hardware only after a clean business cycle.

The Bottom Line

A legacy PBX cutover is risky not because cloud phones are hard, but because the old system hides a decade of analog tails, undocumented call flows, and porting details that surface only under pressure. Inventory everything, let the port drive the schedule, fix the network first, and overlap the two systems with a real rollback path. Done in that order, the migration is invisible to your callers, which is exactly the point. If you want a partner to run the discovery and own the cutover weekend, our unified communications team does this work end to end. Start a conversation through our contact page or call 850-338-6503, and we will map your current system before anyone quotes a replacement.