Tenant-to-tenant migrations in Microsoft 365 have a reputation for being painful. When two companies merge, or when a business unit spins off into its own entity, the question of how to move email, files, and Teams data from one Microsoft 365 tenant to another used to require expensive third-party migration tools, months of planning, and a high risk of data loss or corruption.
Microsoft's Migration Orchestrator changes the picture. It is a native Microsoft tool — no third-party licence required — that handles the orchestration of cross-tenant workload moves with dependency awareness. This post covers what it actually does, what its limitations are, and the specific planning steps that determine whether a migration succeeds or fails.
When You Actually Need a Tenant-to-Tenant Migration
Not every scenario requires a full tenant migration. It is worth confirming which situation applies before starting:
- Merger or acquisition: Company A acquires Company B. Both have existing Microsoft 365 tenants. The goal is to consolidate into a single tenant.
- Divestiture or spin-off: A business unit separates from the parent company and needs its own Microsoft 365 tenant with its historical data.
- Rebranding with domain change: A company changes its primary domain and wants to migrate to a clean tenant rather than rename within the existing one.
- Partner company separation: A shared services arrangement ends and each entity needs its own independent environment.
If you are simply moving from a third-party email provider (Google Workspace, Zimbra, IMAP) to Microsoft 365, that is a different process — an initial tenant migration rather than a cross-tenant one. The Migration Orchestrator is specifically for Microsoft 365 to Microsoft 365 moves.
What the Migration Orchestrator Moves — and What It Does Not
Understanding the scope boundary is critical before you start. Here is what the Orchestrator handles:
✓ Supported Workloads
- Exchange Online mailboxes (email, calendar, contacts, tasks, notes)
- OneDrive for Business content (files and folder structure)
- Microsoft Teams chat history and meeting recordings associated with the migrated mailbox
- Mail routing coexistence during phased migrations via the MailUser stub object
✗ Not Supported
- Teams channels and team data — these remain in the source tenant
- SharePoint site content (beyond what is in individual OneDrive)
- User identities — you must create and configure users in the target tenant manually
- Security groups, Conditional Access policies, Intune configuration — all must be recreated
- Shared mailboxes and distribution lists — require separate migration steps
The most common misunderstanding is around Teams channels. When an employee is migrated, their Teams chat history moves with the mailbox. But the Teams channels — where the team's project conversations and shared files live — stay in the source tenant. This means post-migration, migrated users cannot access their old Teams channel content unless you establish a guest access arrangement or use a third-party tool for channel migration.
For many organisations, this is acceptable. For companies where Teams channels are the primary record of project work, it requires a more nuanced migration plan.
Licensing Requirements: What You Need Before You Start
The Migration Orchestrator is not free for all users. Licensing requirements are specific:
- Source and target tenant licensing: Both tenants must have Microsoft 365 E3, E5, or equivalent enterprise licensing. Business tier licences (Business Basic, Business Standard, Business Premium) do not qualify. This is a hard blocker for smaller organisations — if either tenant is on Business plans, they must either upgrade or purchase add-on licences temporarily.
- Cross-Tenant User Data Migration add-on: Each user whose mailbox or OneDrive you want to move requires a Cross-Tenant User Data Migration licence. This is a per-user add-on purchased through your Microsoft partner. The cost is around €5–8 per user per month, and you only need it for the duration of the migration project.
- Global Admin or Exchange Admin access on both source and target tenants is required to establish the cross-tenant relationship.
The Migration Process: Phase by Phase
Phase 1: Establish the Cross-Tenant Relationship
Before any data moves, administrators in both tenants must agree to the migration relationship. This involves configuring a Migration endpoint in the target tenant and authorising it from the source tenant. The process is documented in PowerShell and takes 2–4 hours for an experienced administrator. Both tenants must have appropriate licences in place before this step.
Phase 2: Identity Mapping and Pre-Migration User Creation
Every user being migrated must already exist in the target tenant before their data can move. This is the most labour-intensive phase. For each user, you need to:
- Create the user account in the target Entra ID with the target domain UPN
- Configure a MailUser object that points to the source mailbox for routing during coexistence
- Assign the target licence
- Map the source user's ExchangeGuid to the target MailUser object (this is the key identity link the Orchestrator uses)
For 50 or more users, this work should be scripted. Doing it manually for large populations is error-prone and slow.
Phase 3: Batch Migration
With identities in place, you create migration batches in the target tenant's Exchange Admin Center. The Orchestrator syncs mailbox content incrementally — initial sync runs first, then delta syncs pick up new mail until you trigger the final cutover. For OneDrive, the same incremental approach applies.
Batching strategy matters. Migrating the entire company in one event reduces coexistence complexity but creates a single point of failure. Phased batches by department or location allow you to address problems without impacting everyone.
Phase 4: Cutover and DNS Update
The cutover for each user involves completing the final delta sync, converting the MailUser to a proper mailbox in the target tenant, and updating DNS MX records to route new mail to the target. After cutover, the source mailbox converts to a forwarding stub so any mail sent to the old address is forwarded to the target during the transition period.
DSGVO Considerations During Cross-Tenant Migration
A tenant-to-tenant migration involves processing personal data — employee emails, calendars, documents. Under the DSGVO, this requires a legal basis and, in most M&A scenarios, a data processing agreement (Auftragsverarbeitungsvertrag) between the involved entities if one is acting on behalf of the other during the migration.
Practically, this means your migration project should include legal review of the data processing relationship, a data inventory of what is being moved, and documentation of the migration in your DSGVO processing records. Microsoft processes the data on your behalf under its Data Processing Addendum — the question is whether the receiving entity (target tenant owner) has an appropriate basis to receive that data.
For acquisition scenarios, this is typically covered by the acquisition agreement. For spin-offs, it requires explicit structuring before migration starts. Leaving it to after the migration creates regulatory exposure.
How IDE Solutions Can Help
We manage cross-tenant migrations from planning through post-migration validation. Our process covers licensing analysis, identity mapping scripts, coexistence configuration, phased batch execution, and the DSGVO documentation your legal team needs.
We have run migrations for companies ranging from 20 to 300 users. The most important investment is always in the planning phase — a well-documented migration plan prevents the issues that turn a three-week project into a three-month one.
Reference: Microsoft 365 Migration Orchestrator Documentation