Microsoft 365 tenant-to-tenant migration
Migrating from one Microsoft 365 tenant to another — the workloads, the tools, and the realistic timeline.
A tenant-to-tenant migration moves a Microsoft 365 estate from one tenant to another — typically after an acquisition, divestiture, or rebranding. It's one of the harder Microsoft 365 projects because everything moves at once: identities, mail, files, Teams, devices, licensing, and integrations.
What needs to move
Every workload has its own migration story:
- Identities — Entra ID users, groups, role assignments.
- Mailboxes — Exchange content, calendars, contacts, rules.
- OneDrive content — per-user file libraries.
- SharePoint sites — including underlying Microsoft 365 Groups and Teams sites.
- Teams — chats, channels, teams, settings.
- Group memberships and ownership.
- Sensitivity labels, retention policies, DLP, eDiscovery — re-published in the target.
- Compliance and audit logs — typically not migrated (a fresh start in the target).
- Devices — Intune-enrolled devices need re-enrolment.
- Licences — purchased on the target.
- Custom apps and Power Platform content — Dataverse, flows, apps.
- Email domain —
yourcompany.comcuts over at a defined point.
The challenge
Microsoft 365 wasn't designed to be split or merged. Most tenant-to-tenant migrations rely on third-party tools and significant project effort.
First-party tooling
Microsoft has added native tenant-to-tenant migration support over the past few years:
- Cross-tenant user data migration (Exchange and OneDrive) in the Microsoft 365 admin center — moves mailboxes and OneDrives between tenants.
- Cross-tenant SharePoint migration — site-level migration tool.
- Cross-tenant Teams migration — Microsoft's own tool, expanded coverage over time.
- Microsoft Entra cross-tenant synchronization — automated provisioning of users between tenants during co-existence.
These first-party tools are improving fast but typically can't yet cover everything end-to-end.
Third-party tools
The mature tools — Quest On Demand, AvePoint Fly, BitTitan MigrationWiz, ShareGate, CodeTwo — cover the full migration scope including Teams chats, Planner content, app permissions, and complex orchestration.
For non-trivial migrations (hundreds of users plus), a third-party tool plus an experienced partner is the usual answer.
A realistic timeline
A typical tenant-to-tenant migration plays out over months:
- Month 1: discovery — inventory both tenants, dependencies, integrations.
- Month 2: planning — target architecture, identity model, co-existence design.
- Month 3: tooling setup, pilot migration of a small group.
- Month 4–6: phased migration of users in waves, with co-existence in between.
- Month 6: cutover of the email domain to the new tenant.
- Month 7+: decommission of the source tenant, lessons learned.
For very large estates, this stretches to 12+ months.
Common pitfalls
- Underestimating co-existence complexity — most pain happens here, not during the moves.
- Domain cutover timing — coordinating MX changes and Outlook profile reset.
- Teams chat history — partial migration is the realistic expectation; users often lose pre-migration DMs.
- Devices — Intune re-enrolment is disruptive; staged carefully.
- External integrations — SaaS apps using SSO to the old tenant need re-onboarding.
When to consider MTO instead
If two tenants will remain logically separate but need to collaborate, Multi-Tenant Organisations (MTO) is now a credible alternative to full merger. See the MTO guide for details.
When the migration is truly necessary, plan it like the project it is — clear governance, clear cutover dates, clear comms, and a healthy contingency.