In December 2025, Microsoft announced the public preview of the Migration Orchestrator, a native tool for moving user data between Microsoft 365 tenants. For anyone who has planned a tenant-to-tenant migration in the last few years, the significance of that is not lost. This space was left almost entirely to Independent Software Vendors (ISVs) for a long time, and the arrival of a Microsoft-native option changes the conversation.
I want to flag that two specific scenarios will block a migration if they are not identified during planning. I will cover them after the overview, because they make more sense once the pieces are in place.
What the Orchestrator Is
The Orchestrator is a PowerShell-driven orchestration layer that coordinates the migration of user-scoped workloads between tenants. It manages sequencing and dependency resolution internally, so admins do not need to track the order manually.
In the current public preview, the supported workloads are:
- Exchange Online mailboxes (emails, contacts, calendar, tasks, notes)
- OneDrive personal sites
- Teams chats (1:1, group, and meeting chat)
- Teams meetings
Batches of up to 2,000 users can be submitted at a time. All data movement stays inside the Microsoft boundary, which removes the third-party data handling concerns that compliance teams often raise during M&A projects.
Three migration models are supported: single-event (all users in one cut-over), phased (batches over time), and tenant split (a subset of users moves while the rest remain in the source). The split model is the most relevant for divestiture scenarios.
What Orchestrator Does Not Migrate
This boundary is important to set with stakeholders before planning goes too far. The orchestrator is a personal-workload tool. It does not migrate:
- Teams channels or team data
- SharePoint sites
- Shared mailboxes
- Auto attendants and call queues
- Teams Voice assignments, dial plans, and voice routing policies
- Conditional Access policies or Entra ID configuration
- Intune device enrolments or policies
- Power Automate flows
- App registrations
For SharePoint and shared OneDrive content, Microsoft provides separate dedicated cross-tenant migration tooling, but that is a distinct process requiring its own planning track. Everything else on the list needs to be rebuilt or re-applied manually in the target tenant.
The Orchestrator moves people’s data. It does not move the configuration estate.
Licensing
The Orchestrator requires the Cross-Tenant User Data Migration add-on license, assigned per user. It can be assigned on either the source or the target user object.
The license covers Exchange Online mailbox and OneDrive migration. During the current preview, Teams chat and Teams meeting migration require no additional license beyond the add-on.
The add-on is available as an attachment to most Microsoft 365 plans, including Business Basic, Standard, Premium, F1, F3, E3, E5, and equivalent Office 365 plans. GA pricing has not been published at the time of writing.
The license must be purchased and assigned before the migration job runs. Microsoft does not offer exceptions, and the migration fails at the validation stage if it is missing.
Identity Mapping Is Mandatory
Before any migration can run, every source user must be mapped to a corresponding target user through Cross-Tenant Identity Mapping (CTIM). This process stamps the source user’s ExchangeGuid onto the target user object, which is what the orchestrator uses to locate and match the correct mailbox.
If this mapping is missing, Teams chat and meeting migration cannot correctly resolve participants, and the mailbox migration has no valid target to write to.
Two Things to Check Before You Start
Check One: Which Mailboxes Are on Hold
The Orchestrator will not migrate a mailbox that is under any type of hold. Litigation hold, eDiscovery hold, in-place hold: all of them result in the migration being blocked for that user. The documentation is explicit: “Mailboxes on any type of hold aren’t migrated, and a move for those mailboxes is blocked.”
In practice, this creates a tension that is easy to underestimate. In many scenarios you have organisations with active legal matters, and the mailboxes most likely to need migrating quickly are often the ones most likely to be on hold.
The first thing to do, before any migration timeline is agreed, is run a full hold audit:
Get-Mailbox -ResultSize Unlimited | Where-Object {
$_.LitigationHoldEnabled -eq $true -or
$_.InPlaceHolds -ne $null
} | Select-Object DisplayName, LitigationHoldEnabled, InPlaceHolds
This gives a complete picture of blocked users before the project commits to a schedule. Presenting that list to legal and compliance early is far preferable to discovering it when the first batch fails.
Whether a hold can be lifted depends on the type. Retention policies applied at tenant or user level may be replaceable with equivalent policies on the target tenant, and lifting them from the source may be viable. eDiscovery holds are a different matter: if a mailbox is held as part of an active investigation, there is no migration path until the hold is released. That is a legal decision, not a technical one. Microsoft’s own guidance is to contact their engineering team before attempting to migrate any held mailbox.
Check Two: The License Assignment Sequence
This second scenario tends to surface when an onboarding team and a migration team are working in parallel without tight coordination.
The prerequisite is stated clearly in the Microsoft documentation: target users must not have Exchange Online mailboxes or OneDrive sites provisioned before the migration runs. The moment a Microsoft 365 license that includes Exchange Online is assigned to a target user, the mailbox provisions automatically, usually within a few minutes. Once provisioned, the migration for that user is blocked.
The correct sequence is:
- Create the target user account (cloud-only or synced from AD)
- Run CTIM to stamp the ExchangeGuid from the source user onto the target user
- Disable OneDrive creation for target users as a precaution
- Assign the migration add-on license
- Only then assign the full Microsoft 365 license
Step 2 is what prevents the auto-provisioning problem. When the ExchangeGuid is already present on the target user object, Exchange Online recognizes the account as a migration target rather than triggering a new mailbox provisioning request.
If the provisioning team has a habit of bulk-creating accounts and immediately assigning licenses, this needs to be a specific briefing point before the project begins. The sequence is not intuitive, and the remediation path if it goes wrong is not straightforward.
Final Observations
The Migration Orchestrator is a meaningful step forward. Native Teams chat and meeting migration without third-party tooling is genuinely useful, and keeping all data inside the Microsoft boundary is a real advantage during compliance-sensitive projects.
The preview state means details may change before general availability. The current scope remains limited to personal workloads, and shared data, voice infrastructure, and tenant configuration all sit outside it. Planning should reflect that from the start.
The two checks above are not edge cases. They will appear in most real M&A migrations, and identifying them during the discovery phase rather than during execution makes a measurable difference to how the project runs.
The official documentation is at Microsoft Learn: Migration orchestrator overview.
I hope this helps.
