Tenant to Tenant Migration: What Actually Moves and What Does Not

A tenant to tenant migration consolidates two Microsoft 365 environments into one, or splits one into two. In a merger or acquisition it usually means moving the acquired organisation’s users into the parent tenant. In a divestment it means the opposite, carving a business unit out into a tenant of its own.

Either way, the work divides into three parts that are worth separating in your own head from the outset. There is identity, meaning users, groups and licences. There is data, meaning mail, files and sites. And there is configuration, meaning everything that makes the environment behave the way people expect: policies, security settings, voice routing, integrations and automation.

Most planning attention goes to the middle one. Data volume is easy to measure, so it is what gets estimated, quoted and tracked. Identity and configuration are harder to size and are where the surprises live.

Microsoft provides cross-tenant capability for the core workloads, and it has improved considerably.

Exchange mailboxes move cross-tenant, carrying folder structure, calendar and contacts. OneDrive content moves with version history preserved, and file sharing permissions are retained by mapping users and groups to their equivalents in the target tenant. SharePoint site collections can move, including document libraries, lists, pages and site metadata.

Microsoft has also introduced an orchestrated cross-tenant user data migration capability that bundles mailbox, OneDrive and Teams migration into a single workflow, with support for large batches. It requires appropriate licensing on both the source and target tenants plus a per-user add-on, and organisations should confirm its current availability and pricing directly, as both have changed recently.

For the data most organisations think of first, then, the native path is real and workable.

The exclusions are where tenant migrations go wrong, because they are rarely discovered at planning stage.

Teams chat history. Microsoft’s documentation states plainly that Teams chat folder content does not migrate cross-tenant. After a mailbox moves, that content remains available to the source tenant administrator through content search and export, but it does not arrive in the target. Private and group chats often hold years of decisions, approvals and context, and users notice their absence immediately. Third-party tooling exists for this and some vendors have withdrawn from it because the workload is technically difficult, so the market is worth checking rather than assuming.

External sharing and guest access. Internal permissions map across. External sharing links and guest accounts do not. Every guest has to be re-invited in the target tenant and every externally shared link re-established, which for organisations that collaborate heavily outside their walls is a substantial piece of work in its own right.

Teams voice configuration. Phone System routing, auto-attendants and call queues do not carry over. They require their own cutover design, and because telephony failure is highly visible, this deserves attention disproportionate to the effort of rebuilding it.

Power Platform. Apps, flows and Dataverse solutions move through manual export and import using standard application lifecycle management, not through any migration tool. Hardcoded environment references and connections have to be reworked. Anything undocumented is likely to be missed, which is one practical reason a maintained inventory of what has been built matters, as covered in our post on the Power Platform CoE Starter Kit.

Various smaller items that add up. Mailbox signatures need recreating. Archived Teams must be unarchived before they can be migrated. Mailboxes under legal hold are blocked from the native process. Customised tabs, third-party app integrations and pinned configurations do not survive.

Between the decision and the cutover there is usually a period where both tenants have to work, and people have to work across them.

This matters because tenant migrations follow commercial events, and commercial events do not pause for IT. Two organisations that have just merged need to book meetings with each other, share documents and reach each other in Teams, often for months, while the migration is planned and executed.

There is a further wrinkle worth knowing. Once a user’s mailbox has moved to the target tenant, Teams in the source tenant loses access to it, so signing in with the old credentials produces a degraded experience with no calendar and limited functionality. Users caught between the two states get confused quickly, which makes sequencing and communication more important than they sound.

Coexistence is a design decision in its own right, and treating it as a gap to be endured rather than a phase to be planned is a reliable way to lose goodwill early.

The sequence that tends to work runs roughly as follows.

Start with a full inventory of both tenants, covering not just data volume but licences, policies, integrations, automation and voice configuration. Establish what has to be migrated, what can be archived and left behind, and what needs rebuilding. Map that against the commercial deadline honestly, because the date is usually fixed and the scope is the only variable available.

Decide the domain strategy early, since a custom domain cannot exist in two tenants at once and removing it from the source is a hard dependency with its own lead time.

Then plan the cutover around people rather than data. Which groups move together, what they lose temporarily, and what they are told in advance.

The discipline here is the same one that determines whether any migration succeeds, which is assessment before movement rather than after it. Our post on why SharePoint migrations fail covers that principle in more detail, and it applies with more force here because the deadline is externally imposed.

Being straight about this matters, because tenant migrations are not all the same size of problem.

A small organisation moving a modest number of users, with tidy data, no complex voice setup, minimal external collaboration and nothing built on the Power Platform, can reasonably run a native cross-tenant migration with internal capability. That situation genuinely exists and does not need outside help.

The picture changes when several of the exclusions above apply at once. Teams chat history that matters, extensive guest collaboration, an established voice deployment, custom automation, legal holds, or a deadline set by a completion date rather than by readiness. Each of those adds a workstream that is separate from the data transfer, and the combination is what turns a migration into a programme.

The honest test is not the number of users. It is how many of the things that do not move natively actually matter to you.