Migrate Teams Voice tenant to tenant (M&A)

Senior Member

Hello, All.  I have been tasked with migrating Teams Voice from one tenant to another, due to a recent M&A.  While I'm not new to Microsoft 365, I have not really been involved in many M&A activities, so I'm not sure what's needed, things to look for, how to migrate, etc.

Any help where to start or where I can find some information, concerns, or anything else, would be extremely helpful.

I've tried searching Google but all I can find is info on Teams as a whole, and little to nothing related to Teams Voice.

I apologize for being vague as I'm not sure where to start so if there's something more I can provide to help my case, please let me know.

Thank you.

1 Reply
best response confirmed by thecomputerguy74 (Senior Member)

@thecomputerguy74 The last I checked, existing "Teams migration" tools only migrate collab related data, not voice data (Quest/BinaryTree/BitTitan/etc). As a result, you are effectively looking at a net-new greenfield deployment into whatever tenant is the destination (assuming you are going from your tenant to another, of which the destination is not currently using Teams for voice). Look at tools like the Microsoft365DSC or Backup-TeamsConfig or BackupRestoreTeamsEV to export your existing voice configuration (dial plans, PSTN Usages, routes, etc), then you could use those same tools to import into the destination after some fiddling.


If you're using Direct Routing, you'll have to deal with the fact that you will need to edit the FQDN of the SBCs in your voice routes since you cannot have the same FQDN (or DNS Domain) exist in two tenants at the same time. This will mean you can update the FQDNs in your tenant configuration ahead of time, but you'll have to have a "cutover" event to update your SBCs/DNS if you aren't able to figure out how to support multiple domains within a single SBC.


If you're using Calling Plans, you'll have to deal with the fact that you will need to request MSFT to move the DIDs between tenants. The numbers must be unassigned from users, then moved, then reassigned - so be prepared for some downtime.