Teams Phone migration: what to settle before you port your numbers

Moving an office phone system into Microsoft Teams is usually sold as a licensing decision. In practice it is a telecom project with a fixed cutover moment: the point at which your published numbers stop ringing on the old system and start ringing in Teams. Everything that goes wrong in a Teams Phone migration tends to go wrong at that moment, and almost all of it is decided weeks earlier.

This guide is for owners and IT leads at small and mid-sized Canadian organisations who have decided, or nearly decided, to move calling into Teams. It covers the four decisions that shape the project, the checks worth completing before a port date is booked, and a cutover plan that keeps a way back.

Decision one: how Teams reaches the phone network

Teams Phone on its own does not connect to the public telephone network. Each user needs a Teams Phone licence and a connection to the public switched telephone network (PSTN) from a provider. Microsoft documents four ways to supply that connection, and a single tenant can use more than one of them.[1]

• Microsoft Calling Plan. Microsoft acts as the carrier: numbers, PSTN access and support come from Microsoft. It is the simplest model to deploy and manage.
• Operator Connect. A participating carrier has already integrated with Microsoft. You contract with that carrier and assign its numbers to users in the Teams admin center.
• Teams Phone Mobile. A participating mobile operator lets a user's mobile SIM number also be their Teams number. It supports user numbers only, not auto attendant, call queue or audio conferencing numbers.
• Direct Routing. Any carrier, connected through a certified session border controller that you, an integrator or a hosted provider operates. It is the most flexible option and the one with the most to maintain.

For most small offices the realistic choice is between a Calling Plan and Operator Connect. Direct Routing earns its complexity when you need to keep an existing carrier contract, integrate with equipment that must stay, or handle unusual routing. Microsoft explicitly supports mixing models, for example Calling Plans for most staff and Direct Routing for one site with special requirements.[1]

Questions that settle the choice

• Do you want one vendor for calling, or to keep a carrier relationship you already value?
• Do your main line, auto attendant and call queue numbers need to move, or only user numbers? That rules Teams Phone Mobile in or out for those numbers.
• Who will support the service when a call fails: Microsoft, a carrier, or whoever runs the session border controller?

Decision two: whether the network is ready for real-time voice

Teams calls are sensitive to the same things that make any voice service sound bad: loss, jitter and latency. Microsoft's own network preparation guidance lists the checks that matter before a rollout, and several of them are commonly skipped in small offices.[2]

• Bypass the VPN for Teams traffic. Microsoft recommends split tunnelling so Microsoft 365 traffic goes directly to the service rather than hair-pinning through a VPN concentrator. VPNs are often not built for real-time media and some do not carry UDP well.[2]
• Keep NAT mappings stable. Firewalls should not change the translated address or port of a UDP session mid-call, and the NAT pool needs enough public addresses to avoid port exhaustion.[2]
• Prioritise voice with QoS on every segment of a managed network, including Wi-Fi Multimedia on wireless. Microsoft notes that QoS helps even where bandwidth is adequate, because it protects calls during unexpected congestion.[2]
• Plan Wi-Fi for voice, not just coverage: favour 5 GHz, avoid overlapping channels between neighbouring access points, and consider band steering on dual-band networks.[2]
• Allow WebSocket connections, which Teams uses for call signalling and notifications. Blocking them forces a slower fallback.[2]

Microsoft publishes per-endpoint bandwidth figures and notes that audio is prioritised over video when bandwidth is short.[2] Bandwidth is rarely the constraint for a small office; a firewall that inspects or re-maps voice traffic is a far more common cause of poor call quality. Our network segmentation guide for small and mid-sized organisations covers where voice traffic should sit in the design.

Decision three: emergency calling

This is the part of a Teams Phone project that should never be left to the last week. Every user needs a validated emergency address, and Microsoft recommends creating those addresses with the map search in the Teams admin center so they are formatted, validated and carry the geo code that dynamic emergency calling needs.[3]

Dynamic emergency calling goes further: the Teams client reports the network element it is connected to, such as a wireless access point, switch port or subnet, and the Location Information Service returns the matching emergency location. Microsoft states that Calling Plans, Operator Connect and Teams Phone Mobile partners provide dynamic emergency routing for users in the United States and Canada. Direct Routing has additional prerequisites, including an emergency routing service provider or an equivalent configuration on the session border controller.[4]

• Map every office, floor and subnet to an emergency location before cutover.
• Decide how staff who work from home confirm their location. Teams supports location sharing, and an emergency disclaimer banner can prompt users to confirm their address.[3]
• Configure security desk notifications if someone in the office should be conferenced into an emergency call.[3]
• Test emergency calling with the method your carrier supports before go-live, not after.

Treat emergency calling as a go-live gate. If emergency addresses are not validated and tested for every site and every remote-work pattern you support, the cutover date moves. No other readiness item carries the same consequence if it is wrong.

Decision four: how the numbers move

Keeping your existing numbers means porting them from the current carrier. The details below come from Microsoft's porting guidance for Calling Plans; Operator Connect and Direct Routing carriers run their own porting process, but the same constraints usually apply because they come from the carriers, not from Microsoft.[5]

• Collect the records first. The account number, authorised person, service address, business name and billing telephone number must match the losing carrier's records. In Canada the carrier's document of record is called an Equipment Record.[5]
• Group by account. One port request covers numbers with the same provider, account, billing number, number type and service address. Different combinations need separate requests.[5]
• Sequence requests on the same account. Carriers process one port request per account at a time; overlapping requests on the same account are rejected.[5]
• Allow Canadian lead times. Microsoft cites a minimum ten-day lead time for Canadian numbers, a typical losing-carrier response of five to seven business days, and a scheduled port time of 11:30 a.m. Eastern for Canadian numbers.[5]
• Do not cancel the old service early. Inactive or disconnected numbers cannot be ported, and a rejected port leaves you with nothing to fall back to.[5]
• Find the fax lines. Numbers used for faxing can be ported, but faxing does not continue in Teams. They need a separate solution.[5]

A cutover plan with a way back

Porting is the one step that is hard to reverse quickly, so the aim is to have everything else proven before the port date arrives.

1. Build first, port last. Licence users, create auto attendants and call queues, and assign temporary numbers. Staff can make and receive calls in Teams for a week or two while published numbers still ring the old system.
2. Pilot with a real group. Include someone who works remotely, someone on Wi-Fi only and whoever answers the main line. Their experience finds the network and call-flow problems a test account never will.
3. Write the call flows down. Business hours, holidays, overflow and after-hours routing for the main number. This is where most of the complaints after cutover come from.
4. Freeze changes before the port. No firewall, Wi-Fi or call-flow changes in the days before the port window.
5. Keep the old system running until every ported number has been test-called inbound and outbound, including the auto attendant path.
6. Watch call quality afterwards. The Call Quality Dashboard and the Teams admin center show whether problems are isolated to one user, one site or one network.[2]

Where this fits

A Teams Phone migration touches licensing, identity, the network, emergency calling and a carrier process with fixed lead times. None of these is difficult alone; the risk is in the dependencies between them. Our unified communications service covers carrier model selection, call-flow design and cutover planning, and our Microsoft 365 work covers the tenant, licensing and identity side the phone system depends on. If your phones live on the same network as everything else, the managed IT services page explains how ongoing support is structured.

If you are weighing a move to Teams Phone and want the plan checked before a port date is booked, contact HAI Consulting for a free initial consultation. We will look at your current numbers, network and call flows and tell you plainly what needs to be ready first.