Microsoft 365 Tenant-to-Tenant Migration in 2026: The Native Migration Orchestrator Changes the Game

TL;DR

• The Migration Orchestrator (Public Preview, December 2025) lets you migrate Exchange mailboxes, OneDrive content, and Teams chats through a single native orchestration layer — no third-party tool required for those workloads.
• SharePoint sites, Teams channels, and channel-connected content still need third-party tools today.
• Cross-tenant synchronization is not a migration tool — the source tenant is still required for those identities to authenticate. Don't confuse sync with migration.
• Migrate in waves by business criticality, not by org chart, and build security and compliance in from day one.
• The goal is not "moving email" — it is keeping the business running on day one.

The landscape just shifted

Tenant-to-tenant migration — moving users, mailboxes, files, and collaboration content from one Microsoft 365 tenant into another — has always been one of the harder projects in the IT calendar. Microsoft does not offer a one-click "merge tenants" button, so historically every serious migration leaned on third-party tooling.

That changed in late 2025. The Migration Orchestrator, released in Public Preview in December 2025, brought native orchestration to the workloads that matter most: Exchange mailboxes, OneDrive personal content, and Teams chats can now be migrated through a single orchestration layer without third-party tools. It is the most significant native improvement to cross-tenant migration in years.

The caveat is just as important: SharePoint sites, Teams channels, and channel-connected content still require third-party tools. So 2026 migrations are typically hybrid — native Orchestrator for mail/OneDrive/chat, plus a third-party tool for SharePoint and channel content.

First, kill a common misconception: sync ≠ migration

Before planning, internalize this: cross-tenant synchronization is not a migration tool. Cross-tenant sync automates creating, updating, and deleting Entra B2B collaboration users across tenants — but the source tenant is required for synchronized users to authenticate, and it does not turn an external B2B identity into a fully migrated native account. It also does not sync devices or contacts.

Use cross-tenant sync when two organizations need to collaborate. Use migration when one tenant must become the other.

What the Migration Orchestrator covers (and doesn't)

flowchart LR
    subgraph Native[Migration Orchestrator - native]
      A[Exchange mailboxes]
      B[OneDrive content]
      C[Teams chats]
    end
    subgraph ThirdParty[Still needs third-party tools]
      D[SharePoint sites]
      E[Teams channels]
      F[Channel-connected content]
    end
    Native --> Target[(Target tenant)]
    ThirdParty --> Target

Plan your tooling around this split from the start. A migration plan that assumes the Orchestrator covers SharePoint will hit a wall mid-project.

A wave-based migration framework

The approach that works best combines due diligence, a Day 1 plan by critical process, wave-based migration by criticality (not by org chart), and security/compliance from day one.

1. Inventory and due diligence. Catalogue users, licenses, mailboxes, OneDrive volumes, SharePoint sites, Teams, and dependencies. You cannot plan waves for content you have not counted.

2. Decide cutover vs. staged. Review the inventory to choose between a single cutover (smaller estates, simpler) and a staged migration (larger, lower-risk). Let data size and downtime tolerance drive the choice.

3. Build a Day 1 plan by critical process. Identify what must work on the first morning in the new tenant — the processes that, if broken, stop the business. Manufacturing, sales, logistics, and finance keep running is the bar, not "email arrived."

4. Migrate in waves by criticality. Group users by business function and risk, not by department on the org chart. Start with a low-risk pilot wave, learn, and scale.

5. Bake in security and compliance from the start. Apply Conditional Access, sensitivity labels, and retention in the target tenant before data lands — not as a cleanup pass afterward. (See our Entra tenant hardening checklist.)

Pitfalls that sink tenant migrations

• Treating it as "moving email." The risk lives in SharePoint permissions, Teams membership, shared mailboxes, and the integrations nobody documented.
• Assuming the Orchestrator covers everything. It does not cover SharePoint sites or Teams channels — budget for third-party tooling.
• Confusing sync with migration. Cross-tenant sync keeps the source alive; it will not decommission the old tenant.
• Migrating by org chart. Criticality, not reporting lines, should define waves.
• Leaving security to the end. Labels, DLP, and Conditional Access belong in the target tenant on day one.

Timeline expectations

A real tenant-to-tenant migration is a months-long program, not a weekend. Inventory and planning alone can take weeks; waves are scheduled around business cycles; and validation between waves is non-negotiable. Build in time for a pilot, a pause to learn, and a buffer for the workload (SharePoint, channels) that still needs third-party tooling.

The bottom line

2026 is the first year native tooling does real work in tenant-to-tenant migration: the Migration Orchestrator handles Exchange, OneDrive, and Teams chats, leaving SharePoint and channel content to third-party tools. But the tooling is the easy part. The discipline that determines success is unchanged — inventory thoroughly, separate migration from cross-tenant sync, plan Day 1 by critical process, migrate in waves by criticality, and build security in from the start. Get those right and the tools will carry you across.

Further reading

• Microsoft 365 tenant-to-tenant migrations (Microsoft Learn)
• What is cross-tenant synchronization in Microsoft Entra ID? (Microsoft Learn)
• Microsoft 365 Mergers & Acquisitions Guide: Tenant-to-Tenant Migration

Image credit: Joël van der Loo via Wikimedia Commons (CC BY-SA 4.0).