Microsoft 365 Migration Orchestrator: Tenant-to-Tenant Migration Explained

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. Our managed Microsoft 365 service includes full migration support for mergers, acquisitions, and reorganisations.

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.

If you would rather hand the whole move to a partner, our Microsoft 365 migration services cover tenant-to-tenant projects on a fixed scope and timeline, including the licensing analysis and identity mapping described below.

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:

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: the add-on is available on Microsoft 365 Business Basic, Standard and Premium as well as on Microsoft 365 F1/F3/E3/E5, Office 365 F3/E1/E3/E5, Exchange Online, SharePoint and OneDrive plans. Business tier licences do qualify, so smaller organisations no longer have to move to an enterprise plan first. Each user does need a Teams licence and an Exchange Online plan in both tenants.
• 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. It is charged as a one-time fee per user rather than a monthly subscription, and the licence can be assigned to either the source or the target user object.
• Global Administrator access on both source and target tenants is required to establish the cross-tenant relationship. The migration commands themselves run in the target tenant and can be issued by a Microsoft 365 Migration Administrator instead.

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:

1. Create the user account in the target Entra ID with the target domain UPN
2. Configure a MailUser object that points to the source mailbox for routing during coexistence
3. Assign the target licence
4. 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 from the target tenant through Microsoft Graph, and a batch holds at most 100 users. The Orchestrator syncs mailbox content incrementally, initial sync runs first, then delta syncs pick up new mail until the CompleteAfterDate you set on the batch triggers the cutover. OneDrive behaves differently: it does not move at all before cutover, and incremental or delta passes are not possible.

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.