How to Consolidate Two Microsoft 365 Tenants After a Merger or Acquisition

Decide the Direction Before Touching Any Data

Microsoft doesn’t offer a single switch to merge Microsoft 365 tenants. What happens in practice is that data and identities move from a source tenant into a target tenant, workload by workload. So the first call is which tenant survives.

Most teams pick the acquirer’s tenant, or whichever one has stronger compliance settings and licensing. Check three things before you commit: license coverage for incoming users, Conditional Access and retention policies in the target, and which custom domains will change hands. A custom domain can be verified in only one tenant at a time, so the domain move must be sequenced with mail flow changes.

A Microsoft 365 merger and acquisition migration also runs on the deal’s calendar, not yours. Legal Day One dates and transition agreements often set the deadline. For wider planning context, this guide on handling a Microsoft 365 tenant merger during an acquisition covers the common constraints in more detail.

The Native Route: Cross-Tenant Mailbox Migration

For Exchange Online data, Microsoft provides cross-tenant mailbox migration. It fits best when the scope is small, limited to mailboxes, and handled by someone comfortable with PowerShell. The outline looks like this:

1. In the target tenant, register an application in Microsoft Entra ID, grant it the mailbox migration permission, and create a migration endpoint.
2. In the source tenant, consent to that application, set up an organization relationship, and create a mail-enabled security group that defines which mailboxes may move.
3. Back in the target, create a mail user for each person, with attributes such as the ExchangeGUID and the legacy DN (added as an x500 address) matching the source mailbox.
4. Start a migration batch from the Exchange admin center or Exchange Online PowerShell.
5. Once the batch finishes, update mail routing and confirm the results with each user.

Microsoft’s documentation lists the exact attributes and permissions, and requirements do change, so check the current version before you start.

The catch is scope. This process moves mailboxes. Teams, SharePoint sites, and shared files sit outside it, and Microsoft handles some of them in OneDrive.

Steps to Perform Native Cross-Tenant Migration

Register the migration app in the target tenant.

1. Grant the required permissions in the source tenant.
2. Create MailUser objects in the target tenant.
3. Add the matching ExchangeGUID and X.500 address.
4. Create the migration endpoint and batch using PowerShell.
5. Run New-MigrationBatch and monitor the migration.

Where Manual Effort Adds Up

Anyone who has tried to consolidate two Microsoft 365 tenants with scripts alone knows the pattern. Nothing is impossible, but the small tasks multiply.

• Attribute preparation repeats for every target mail user.
• Each workload carries its own process and prerequisites.
• Progress is tracked mainly through PowerShell output, so consolidated reporting takes extra work.
• Duplicate data may also be migrated. Two companies often hold the same templates, contracts, and vendor files, and a straight copy moves both versions.

None of this blocks a 30-user project. At several hundred users, it turns into weeks of coordination.

Using Dedicated Tool

Purpose-built software reduces much of the scripted preparation with a console. The DRS Softech Tenant to Tenant Migration Tool is built for this scenario, and it covers four workloads from one place: Exchange Online mailboxes, SharePoint Online sites, OneDrive for Business accounts, and Microsoft Teams.
Here is what matters for a consolidation project:

• Authentication: Modern Authentication and Azure App Registration, with MFA support.
• Mapping: Supports one-to-one, one-to-many, many-to-one, and many-to-many mappings for mailboxes, sites, and OneDrive accounts.
• Incremental passes: The Skip Previously Migrated option only transfers new or modified items. If 60 of a 100 GB mailbox has already been transferred, the next run can focus on the remaining data.
• Filters: date range, file size, file extension, and content type, so you can leave old data behind.
• Teams: public and private channels, messages, files, apps, and tabs move through the Microsoft Graph Migration API with one-to-one user mapping.
• Deduplication: built-in scanning for emails, SharePoint files, and OneDrive data, using hash-based comparison of file content.
• Reporting: an Active Tasks view for live progress, plus reports listing transferred, skipped, and failed items.

When reading the table below, remember that a Microsoft 365 tenant-to-tenant migration of this scope typically consists of multiple workloads, which is why the proper approach depends on which workloads you need to migrate.

Steps to Perform Tenant Migration with DRS Softech

• Install and run the DRS Softech Tenant-to-Tenant Migration Tool.
• Choose the workload: mailboxes, SharePoint, OneDrive, or Teams.
• Connect the source tenant using Modern Auth or individual user credentials.
• Log in to the destination tenant via Modern Auth or Impersonation.
• Map source-to-destination user accounts and apply date or folder filters.
• Click Start Migration to begin the cross-tenant transfer.
• After migration, monitor the migration process via the progress bar.

Microsoft 365 tenant migration: Native vs. Dedicated Tool

Factor	Native cross-tenant mailbox migration	Dedicated migration tool
Interface	Exchange admin center and PowerShell	Single desktop console
Workloads covered	Exchange Online mailboxes	Mailboxes, SharePoint, OneDrive, Teams
Mapping options	Per-user preparation	One-to-one through many-to-many
Duplicate handling	Not part of the migration	Built-in deduplication
Reporting	Batch status and PowerShell output	Active Tasks view and detailed reports

Conclusion

To consolidate two Microsoft 365 tenants, careful planning is required, especially when mailboxes, SharePoint, OneDrive, and Teams are involved. Microsoft’s native cross-tenant migration can handle Exchange Online mailboxes, but other workloads require separate migration processes. A dedicated migration tool can simplify multi-workload migration with user mapping, filters, incremental passes, deduplication, and reporting. Try the trial version to migrate and validate data, and then move the remaining users in planned phases.

Frequently Asked Questions