Microsoft 365 tenant-to-tenant migration: method and lessons learned

When a tenant-to-tenant migration becomes unavoidable

A Microsoft 365 tenant-to-tenant migration is never a project you take on for fun: it's almost always the consequence of a corporate event. A merger, an acquisition, a spin-off, an exit from a group, a restructuring, a major rebrand, or consolidation after several years of growth through acquisition.

Unlike an on-premises-to-M365 migration - where Microsoft's tooling is mature and well documented - migrating between two Microsoft 365 tenants remains a high-risk exercise. Microsoft doesn't provide a complete native tool: you have to combine several third-party solutions and accept trade-offs on certain features (Teams chat history, OneNote shared notebooks, some SharePoint metadata).

The 6 phases of a successful tenant-to-tenant migration

Whatever the size of the project - from 50 to 50,000 users - we always break the migration into six phases. Skip a phase and you're guaranteeing a major incident.

• Phase 1 - Scoping and inventory (2 to 4 weeks): audit both tenants and map the objects to be migrated (mailboxes, SharePoint sites, Teams teams, OneDrives, security groups, service accounts, registered applications).
• Phase 2 - Target architecture and tool selection (1 to 2 weeks): decide on identity (coexistence, AD merge, target AD Connect), choose the main migration tool (BitTitan MigrationWiz, Quest On Demand Migration, ShareGate, AvePoint Fly), and define the DNS cutover schedule.
• Phase 3 - Coexistence and pilot (2 to 4 weeks): set up cross-tenant free/busy, shared SMTP routing, and an intermediate routing domain, then run a pilot migration on 20 to 50 representative users.
• Phase 4 - Main wave (2 to 8 weeks depending on size): migrate in waves of 100 to 500 users, usually over weekends. Cut over the MX records once the final wave is complete.
• Phase 5 - Cleanup and hand-over (2 to 3 weeks): remove source objects, remove cross-tenant shares, lock down the new tenant, and hand over documentation.
• Phase 6 - Post-migration support (4 to 6 weeks): reinforced help desk, support for edge cases, and resolution of items that didn't migrate (often 1 to 3% of the volume).

The tools we use

Our go-to tool is AvePoint Fly: it covers the full scope of a tenant-to-tenant migration — Exchange mailboxes, OneDrive, SharePoint sites (preserving metadata, versions, and inherited permissions), and Teams end to end, including chat history (limited to the last 30 days on the Microsoft API side) and tabs. Being able to migrate everything from a single platform simplifies the project and reduces the risks that come with stitching multiple tools together.

Depending on the client's preferences and ecosystem, we also work with other proven solutions, on their own or as a complement:

BitTitan MigrationWiz: robust and scriptable for Exchange mailboxes and OneDrive, with excellent error handling.

Quest On Demand Migration and ShareGate: especially strong on SharePoint, preserving metadata, versions, and inherited permissions.

For identity, the target AD Connect has to be planned as early as phase 2. If you're merging on-premises AD, budget an extra 4 to 8 weeks for the forest restructure (ADMT, Quest Migration Manager).

The critical things to watch for

Across 30 tenant-to-tenant projects over the past 4 years, here are the recurring pitfalls:

• DNS and email coexistence: a bad MX record for 4 hours means thousands of lost emails. Always plan for a temporary routing domain (e.g., contoso-mig.onmicrosoft.com).
• Service accounts and registered applications (Azure AD App Registrations): often forgotten. Every third-party integration (CRM, ERP, e-signature) has to be re-authorized in the target tenant.
• Teams Phone (Direct Routing, Calling Plans): requires a full re-subscription, and sometimes re-acquiring the numbers through the carrier. Lead time of 2 to 6 weeks depending on the carrier.
• Purview sensitivity labels: they don't migrate. They have to be recreated in the target tenant before document migration begins, or the files end up with no label.
• Classic Stream (deprecated in 2024) and Yammer/Viva Engage: separate exercises - plan them on their own.
• Licensing: double-paying is unavoidable for 4 to 12 weeks (both tenants active at the same time). The budget has to account for it.

Field notes: 4,000 users in 12 weeks

A recent engagement is a good illustration of how this plays out. A Québec group consolidating three entities (4,000 users in total) into a single tenant. Three sources, one target. Volume: 18 TB of OneDrive, 240 SharePoint sites, 380 Teams teams, 4,200 mailboxes.

Timeline: 4 weeks of scoping and architecture, 2 weeks of piloting on 80 users, 4 cutover waves of 1,000 users each spread across 4 consecutive weekends, and 2 weeks of cleanup and reinforced support. Total: 12 weeks.

Post-migration user incident rate: 2.8% (resolved in 48 hours on average). Zero document data loss. Three mailboxes had to be re-migrated manually due to source Exchange corruption.