Teams Voice: How to Handle Incoming Calls Across Multiple Phone Numbers

If you have migrated to Microsoft Teams Voice from a legacy phone system — Cisco, Avaya, Mitel, or similar — there is a good chance you have landed on a specific and frustrating problem.

You have a block of old numbers that users were on. You have a new block of numbers you are moving them to. Both need to work simultaneously during the transition, and ideally long-term too. In Cisco, you solved this with a translation pattern. You assigned the new number to the user, created a pattern that mapped the old number to the new one, and both numbers reached the same person. Job done.

In Teams Voice, there is no direct equivalent of a translation pattern. Which leaves a lot of administrators doing what they have always done when a platform does not have the feature they need: building a workaround.

The most common workaround is to create a resource account with the old number, assign it to a call queue, and forward that queue to the user. It works. It is also clunky, hard to manage at scale, and consumes resource account licences for every single number you need to redirect.

So what are the actual options? Here is an honest breakdown.

Before we get into it. How are you managing your Teams estate across the globe? Our SPORTrack platform remotely monitors and managers every end point so that you can see the status of every device, everywhere in real time. Check out SPORtrack here 

Why Teams Voice Handles This Differently

Microsoft Teams Voice was not designed as a direct replacement for a traditional PBX. It was designed as a cloud-first telephony system built around users and policies, not number translation logic. That distinction matters because it explains why features that were standard in on-premise systems either do not exist or are implemented in a fundamentally different way.

In Teams, numbers are assigned directly to users or to resource accounts (which back call queues and auto attendants). There is no routing table in the traditional sense. There is no place to say 'when this number is dialled, send it to this other number.' The platform routes based on who or what holds the number, not based on pattern matching.

This is not a gap that Microsoft have overlooked. It reflects a different architectural philosophy. But it does create a real operational challenge for organisations mid-migration.

Option 1: The Resource Account and Call Queue Method (What Most People Are Doing)

This is the workaround most Teams admins land on, and it does work. The logic is:

1. Assign the new number directly to the user in Teams Admin Centre
2. Create a resource account and assign the old number to it
3. Create a call queue backed by that resource account
4. Configure the call queue to forward immediately to the user

Calling the old number hits the resource account, which hits the call queue, which routes to the user. From the caller's perspective, both numbers reach the same person.

Note: Resource accounts require a Teams Phone Resource Account licence, which is free. However, the old number still needs an active number assignment, and in some configurations a Teams Phone licence may be required on the resource account depending on your setup and calling plan type. Check your licence agreement.

The downside is scale. If you have 50 users each with an old number that needs to remain active, you are creating 50 resource accounts, 50 call queues, and 50 number assignments to manage. It is not sustainable as a long-term architecture, and it adds operational overhead every time a user leaves, changes role, or moves to a different number.

Option 2: Direct Routing with Number Manipulation at the SBC

If your organisation is using Direct Routing (i.e. you have your own SBC connecting your telephony carrier to Teams), this is the cleanest solution and the closest equivalent to what Cisco's translation patterns were doing.

The SBC — Session Border Controller — sits between your carrier and Microsoft Teams. It handles the SIP signalling for all inbound and outbound calls. Most enterprise-grade SBCs support number manipulation rules, which allow you to rewrite the called number before it is passed to Teams.

In practice, this means:

• A call arrives at the SBC addressed to the old number
• The SBC applies a manipulation rule that rewrites the destination to the new number
• Teams receives the call as if it were dialled to the new number and routes it to the user

From Teams' perspective, only the new number exists. The old number is handled entirely at the SBC layer before Teams ever sees it. This is architecturally much cleaner than resource account stacking, and it scales well — you manage number mappings in one place on the SBC rather than across hundreds of Teams admin objects.

Note: This approach requires access to your SBC configuration and familiarity with the specific SBC platform you are using (AudioCodes, Ribbon, Oracle, etc.). The syntax for number manipulation rules varies between vendors. Your telephony partner or SBC administrator will need to implement this.

If your organisation does not currently use Direct Routing, this is not a quick fix — it is a significant infrastructure decision. But if you are already on Direct Routing and not using SBC-level number manipulation, this is worth exploring seriously.

Option 3: Operator Connect with Carrier-Side Forwarding

If you are using Operator Connect (where your carrier is directly connected to Microsoft Teams via the Operator Connect programme), the number manipulation may be possible on the carrier side rather than within Teams.

Carriers that support Operator Connect often have their own number management portals or can configure forwarding rules at the network level. If a call is dialled to an old number, the carrier can redirect it to the new number before it even reaches Teams.

The feasibility of this depends entirely on your carrier and what their platform supports. Not all Operator Connect carriers offer this capability, and those that do may implement it differently. This is a conversation to have directly with your carrier's technical team.

Note: This approach keeps everything outside of Teams administration, which reduces Teams-side complexity. The trade-off is that you are dependent on your carrier's tooling and support processes to manage what are essentially internal business routing decisions.

Option 4: Auto Attendant as a Routing Layer

A variation on the resource account method that some organisations prefer for cleaner management is using an auto attendant rather than a call queue as the intermediary.

The setup is similar:

1. Assign the old number to a resource account
2. Create an auto attendant backed by that resource account
3. Configure the auto attendant to route directly to the user (without any menu or announcement if you want a seamless experience)

The difference is primarily administrative. Auto attendants give you slightly more flexibility in routing logic — for example, routing to different users based on time of day, or adding a brief announcement before connecting. If you are managing a complex transition with multiple rules, an auto attendant can be easier to maintain than a call queue.

That said, this still has the same fundamental scaling problem as Option 1. One resource account and one auto attendant per number is still one resource account and one auto attendant per number.

Comparing the Options

The Honest Answer

There is no single right answer here, but there is a clear hierarchy depending on your infrastructure.

If you are on Direct Routing and have access to your SBC configuration, SBC-level number manipulation is the right long-term approach. It is the closest functional equivalent to what Cisco's translation patterns were doing, and it keeps Teams clean.

If you are on Microsoft Calling Plans or Operator Connect without SBC access, the resource account and call queue method — while imperfect — is currently the most reliable native Teams option. Microsoft's architecture simply does not have a translation pattern equivalent built in at the platform level.

If you are managing this at scale, it is worth raising with your Microsoft partner or account team. Number management during migrations is a known pain point, and there may be roadmap features or licensing options relevant to your situation that are not widely documented.

What to Think About During Your Number Migration

Beyond the technical routing question, a few things are worth factoring in if you are mid-migration:

• Document every number mapping before you start. Old number, new number, user, department, call routing expectation. Do this in a spreadsheet before touching any Teams configuration.
• Decide on a sunset date for old numbers. Running both numbers indefinitely is a management overhead. Set a date, communicate it to users and external contacts, and decommission the old numbers when you are confident traffic has dropped off.
• Test every redirect before you tell users it is live. Call the old number from an external mobile, confirm it reaches the right person, and document the result.
• Check your number assignment costs. In some calling plan configurations, holding active assignments on old numbers has a cost implication. Understand what you are paying for before the migration drags on longer than planned.

Need Help With Your Teams Voice Setup?

Getting Teams Voice configured correctly, especially during a migration from a legacy phone system, is one of the areas where the gap between 'technically working' and 'properly implemented' is most expensive.

If you are working through a number migration or dealing with routing complexity in your Teams environment, SPOR can help. We work with organisations across the UK to design, implement, and manage Microsoft Teams Voice deployments that actually hold up in practice.

Get an instant estimate for your project: Check out our pricing estimator here