Microsoft 365 tenant-to-tenant migration: what breaks first

Tenant-to-tenant migration arrives with a merger, a divestment or a rebrand, and it is consistently underestimated. The reason is that people scope it as a mailbox migration, which is the part with mature tooling and predictable timings.

The hard constraint is elsewhere: a verified domain can exist in exactly one tenant at a time. Everything difficult about this work follows from that single fact.

The problem the constraint creates

To move contoso.com from tenant A to tenant B, you must remove it from A before adding it to B. Between those two events, nothing can receive mail at that domain and nobody can sign in with a UPN using it.

That window is the whole project. Compressing it is the design objective, and every decision below is really a decision about how short you can make it and what you are willing to run in parallel on either side.

It also means a gradual per-user migration of the primary domain is not possible in the way people assume. You can migrate users gradually; you cannot have half the users authenticating with contoso.com in tenant A while the other half use it in tenant B.

Design choices

The big-bang cutover

Move everything, cut the domain, done. Shortest total project, largest single event, and the highest risk concentrated into one weekend.

This is the right answer for small organisations — a few hundred users, straightforward workloads, a business that can tolerate a weekend of disruption. It becomes indefensible quickly as size and workload complexity grow.

Staged migration with a temporary domain

Users move in waves to a temporary domain in the target tenant, and the real domain is cut over at the end. This spreads the mailbox work and shortens nothing about the domain cutover itself.

The cost is real and it is mostly human: for a period, migrated users have a different email address. Mail sent to their old address must route correctly, and their external correspondents see something unfamiliar. Plan the routing and the communication, because both are where this design generates tickets.

Coexistence, then cutover

The most work and the least disruption. Establish cross-tenant collaboration first — shared calendars and free/busy, Teams federation, cross-tenant access settings — so the two organisations can work together before any mailbox moves. Then migrate in waves behind that coexistence, and cut the domain last.

This is what I would aim for in any organisation large enough that a weekend outage is not acceptable. It is also the design most likely to be abandoned partway, because it requires sustained attention from both tenants’ administrators, and in a merger those are frequently two teams with different priorities.

What actually breaks, in the order you will meet it

Identity, first and worst. Every user needs an account in the target tenant. If both organisations run directory synchronisation from Active Directory, you have two source directories and a decision about which is authoritative — and possibly an Active Directory migration underneath the Microsoft 365 one. The source anchor question from hybrid identity failure modes is directly relevant, because objects recreated rather than matched become new identities.

Licensing. Licences do not transfer between tenants. The target tenant needs its own subscriptions, provisioned and assigned before migration, and there is a period of paying twice. Budget for the overlap explicitly.

Mailbox data. The well-tooled part. Content migrates reliably; what does not migrate cleanly is the surrounding configuration — delegate permissions, shared mailbox access, inbox rules referencing old addresses, and calendar items with embedded meeting links.

Teams. Consistently the hardest workload. Chat history, channel content, private channels, apps, meeting recordings and the external sharing relationships all have different migration characteristics, and some have none. Establish early what genuinely cannot move, and get a business decision on it rather than discovering it during the cutover.

SharePoint and OneDrive. Content moves; permissions, sharing links and versioning are more complicated. Every externally shared link breaks, because the link contains the tenant. For an organisation that shares heavily with clients, this is a communications project of its own. The sharing posture in the target tenant is worth deciding deliberately rather than inheriting — see SharePoint and OneDrive sharing defaults.

Devices. Entra-joined and Intune-enrolled devices are registered to a tenant. Moving them generally means re-enrolment, and in many cases a rebuild. For a large estate this is the longest-duration workstream and it is frequently discovered late.

Applications and service principals. Every enterprise application, app registration, consent grant and certificate must be recreated in the target tenant. Nothing carries over. Applications integrated with the old tenant’s identity need reconfiguring, and each one has an owner you must find.

Everything keyed to the tenant. Conditional Access policies, Purview configuration, Defender policies, retention settings, DLP rules, custom roles, PIM configuration. All of it is rebuilt.

The sequence that works

1. Discover both tenants properly. Users, licences, mailboxes and sizes, Teams, sites, devices, applications, domains, and — critically — external sharing relationships.
2. Decide the target design first. Do not replicate the source tenant’s configuration by default. A migration is the only realistic opportunity to fix a configuration nobody would choose again.
3. Establish cross-tenant collaboration if you have chosen coexistence.
4. Provision identities and licences in the target, with a pilot group.
5. Migrate a pilot wave, and treat it as a genuine test rather than a formality. The pilot should include someone with delegate access, someone with heavy external sharing, and someone with a managed device.
6. Migrate in waves, keeping people who work together in the same wave. Splitting a team across the cutover generates far more disruption than the size of the team suggests.
7. Cut the domain, in the shortest window you can achieve. This needs to be rehearsed.
8. Reconfigure what is keyed to the domain — email authentication records, application redirect URIs, anything with the domain in a configuration file.
9. Decommission the source tenant deliberately, after a retention period agreed with legal.

Validation

Validate per wave, not only at the end:

• Migrated users can sign in, reach mail, and see their calendar with delegate access intact.
• Mail flows to and from external correspondents in both directions.
• Free/busy works between migrated and unmigrated users, where coexistence was promised.
• Files are accessible, and at least a sample of shared links have been reissued.
• Devices are enrolled and compliant.
• Email authentication records for the domain are correct in the target tenant immediately after cutover — this is a common miss and it produces delivery failures a day later. The sequence in SPF, DKIM and DMARC has to be reapplied against the new tenant.

Operational realities worth stating

The domain cutover needs a rehearsal, on a test domain, with the same people and the same runbook. It is the one step with no partial success.

Communication is a workstream, not an afterthought. Users whose email address changes need to tell their contacts. External correspondents need to know. Clients with shared links need new ones.

Keep the source tenant longer than you think. Data you failed to migrate is discovered weeks later, and a decommissioned tenant is not recoverable.

Third-party tooling is usually justified. The native tooling covers mailboxes well and other workloads less completely. For anything beyond a small organisation, evaluate a migration product against your specific workload mix rather than assuming native capability will stretch.

Rollback

There is effectively no rollback after the domain cutover. You can move a domain back, but only by repeating the removal and re-verification, with another outage — and by then users have new mail in the target tenant that the source does not have.

Rollback exists only per wave, before the cutover, and only if you kept the source mailboxes intact. That asymmetry is why the pilot wave matters and why the cutover is rehearsed.

Verification and limits

The single-tenant domain constraint, the non-transferability of licences, service principals and device registrations, and the existence of cross-tenant access and collaboration features were checked against current Microsoft documentation on 20 September 2026. The sequencing and the workload difficulty ordering reflect my own experience of migration and coexistence work.

No migration was performed for this article. Cross-tenant capability and migration tooling change: validate the current feature set, supported scenarios and licensing before committing to a design, and do not plan a domain cutover from a summary — use Microsoft’s current documentation and a rehearsal.

References

• Microsoft 365 tenant-to-tenant migrations
• Cross-tenant access settings in Microsoft Entra External ID
• Cross-tenant mailbox migration
• Add a domain to Microsoft 365