Tenant-to-Tenant Microsoft 365 Migration After a Merger

Two companies, two Microsoft 365 tenants, one new org chart. Somebody has to combine them. There is no button for this. Microsoft provides native cross-tenant moves for mailboxes and OneDrive, but the domain can only live in one tenant at a time, Teams has no native migration, and every user's identity has to be recreated on the target side.

This post lays out what can be moved natively, what needs a third-party tool, and the sequence that avoids a weekend where nobody in the acquired company can get email.

Decide the end state first

Not every acquisition needs a merged tenant. If the acquired company keeps its brand, its domain and its IT team, cross-tenant collaboration through Entra B2B, cross-tenant access settings and shared channels may be enough for a year or more. Consolidation is the right call when the companies will share a domain, a security baseline and an IT team, and it costs weeks of work per hundred users.

If you consolidate, pick the surviving tenant. It is normally the larger one, but the tenant with the cleaner identity setup, current licensing and existing compliance configuration is the better home even if it is smaller.

Identity: users have to exist on the target side

Every migrated user needs an account in the target tenant with a license, a UPN, and for mailbox moves a mail user object stamped with the source mailbox's Exchange GUID and legacy DN. If the acquired company runs Active Directory, the cleanest path is to join those users to the surviving directory, or at least sync them into the target tenant with Entra Connect from a second forest, so the accounts are created and matched by sync rather than by hand.

Microsoft's cross-tenant identity mapping and cross-tenant synchronization can create the target users for you, but the Exchange attributes still have to be right before a mailbox move will start. Prepare the target objects with the mail user attributes and confirm them before you create a batch.

# In the SOURCE tenant, collect what the target needs
Connect-ExchangeOnline
Get-Mailbox user@source.com | Format-List ExchangeGuid, ArchiveGuid, LegacyExchangeDN, EmailAddresses

# In the TARGET tenant, stamp the mail user
Set-MailUser user@target.onmicrosoft.com -ExchangeGuid <guid> -ArchiveGuid <guid> -EmailAddresses @{add="x500:<LegacyExchangeDN>"}

Native cross-tenant mailbox and OneDrive moves

Exchange Online supports cross-tenant mailbox migration natively. The target tenant sets up a migration application registered in Entra ID, the source tenant consents to it and creates an organization relationship that scopes which mailboxes can be pulled, and the target runs a migration batch of type cross-tenant. Mailboxes move with their archive, and the source mailbox is converted to a mail user after completion. It needs the identity preparation above and a mail-enabled security group in the source tenant listing the mailboxes in scope.

OneDrive and SharePoint sites have their own native cross-tenant moves, driven by PowerShell from the target tenant with a trust set up on both sides. Each user's OneDrive moves as a unit, and links pointing at the old tenant are redirected. Both change from time to time, so read the current Microsoft docs before you begin.

# Target tenant, after the app and org relationship exist
New-MigrationBatch -Name AcquiredCoBatch1 -SourceEndpoint AcquiredCoEndpoint -CSVData ([System.IO.File]::ReadAllBytes("C:\t2t\batch1.csv")) -TargetDeliveryDomain target.onmicrosoft.com -AutoStart
Get-MigrationBatch AcquiredCoBatch1 | Format-List Status, TotalCount, SyncedCount, FailedCount

# OneDrive cross-tenant move
Connect-SPOService -Url https://target-admin.sharepoint.com
Start-SPOCrossTenantUserContentMove -UserPrincipalName user@source.com -DestinationUserPrincipalName user@target.com -DestinationUrl https://target-my.sharepoint.com
Get-SPOCrossTenantUserContentMoveState -PartnerCrossTenantHostUrl https://source.sharepoint.com

The domain problem and what has no native path

A domain can be verified in only one tenant. To move acquired.com to the surviving tenant, every object in the source tenant that uses it must be renamed to onmicrosoft.com addresses, the domain removed from the source, then added and verified in the target, then every migrated user given back their address. That means a window, usually a weekend, where mail for that domain is not deliverable unless you have set MX to a holding service or accepted a short outage. Plan it, communicate it, and script the address changes on both sides.

Teams chat history, channel messages, Planner, Forms, Power Automate flows and Power BI workspaces have no native migration. Third-party tools cover Teams messages and files with varying fidelity. Most organizations move Teams files through SharePoint site migration, recreate teams with the same owners, and accept that chat history stays in the old tenant for a read-only period. Tell users this early.

• Native: mailboxes with archives, OneDrive, SharePoint sites, identity via cross-tenant sync.
• Third-party or manual: Teams chat and channel posts, Planner, Forms, Power Platform, Intune device enrollment.
• Rebuild: conditional access, DLP, retention, transport rules, distribution groups, shared mailbox permissions.

A sequence that works

Move the data before the domain, and the domain before the devices.

1. Inventory both tenants: users, licenses, domains, shared mailboxes, groups, sites, teams, policies.
2. Create target accounts and licenses, matched to source by a mapping table. Prepare mail users with Exchange GUIDs.
3. Set up cross-tenant mailbox migration and OneDrive trust. Move a pilot of five users end to end.
4. Run mailbox and OneDrive batches over weeks while users work in the source tenant.
5. Domain weekend: complete final batches, strip the domain from source, add to target, restore addresses, switch MX.
6. Following week: re-enroll devices in Intune, re-add accounts on phones, recreate teams, retire the source tenant after a read-only period.

Frequently asked questions

Takeaway

A tenant merge is three projects: identity, data and the domain weekend. The native cross-tenant tools handle mailboxes and OneDrive well once the target objects are prepared, and everything else is rebuild or third-party. Map it, pilot it, and put the domain move on a calendar with the people who will be affected.