Microsoft 365 tenant-to-tenant migration

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.

Migration has a family of guides: from Google Workspace, from on-premises Exchange, from file shares, the organisational side in Microsoft 365 after an acquisition and tenant rebranding, and the in-place moves Entra Connect to Cloud Sync and Direct Routing to Operator Connect. Multi-Geo is sometimes the alternative to a migration.

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.com cuts 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.