Migrating Teams voice from Direct Routing to Operator Connect
By Emil Björk · Microsoft ecosystem consultant, Gothenburg
A runbook for moving Teams Phone users off a Direct Routing SBC and onto Operator Connect — choosing an operator, the port versus new-number decision, the per-user cutover that keeps calls flowing, emergency addresses, and finally switching the SBC off.
Direct Routing gave you control and a session border controller to look after. Operator Connect gives the operator the SBC and gives you a number list in the Teams admin center. The migration is, at its core, a change in where a phone number is assigned from — and because Teams lets a user hold exactly one number, the whole exercise is sequencing so that every user's number is live on one path at every moment. The background on both models is in calling plans and Operator Connect and the Direct Routing deep dive.
Step 1: pick the operator, and get the number question answered
Teams admin center → Voice → Operators lists the operators available in each country. Choose based on the countries you need (an operator must be present in each), and on the answer to the only question that decides the project's shape:
Can the operator port your existing numbers? If your Direct Routing numbers are on a SIP trunk from a carrier who is also an Operator Connect operator, they can often move the numbers from the trunk to Operator Connect without a port — an internal migration on their side. If the carrier is a different company, the numbers must be ported, which is a regulated process with its own timelines in each country, and the port date becomes your cutover date.
If porting is impossible or too slow, you get new numbers from the operator, and users change number. That is an organisational project (signatures, business cards, call-forwarding on the old numbers for a period) more than a technical one.
Sign the operator's agreement in the admin center. Operators need a few days to provision the tenant on their side.
Step 2: understand the constraint
A Teams user's LineUri comes from one of: Calling Plan, Operator Connect, or Direct Routing. Assignment is per user, so coexistence is natural — half the users on Direct Routing and half on Operator Connect is a supported, everyday state. What you cannot do is assign the same number from both. The migration is therefore per user, or per batch of users, and never a big-bang unless you want it to be.
The other constraint: emergency calling. Direct Routing users have emergency addresses via your own configuration; Operator Connect requires emergency addresses assigned per number and validated with the operator, because the operator is the one routing the emergency call. Build the emergency locations in Teams admin center before any number moves; see Teams emergency calling for the regulatory detail per country.
Step 3: prepare the Operator Connect side
Once the operator has provisioned the tenant:
- Numbers appear in Teams admin center → Voice → Phone numbers with the operator listed, either from the port or from a new order made in the operator's portal.
- Assign an emergency location to each number.
- Check that each number's usage is set correctly — user, conference bridge, auto attendant or call queue. Resource accounts for auto attendants and queues need Operator Connect numbers of the right type.
Do not touch the Direct Routing users yet. Nothing on the Operator Connect side affects them.
Step 4: pilot, then cut over in batches
For each user in a batch:
- Remove the Direct Routing number:
Remove-CsPhoneNumberAssignment -Identity user@contoso.com -RemoveAll. The user loses PSTN calling at this instant. - Assign the Operator Connect number:
Set-CsPhoneNumberAssignment -Identity user@contoso.com -PhoneNumber +4631123456 -PhoneNumberType OperatorConnect. - Remove the online voice routing policy that pointed the user at the SBC:
Grant-CsOnlineVoiceRoutingPolicy -Identity user@contoso.com -PolicyName $null. Leaving it in place is harmless for outbound routing when the number type is Operator Connect, but it confuses later troubleshooting. - Have the user restart Teams, then make an outbound call and receive an inbound one.
The gap between steps 1 and 2 is a few seconds if scripted. Batch by team so that a department's numbers move together, and never during the department's peak calling window. If the numbers are being ported rather than migrated on the operator's side, steps 1 and 2 happen at the port completion time the operator gives you, and inbound calls will land wherever the carrier routes them at that moment — usually a window of minutes to an hour where inbound may reach either path or neither.
Auto attendants and call queues follow the same pattern via their resource accounts. Move them last, after the users they route to.
Step 5: verify what nobody thinks to test
- Caller ID. Direct Routing often had per-user or per-policy caller-ID manipulation; Operator Connect presents the assigned number and the operator's rules. Check outbound caller ID to a mobile.
- Voicemail and call forwarding settings survive the number change, but simultaneous-ring targets that were internal PSTN numbers need re-checking.
- Dial plans. Normalisation rules that translated short codes for the SBC still apply, but any rules that existed only to satisfy the SBC's expected number format can go.
- Analogue devices, fax, alarm lines that were fed through the SBC. Operator Connect does not carry these; they stay on a trunk, move to the operator's own analogue offering, or get an ATA with its own SIP service.
- Call quality dashboard: watch the first week. Media now goes to the operator's infrastructure, and anything you had tuned for the SBC's location is gone.
Step 6: decommission Direct Routing
Once no user, resource account or device has a Direct Routing number:
- Remove the voice routes and PSTN usages that referenced the SBC, then the SBC itself (
Remove-CsOnlinePSTNGateway). - Cancel the SIP trunk with the carrier — after the porting is confirmed complete, not on the port date.
- Retire the SBC hardware or virtual appliance, and its certificate renewals and firewall rules.
Keep the routing configuration exported for reference for a while; nobody has needed one back, but it costs nothing.
Downtime and dependencies, honestly
Per user: seconds, scripted. Per batch during a number port: up to an hour of uncertain inbound routing at the port time, controlled by the carriers, not by you. Nothing requires Microsoft support; the operator is the party you will be waiting on, and their porting desk is the critical path. Get their timeline in writing before you announce a date.
Further reading
Spot something wrong or want a topic covered? Send it through the contact form.