Business acquisitions, mergers, and rebrands often come with an IT project nobody budgeted for: consolidating two separate Microsoft 365 tenants into one. Unlike moving from Google Workspace, both the source and destination are already fully built-out Microsoft 365 environments - which brings its own set of risks around duplicate identities, Teams data, and SharePoint permissions. Here's how to plan it properly.
When you need a tenant-to-tenant migration
- Acquiring or merging with a business that already runs its own Microsoft 365 tenant
- A company rebrand or restructure that requires consolidating multiple tenants under one
- Divesting part of a business into a separate, independent tenant
- Moving away from a tenant previously managed by an external party you no longer work with
What makes this different from a Google Workspace migration
When moving from Google Workspace, the destination Microsoft 365 tenant is usually brand new and empty. In a tenant-to-tenant migration, the destination already has its own users, mailboxes, Teams, and SharePoint sites in active use. This adds complexity most other migrations don't have to deal with:
Duplicate or conflicting identities
If both tenants have a user with the same email address, or a shared naming convention, accounts need to be reconciled before migration - Microsoft 365 won't allow the same email address to exist as a primary address in two tenants simultaneously.
Teams and channel history
Microsoft doesn't offer a fully native way to migrate Teams chat history and channel conversations between tenants - this typically requires a third-party migration tool. Plan for what history is genuinely needed versus what can be archived and left behind.
SharePoint permissions and site structure
SharePoint sites carry complex nested permissions that don't map automatically to a new tenant. Migrating this cleanly usually means rebuilding the permission structure in the destination tenant rather than expecting a straight copy.
Licensing overlap
Users who exist in both tenants during the transition period may need temporary licences in both, which affects the project budget beyond the migration labour itself.
The tenant-to-tenant migration process
- Discovery and mapping. Document every user, mailbox, Teams site, and SharePoint library in the source tenant, and map each one to where it lands in the destination.
- Identity reconciliation. Resolve any duplicate email addresses or naming conflicts between the two tenants before migration begins.
- Domain preparation. Verify the source domain(s) in the destination tenant, ready for cutover.
- Pre-migration data copy. Mailboxes, OneDrive, and SharePoint content are copied into the destination tenant using a migration tool designed for tenant-to-tenant moves.
- Teams migration. Channels, files, and (where supported) chat history are migrated, with a clear plan for what gets left in an archived source tenant.
- Cutover. Domains are removed from the source tenant and added to the destination, redirecting mail flow and sign-in.
- Decommission. Once confirmed stable, the source tenant is retired or repurposed, and duplicate licences are removed.
Common problems to plan around
- Staff losing access to shared files mid-migration because SharePoint permissions weren't rebuilt before cutover
- Teams chat history being lost because it wasn't flagged as a requirement before the project started
- Email delivery gaps during the domain switch, particularly for businesses that can't accept any downtime
- Underestimating licensing costs during the overlap period when users exist in both tenants
Many of the underlying planning principles are the same as any other email platform move - see our general email migration guide for the audit and cutover fundamentals that still apply here.
Frequently Asked Questions
What is a Microsoft 365 tenant, in plain English?
A tenant is your business's dedicated, isolated instance of Microsoft 365 - it holds your user accounts, mailboxes, Teams, SharePoint sites, and security settings, all tied to your domain. Two businesses each have their own separate tenant by default, even if they're later acquired by the same parent company. Merging or migrating requires deliberately moving data from one tenant into another.
Why can't we just add our new domain to our existing Microsoft 365 tenant?
In some straightforward cases you can - adding a domain to an existing tenant works fine if you're simply adding a brand name or secondary domain to a business that already exists in that tenant. Tenant-to-tenant migration is different: it's needed when two businesses each already have their own separate, populated Microsoft 365 tenant (mailboxes, Teams, SharePoint data all in use) and you need to consolidate one into the other, which is a genuine data migration project rather than a settings change.
How long does a tenant-to-tenant migration take?
For a straightforward merger of two businesses with 10-30 users each, budget 3-6 weeks from planning through to full cutover, including Teams and SharePoint data. Larger environments with extensive SharePoint sites, Teams channels, and years of data take longer. It's typically a more involved project than a Google Workspace to Microsoft 365 migration, since both source and destination environments are already fully built out.
Merging two Microsoft 365 tenants?
We plan and run tenant-to-tenant migrations for Perth businesses going through a merger, acquisition, or restructure - with a clear plan for identities, Teams, and SharePoint before anything moves.
Get a Free ConsultationFor related reading, see our IT Due Diligence When Buying a Perth Business and Google Workspace to Microsoft 365 migration guide.