Microsoft 365 Tenant-to-Tenant Migration

The typical triggers

A Microsoft 365 tenant-to-tenant migration is never a project you launch on a whim: it's almost always the consequence of a business event. Understanding the trigger matters, because it shapes the constraints - timeline, budget, brand image and change management.

• Merger and acquisition: consolidating two or more tenants into a target tenant, often within the first 12 months after the deal closes.
• Carve-out or divestiture: extracting part of an existing tenant into a new, standalone tenant.
• Exit from a group: a subsidiary bought by an outside shareholder that has to leave the group's tenant.
• Internal restructuring: consolidating several legacy entities under a new corporate structure.
• Major rebranding: moving to a new primary domain name - a chance to start fresh.
• Pressure on Microsoft 365 SKUs or costs: consolidating to optimize licensing.

Why it's harder than an on-premises migration

Unlike an on-premises Exchange to Microsoft 365 migration, where Microsoft's tooling is mature and well documented, Microsoft doesn't offer a complete native tool for migrating between two Microsoft 365 tenants. You have to combine several third-party solutions, accept trade-offs (limited Teams chat history, some SharePoint metadata lost) and orchestrate coexistence by hand.

The other layer of complexity: a tenant-to-tenant migration touches more than mailboxes. It touches the entire Microsoft Graph ecosystem - SharePoint, OneDrive, Teams, Planner, Stream, Yammer, Power Platform, Dynamics, registered applications and service accounts. Each service has its own migration mechanics and its own limits.

Phase 1 - Scoping and inventory (2 to 4 weeks)

Scoping is the most critical phase, and the one that's most often under-resourced. This is where you document exactly what's going to move.

• Audit of both tenants: licensing, configurations, Conditional Access policies, MFA, Defender, Purview.
• Exhaustive inventory of objects: mailboxes (size, type, archive enabled), SharePoint sites, Teams (with tabs, channels, apps), OneDrives, security groups, Microsoft 365 groups, service accounts, registered Entra ID applications.
• Mapping of third-party integrations: CRM (HubSpot, Dynamics, Zoho), ERP, e-signature (DocuSign), payroll tools, line-of-business applications.
• Identity decision: coexistence, AD merge, target AD Connect.
• Domain decision: new primary domain, email redirections, SSL certificates.

Phase 2 - Target architecture and tool selection (1 to 2 weeks)

Building on the inventory, the architect defines the target and chooses the tools. The main decisions:

• Target primary domain: keep it, merge it, or start new?
• Identity strategy: a greenfield Microsoft Entra ID target tenant, or an on-premises AD merge via ADMT/Quest?
• Migration tools: BitTitan MigrationWiz (mailboxes + OneDrive), Quest or ShareGate (SharePoint), AvePoint Fly (Teams).
• DNS cutover schedule and coexistence strategy (cross-tenant free/busy, shared SMTP routing).
• Governance during the transition: who creates objects in which tenant? change freeze?

Phase 3 - Coexistence and pilot (2 to 4 weeks)

Before any mass migration, set up coexistence so that users in both tenants can collaborate during the transition:

• Cross-tenant free/busy (cross-tenant calendar sharing): a user in tenant A can see the availability of a user in tenant B.
• An intermediate routing domain (e.g. contoso-mig.onmicrosoft.com) to avoid email loops during the transition.
• Configuration of MX, autodiscover, SPF, DKIM and DMARC for coexistence.
• A pilot migration on 20 to 50 representative users: one in sales, one in HR, one in finance, one executive, one manager, one intern, and so on.
• Measuring per-user migration times and identifying edge cases.

Phase 4 - Main wave (2 to 8 weeks)

The mass migration runs in waves of 100 to 500 users, typically over weekends. Each wave follows the same runbook:

1. 1Friday 6 p.m. - Final communication, change freeze on the source tenant.
2. 2Friday 10 p.m. - Mailbox migration kicks off (the final delta migration, with pre-migrations already completed in the preceding weeks).
3. 3Saturday 8 a.m. - Verify the migrations, escalate on error.
4. 4Saturday 2 p.m. - OneDrive delta migration, SharePoint delta migration.
5. 5Sunday 10 a.m. - DNS cutover for migrated users, send/receive test.
6. 6Sunday 6 p.m. - End-to-end validation, go/no-go call for Monday morning.
7. 7Monday 7 a.m. - Reinforced helpdesk, incident handling.

Phase 5 - Cleanup and hand-over (2 to 3 weeks)

Once the final wave is done, you clean up:

• Gradual removal of objects in the source tenant.
• Removal of cross-tenant shares that no longer serve a purpose.
• Final hardening of the target tenant: target Conditional Access, Defender, Purview, sensitivity labels.
• Knowledge transfer: runbooks, architecture, decisions, known dependencies.
• Decommissioning of the source tenant (sometimes kept read-only for 6 to 12 months for legal archiving).

Phase 6 - Post-migration support (4 to 6 weeks)

The project doesn't end at the final cutover. The next 4 to 6 weeks are dedicated to reinforced support:

A dedicated helpdesk with a tighter SLA on migration-related issues. Resolving edge cases: items that didn't migrate (typically 1-3% of the volume), corrupted mailboxes to re-migrate by hand, Teams chats to partially rebuild. Monitoring the stabilization of third-party integrations (CRM, e-signature, payroll).