Migrating from a legacy PBX to Teams Phone: approach, sequencing and coexistence

What it does

The plan for getting users, numbers and call flows off an on-premises or hosted PBX and onto Teams Phone: big bang or phased, site by site or persona by persona, and how the old and new systems talk to each other while both are live.

Key facts

Direct Routing connects your own telephony infrastructure, including third-party PBXs and analogue devices, to Teams Phone through a Microsoft-certified SBC. It's the supported way to trunk Teams and an existing PBX together during coexistence.
Only Microsoft-certified SBCs are supported. The SBC needs a public IP, a public DNS FQDN on a tenant-registered domain and a certificate from a CA in the Microsoft Trusted Root Program.
SIP signalling uses TLS on port 5061 to Microsoft; media uses UDP 3478–3481 and 49152–53247. Failover to the nearest healthy Microsoft datacentre is automatic.
Direct Routing can run alongside Calling Plans, Operator Connect and Teams Phone Mobile in the same tenant, so the end-state PSTN model doesn't have to be Direct Routing.
Users moving to Teams Phone need TeamsOnly mode, a Teams Phone licence and a PSTN option; Direct Routing users also need an online voice routing policy.
Porting into Calling Plans typically takes 7–14 days and up to 30. Port orders for the same carrier account run one at a time, a target date can't be more than 30 days out, and a frozen carrier account rejects the order.
Microsoft can't currently port UK non-geographic numbers (0843, 0844, 0845, 0870, 0871, 0872) into Calling Plans.
Survivable Branch Appliance keeps PSTN calling working on Teams desktop clients and Teams phones during an internet outage at a Direct Routing branch. It needs media bypass on the SBC and doesn't support emergency call routing policies or location sharing.

When to use / skip

Big bang works for single-site or small multi-site organisations with one number range and one carrier: port everything on a weekend, have floorwalkers in on Monday, done. It avoids coexistence entirely, which is the single biggest source of cost and complexity in a PBX migration. If the client is under a few hundred users and the PBX has no exotic integrations, push for it.

Phased migration is the norm for anything larger, and the right way to phase is usually by number range and site, because that's how carriers and porting work. Phasing by department across sites sounds tidy but means extension dialling across two platforms for months. The cleanest coexistence pattern is an SBC sitting between the carrier, the legacy PBX and Teams — numbers stay on the existing trunk, and the SBC routes per number to whichever platform the user is on. Moving a user becomes a routing change and a licence assignment rather than a port. If the end-state is Operator Connect or Calling Plans, the SBC is temporary scaffolding: you port the ranges once the last user on each has moved.

Skip the whole "keep the PBX for the call centre and receptions" compromise unless there's a firm date to retire it. It becomes permanent, and you'll be supporting a PBX, an SBC and Teams with half the knowledge of each.

Configuration decisions

Approach: big bang vs phased. Phased by site/number range is usually safer than phased by department.
Coexistence design: SBC between carrier, PBX and Teams; or PBX as the front end with a SIP trunk to an SBC; or no coexistence at all.
End-state PSTN model, decided up front: Direct Routing permanently, or Operator Connect/Calling Plans with Direct Routing only for the migration and the leftovers.
Number porting plan: which ranges, which carrier, in what order, with the billing account number (BTN) and contract terms confirmed per range.
Dialling plan: four-digit extension dialling across both platforms during coexistence, via Teams dial plans and SBC normalisation.
Non-user endpoints: analogue lines, lifts, alarms, door entry, fax, franking — kept on analogue gateways behind the SBC, moved to a separate provider, or retired.
Survivability: SBA at sites where an internet outage must not stop PSTN calling, or acceptance that outages fall back to mobiles.
Call flows: rebuild hunt groups and IVRs as auto attendants and call queues, or move them to a contact centre platform.

Gotchas

Contact centre and reception call flows always contain undocumented logic. Get call flow exports or recordings of the IVR before the PBX engineer leaves.
Port orders for the same carrier account process one at a time. Submitting five sites at once means four rejections and a week lost.
A carrier account freeze rejects the port, and lifting it can take one to three weeks. Check this at the start, not the week of cutover.
UK non-geographic numbers can't go into Calling Plans. They stay with a carrier or move via Operator Connect or Direct Routing.
Emergency calling during coexistence is two systems with two location models. Users on Teams need emergency addresses and network sites before cutover, not after.
SBA doesn't support emergency call routing policies or location sharing. Don't sell it as full 999 resilience.
Analogue and alarm lines are always forgotten. Walk the building with facilities and count the grey boxes.

Consultant notes

Front-load discovery: PBX config export, number ranges by carrier account, contract end dates, analogue inventory, and every hunt group and IVR. This takes longer than the migration.
With the UK's all-IP switchover approaching, ISDN-heavy sites have a hard deadline. Use it to prioritise sites rather than fight it.
Pilot with IT and a friendly department on real numbers through the coexistence SBC. Test transfers, extension dialling and voicemail both ways.
Plan the porting calendar backwards from contract end dates, then add the 30-day porting worst case.
Write a decommissioning date for the PBX and SBC into the project charter. Without one, coexistence is forever.
Train receptionists and queue agents separately and in person. They feel the change most and generate most of the hypercare tickets.

Revisit when the UK all-IP switchover date firms up, or if Microsoft extends UK porting to non-geographic numbers