Tenant-to-Tenant Migration: Microsoft 365 and Workspace

The deal closed Friday. Monday morning the CEO sends an email asking when the acquired company's 280 staff will be on the parent organisation's Microsoft 365 tenant, with the parent's domain, sharing calendars across the two halves of the business. You have a real project on your hands — not a mail server move, but an identity, licensing, compliance, and coexistence project that happens to involve email. This guide is for that project.

When tenant-to-tenant migration is the right shape of project#

Tenant migrations come up in four scenarios, and the scenario shape determines almost every downstream decision.

Acquisition or merger#

You bought another company. Their users, mail, calendars, files, and Teams chats need to live in your tenant under your domains. The hard parts are domain transfer (the source domain has to leave the source tenant before yours can claim it) and identity unification (people who had two accounts now have one). The merger and acquisition email migration playbook covers the M&A-specific dynamics in more detail.

Divestiture or spin-off#

You sold a business unit. Their users, mail, and files need to leave your tenant and land in a new one — sometimes one that doesn't exist yet on day one of the transitional services agreement. The hard parts are scoping (which users, which shared mailboxes, which distribution lists belong to the spun-off entity) and the timing of access revocation. The divestiture email migration walkthrough goes into the unique constraints of these projects.

Brand split or rebrand#

The legal entity stays the same, but the company is splitting into two operating brands with separate email domains and possibly separate tenants. Often used by holding companies, professional services firms, or organisations preparing for a future sale. The hard parts are calendar coexistence and shared resource planning while the split is in motion.

Domain change without tenant change#

Less common, but worth naming: you're keeping the tenant but changing the primary domain. This is usually a domain change migration, not a tenant move, and the steps are quite different — you don't move mailboxes, you rename them. Make sure the project is genuinely a tenant migration before you scope it as one.

What's actually moving#

A tenant migration is not one workload. It's a stack of workloads that share a calendar but have different tooling, owners, and risks. For the mail-and-calendar portion specifically, the Microsoft 365 migration guide and Google Workspace migration guide cover the platform-specific mechanics.

The email and calendar workload#

Primary mailbox content (mail, folder structure, read state, flags), calendar (events, recurring meetings, free/busy lookups, room mailboxes), contacts (personal and shared), rules, signatures, out-of-office, archive mailboxes, journaled or litigation-hold mail.

This is the workload that touches users most visibly. A botched mail migration is the one users will complain about loudest, because it's the one they notice within an hour of cutover.

The identity workload#

User accounts, groups, licenses, MFA configurations, conditional access policies, app permissions. In an acquisition, you're often deciding whether to keep two separate identity providers running in parallel or merge them. Your answer shapes everything else.

The collaboration workload#

OneDrive personal storage, SharePoint sites, Teams chats and channels, Planner plans, Power Platform environments. Each has its own migration mechanism, its own throttling, and its own quirks. These rarely fit in the same cutover window as email.

The compliance workload#

Retention policies, eDiscovery holds, audit logs, DLP rules, sensitivity labels. The destination tenant may already have policies that conflict with the source tenant's; reconciling them is a project of its own. The email migration compliance guide covers this end-to-end.

Microsoft's native cross-tenant tools#

Microsoft offers conceptual support for tenant-to-tenant migration through a few mechanisms, all aimed at making the data-move portion of the project less painful. None of them eliminates the surrounding identity and licensing work.

Cross-tenant mailbox migration#

At a conceptual level, this lets the destination tenant pull mailboxes directly from the source tenant using a trust relationship and a migration endpoint, instead of going through IMAP or third-party tooling. The benefit is that primary mailbox data including metadata moves cleanly and quickly. The limitations: it focuses on mailbox content, doesn't unify identity by itself, and the configuration involves consent flows on both tenants that often take longer to set up than expected.

Use it when both tenants are M365, when you have admin cooperation on both sides, and when the scope is genuinely just mail. Don't expect it to handle rules, signatures, or the surrounding identity work.

Cross-tenant SharePoint migration#

Separate from mailbox migration, with its own enablement steps, its own throttling profile, and its own scope (sites, lists, libraries, with some metadata caveats). Plan it as a separate workstream.

Cross-tenant identity (B2B and synced identity)#

If you can't unify identity immediately, B2B lets users from the source tenant access destination tenant resources as external guests during the coexistence period. It's a stopgap, not an end state, but it buys time when the data move has to happen before identity unification.

What native tools don't do well#

• Calendar and contacts in the same pass as mail. You usually need a separate workflow.
• Rules (server-side filters). These don't transfer; rebuild them on the destination.
• Out-of-office text. Doesn't carry.
• Shared mailbox permissions. The mailbox content moves; the permissions don't.
• End-user signatures stored client-side. Out of scope for any server migration tool.

Third-party tool advantages#

The case for a third-party tool over Microsoft's native cross-tenant migration is rarely about mail content quality — Microsoft's tooling handles mail well. The case is about everything around the mail.

One pass for mail, calendar, and contacts#

A purpose-built migration tool does mailbox, calendar, contacts, and (sometimes) rules in a single coordinated job. Native tooling makes you orchestrate these separately, with different tools and timelines. For 30 users, this is a minor convenience. For 300 users with shared calendars and complex meeting series, it's the difference between a working cutover and a week of post-cutover repair.

Real-time delta sync and coexistence#

Good third-party tools support delta sync up to the cutover moment and bidirectional sync during coexistence windows. That means users on the source tenant and users on the destination tenant can still see each other's free/busy and meet without invite collisions during a multi-day or multi-week coexistence period. Native tooling has improved here, but the third-party offerings tend to be more flexible.

Throttling intelligence#

The good migration vendors have built throttling profiles for Microsoft 365 and Google Workspace over years of moving customers. They know when to back off, how aggressively to retry, and which combinations of mailbox size and folder depth cause specific failure modes. You can build this yourself; you'll spend weeks on it.

Reporting and audit trail#

A migration that needs compliance sign-off needs an audit trail. Counts of items per mailbox at source. Counts at destination. Discrepancies. Reasons (skipped because of size, skipped because of policy, etc.). Native tools produce some of this; third-party tools tend to produce more of it in formats compliance teams can actually consume.

Identity and the UPN question#

Every tenant migration runs into the same identity question: what does the user's UPN (User Principal Name) look like during and after the migration?

Option 1: cutover by domain#

The destination tenant claims the source tenant's domain. Users keep their email address. The trade-off: the source tenant has to surrender the domain first, which means every source mailbox temporarily uses an onmicrosoft.com address. There's typically a window of a few hours to a few days where the source domain is "in transit" between tenants and email to it bounces or is at risk of bouncing.

This is the cleanest outcome for users — they never see their address change — and the most operationally complex for admins. Read the section on rename-domain below.

Option 2: new UPN on destination#

Users get a new email address on a destination-owned domain. Their old address either stays valid via a forwarding mechanism on the source tenant (if the source is still running) or via a transport rule on the destination after the domain transfer (if the source is being decommissioned). The trade-off is user disruption — everyone has to update their email signature, their externally-shared contact info, and their business cards.

Use this when the business has decided to consolidate to a single brand domain anyway. Don't use it when retaining the source brand identity is a business requirement.

Option 3: dual UPN with proxy address#

Users have a primary UPN on the destination domain but receive mail at both the old and new addresses through proxy addresses. Mechanically straightforward but creates ongoing confusion about which address is "the real one". Acceptable as a transitional state, problematic as a permanent one.

The rename-domain pattern#

This is the pattern that gets every M&A acquisition's email project most of the way to a clean state. Worth its own section.

The sequence#

1. Provision destination mailboxes for every source user, initially on the destination's existing domain (acquireduser@parentcompany.com or on an onmicrosoft.com placeholder).
2. Run a full mailbox sync from source to destination. Both tenants are live; mail still flows to source addresses.
3. On the chosen cutover day, rename every source mailbox to its onmicrosoft.com address. This frees the source domain.
4. Remove the source domain from the source tenant.
5. Add the source domain to the destination tenant.
6. Update each destination mailbox to use the source domain as its primary SMTP. Users keep their original email addresses.
7. Update MX records to point to the destination tenant.
8. Run a final delta sync to catch the messages that arrived during the rename window.

What goes wrong#

The rename step (3) takes longer than you expect, especially for tenants over a few hundred mailboxes. The domain removal (4) sometimes fails because of stale references — distribution groups, shared mailboxes, room mailboxes, application mailboxes that still claim the domain. Microsoft will refuse to remove the domain until every reference is cleared.

The domain add (5) is fast once the source has released the domain. The MX update (7) is subject to DNS TTL, so the actual cutover happens over hours rather than instantly.

Plan a 24–48 hour window for the full rename-and-domain-transfer sequence, even though the "active" steps take less than an hour. The waiting and verification dominate.

Licensing implications#

Tenant migration is when licensing surprises arrive. Three patterns recur.

Double licensing during coexistence#

If users have active mailboxes on both source and destination tenants during a coexistence period, both tenants are billing for those users. For 300 users with E3 licenses, that's an extra significant monthly bill for however many months the coexistence runs. Build this into the project budget; finance should not be surprised at the first invoice.

License SKU mismatch#

The source tenant has E5 and the destination tenant has E3, or vice versa. Some features the user relied on (advanced eDiscovery, certain compliance features, Power BI Pro) may not exist on the destination after cutover. Inventory feature usage during discovery, not after users complain.

Add-on licenses don't always transfer cleanly#

Third-party add-on licenses (provisioned through M365 admin center) sometimes assume a stable tenant ID. Check each add-on vendor's tenant-migration story before assuming licenses follow users.

Coexistence windows#

For anything beyond a small project, you'll have a period where some users live on the source tenant and some on the destination. Free/busy lookups, distribution lists, and external email forwarding all need to keep working during that window.

What to configure#

A bidirectional free/busy trust between the two tenants — either via the native cross-tenant free/busy mechanism in M365 or through a migration tool's coexistence feature. Mail flow rules on both sides to route mail correctly when a user has moved but external senders still have the old address cached. Address book sync so that users on both tenants can see each other in autocomplete and find each other in their directories.

How long is too long#

The pragmatic answer: as short as the project allows. Coexistence is brittle. Free/busy can degrade. Address books drift. Distribution lists develop split memberships. The longer you run it, the more issues compound. Two weeks is comfortable. Two months is risky. Six months is asking for trouble unless the architecture genuinely supports long-term coexistence.

Google Workspace tenant-to-tenant#

Workspace tenant migrations follow the same shape as M365 but with different tooling. Google's Migrate for Workspace and Workspace Migration for Microsoft Outlook handle parts of the process. The conceptual model is similar: provision destination accounts, sync data, transfer the domain, cut over.

The Workspace-specific quirks: labels are not folders, so "folder structure" preservation means mapping labels semantically. Drive sharing permissions are scoped to the source tenant and need explicit re-permissioning. Calendar resources (rooms, equipment) are individual calendars that need to be moved like user calendars.

For the platform mechanics, the Google Workspace migration guide covers the underlying procedures.

Data residency#

Tenant migrations move data through migration infrastructure that lives somewhere. For most projects, this doesn't matter. For some, it's the central question.

If your source tenant is in the EU and your destination tenant is in the US, the migration tool's processing region matters. If the tool processes the data in a third region, you may have a transfer issue under GDPR. Get this in writing from the vendor before the bulk pass, and document the data flow in your project records.

Desktop migration tools (where the migration runs on a workstation under your control) sidestep some of this — the data never touches a third-party cloud — but only if the workstation itself is in the right region. Verify and document.

When the project is actually a renaming problem#

Sometimes "we need a tenant migration" turns out to be "we need to change the primary domain". One tenant, same users, different SMTP suffix. That's a much smaller project: rename mailboxes, update DNS, set up proxy addresses for the old domain during the transition.

Ask the question early. The right answer isn't "do the smaller project disguised as a bigger one"; it's "scope the project correctly so you don't over-engineer the solution".