Cross-tenant migration tooling: what Microsoft moves natively, and the gaps you have to tool
The mistake teams make is treating cross-tenant migration as one product to buy. It is not. Microsoft moves some of it natively, badly wants you to think it moves the rest, and quietly leaves a few workloads for you to either tool around or lose on purpose.
New to cloud? CAMPUX is a free, build-first course. Start here →
Two companies merge, or one spins off, and someone hands you the job of moving people and their data from one Microsoft 365 tenant into another. This is part of the Azure tenant-to-tenant migration guide, and the first honest thing to say is that there is no single button. What exists is a spread of native capabilities that cover the common workloads well, a set of specific gaps that native tools handle poorly or not at all, and a decision — made per workload — about whether to use Microsoft's tooling, buy a third-party product, or write off some content as acceptable loss.
What Microsoft moves natively
The native story is stronger than it was a few years ago, and it covers the workloads that matter most. Microsoft ships cross-tenant tools for the three heavy hitters: mailboxes, OneDrive, and SharePoint. Cross-tenant mailbox migration runs through the Mailbox Replication Service and Exchange Online PowerShell — the same New-MigrationBatch path admins already know — and moves the user-visible content: email, contacts, calendar, tasks, and notes. It needs a per-user migration license, and it expects each person to already exist in the target tenant as a MailUser. After a successful move the source mailbox is deleted, so this is a cutover, not a running sync.
On top of the individual workload tools, Microsoft now offers a Migration Orchestrator that runs mailboxes, OneDrive, SharePoint, and Teams together in coordinated batches and sequences the dependencies for you — mailboxes before the Teams content that leans on them, OneDrive and SharePoint together because they share a permissions model. For identity, there is cross-tenant identity mapping, which is how you tell the tooling that jsmith in the old tenant is the same human as john.smith in the new one.
Where cross-tenant synchronization actually fits
People reach for cross-tenant synchronization expecting it to carry data, and it does not. Microsoft is blunt about this: it is not a migration tool, because the source tenant is still required for synced users to authenticate. What it does is create and maintain B2B guest accounts across tenants automatically, so that during a phased move people in both tenants can find each other, share calendars, and collaborate. It is coexistence plumbing, not a moving truck. Use it to keep the lights on while you migrate in waves; do not expect it to relocate a single mailbox or file.
Cross-tenant sync keeps people working across both tenants. It never carries their data.
The gaps you have to tool around
Now the honest part. Native coverage thins out fast once you leave mail and files. The most infamous gap is Teams one-to-one and private chat history. Microsoft's Teams migration APIs exist, but they are slow — large migrations can run for weeks — and limited enough that most teams do not rely on them for chat. The common outcomes are to export chat to read-only HTML for reference, have a third-party tool recreate the threads in the target, or accept the loss and keep the source tenant readable for a retention window.
Intune device state is the second wall. Enrolled devices, compliance policies, and configuration profiles do not travel cross-tenant with the native migration tools; devices generally have to be re-enrolled against the target tenant, which is a coordinated end-user event, not a background copy. Beyond those two, some Purview content — sensitivity labels, retention artifacts — and Power Platform apps and flows sit outside the native cross-tenant path and need rebuilding, exporting, or a specialist tool. None of this means the migration fails. It means you decide, deliberately, what moves with fidelity and what does not.
Between the native tools and the third-party products sits PowerShell and Microsoft Graph, and you will write more of it than you expect. Identity mapping files, staging MailUser objects in the target, batching users, reading migration status, reporting on what moved — this is scripted work. Graph is also where you reach content the packaged tools skip. A realistic cross-tenant project is native tools for the heavy workloads, a third-party product for a specific gap, and a folder of your own scripts holding the whole thing together and proving what happened.
A plain way to decide
The heuristic is simple and it keeps you honest. Use native where it exists; tool the gaps; write down what you are choosing to lose. Walk the workloads in order. Mail, OneDrive, SharePoint, identity mapping — native, every time; the tools are supported and the licensing is predictable. Coexistence during a phased cutover — cross-tenant synchronization, because that is exactly its job. Teams chat history, Intune devices, Purview labels, Power Platform — stop and ask whether the business genuinely needs each one carried across. If yes, price a third-party tool against the effort of scripting it yourself. If no, document the accepted loss so it is a decision on the record, not a surprise in the post-migration review.
A separate note in this series compares the third-party tools directly, so I will not name vendors here — the point at this altitude is the shape of the landscape, not the logos. What matters is that you never buy a product to solve a problem native tooling already solves, and you never assume native tooling covers a workload it visibly does not.
The takeaway
Cross-tenant migration is a portfolio, not a product. Microsoft moves mailboxes, OneDrive, SharePoint, and identity mapping natively — and orchestrates them together — while cross-tenant synchronization handles coexistence and carries no data at all. The gaps are specific and known: Teams chat history, Intune device state, parts of Purview and Power Platform. Map each workload to native, third-party, or accepted loss before you touch anything, keep PowerShell and Graph ready for the glue, and you will run a migration that surprises no one. The engineer who can name what Microsoft covers and what it quietly leaves to you is the one who scopes these projects correctly.
Questions people also ask
Does Microsoft have a native tenant-to-tenant migration tool?
Partly. Microsoft ships cross-tenant tools for mailboxes, OneDrive, and SharePoint, plus a Migration Orchestrator that runs those workloads in coordinated batches. It does not natively cover everything — Teams chat history, Intune device state, and some Purview and Power Platform content fall outside those tools, which is where third-party products or scripted glue come in.
What does cross-tenant mailbox migration actually move?
Only user-visible content: email, contacts, calendar, tasks, and notes. It runs through the Mailbox Replication Service and Exchange Online PowerShell, needs a per-user migration license, and requires each user to already exist in the target tenant as a MailUser. After a successful move, the source mailbox is deleted, so this is a one-way cutover, not a coexistence sync.
Can you migrate Teams chat history between tenants?
Not cleanly with native tools. One-to-one and private chat is the notorious gap in cross-tenant work. Microsoft's Teams migration APIs exist but are slow and limited, so most teams either export chat to read-only HTML, have a third-party tool recreate it, or accept the loss and keep the source tenant read-only for a retention window.
Is cross-tenant synchronization a migration tool?
No. Microsoft is explicit that cross-tenant synchronization is not a migration tool, because the source tenant is still required for synced users to authenticate. It creates and maintains B2B guest accounts across tenants for coexistence and collaboration. You use it to keep people working across both tenants during a phased move, not to carry data across.
Do you need a third-party tool for tenant-to-tenant migration?
It depends on scope. If you only need mail, files, and identity mapping, native tools plus PowerShell can carry the whole job. The moment Teams chat history, Intune-managed devices, or Power Platform content have to move with fidelity, native coverage thins out and a third-party tool — or a deliberate decision to accept some loss — usually becomes the practical answer.