October 6, 2026
A practical guide to planning a Microsoft 365 tenant-to-tenant migration when multiple companies are coming together.
When two or more companies come together, IT gets a deadline long before it gets a plan.
Leadership may want one company, one email domain, and one Microsoft 365 environment shortly after the deal closes. Users need access to email, files, Teams, and other applications, while IT teams must coordinate multiple tenants, identities, domains, security policies, and migration waves.
The migration itself is only one part of the project. The decisions made before the first data moves often determine whether Day 1 is smooth or filled with support tickets.
For MSPs and IT teams, the key is to establish the scope, dependencies, migration sequence, and destination environment before migration begins.
Why M&A Migrations Are Different
A typical tenant-to-tenant migration has one source and one destination.
An M&A migration may involve several source tenants, each with different domains, naming conventions, identity configurations, security policies, and data volumes. The project also has fixed business deadlines, including Legal Day 1, TSA expiration dates, and planned tenant shutdowns.
At the same time, employees are experiencing significant organizational change.
That makes preparation especially important. A successful M&A migration isn’t simply about moving data. It’s about creating a clear path from multiple existing environments to a new destination—and making sure the business can operate throughout the transition.
Phase 1: Establish the Project
Start by establishing the project framework before getting into migration details.
Document the companies and tenants involved, key dates, stakeholders, destination tenant, and major business requirements. Bring together the people responsible for Microsoft 365 administration, security, DNS, compliance, communications, and user support.
Most importantly, make the major design decisions early.
Determine the destination email and UPN format, how domains will be handled, whether coexistence is required, and what needs to be available on Day 1.
These decisions become the foundation for everything that follows.
Phase 2: Discover and Scope
You can’t build a reliable migration plan without understanding what’s in each environment.
For every source company, identify the users and workloads that need to move. Look at mailbox and OneDrive data volumes, shared mailboxes, groups, SharePoint sites, Teams, and other collaboration data.
Also identify dependencies outside the core migration, including identity configuration, security policies, applications, Power Platform workloads, Intune, and single sign-on.
This is also the time to clean up. Remove or exclude departed users, duplicate accounts, obsolete data, and anything else that doesn’t need to move.
The goal isn’t simply to create an inventory. It’s to understand what needs to move, what depends on something else, and what could create a problem later.
Phase 3: Design the Migration
With the environment scoped, design the path to the destination.
Start with identity. Map source users to their destination accounts and resolve naming conflicts before migration.
Then plan the domain transition. Determine who controls DNS, when domains need to move, and how the cutover will affect mail flow.
Next, build migration waves. Rather than moving everyone at once, group users into manageable waves based on company, department, location, data volume, or other business requirements.
Start with a pilot. A small pilot allows the team to validate the process, identify unexpected dependencies, measure performance, and refine the migration plan before scaling.
Finally, determine the MigrationWiz licensing required for the workloads and users in scope.
Phase 4: Prepare the Tenants
The destination environment should be ready before users begin moving.
Provision destination accounts and licenses, prepare OneDrive and other required services, and establish the destination objects and configurations needed for the migration.
At the same time, prepare the source and destination tenants for MigrationWiz. Complete the required application registration, permissions, authentication, and security configuration, and make sure Conditional Access policies won’t interfere with the migration.
Phase 5: Build and Test the MigrationWiz Projects
Once the environments are ready, create and organize your MigrationWiz projects.
For larger M&A engagements, use a consistent naming convention for companies, workloads, and migration waves. Maintain a master user mapping that connects source users to destination users and tracks their migration status.
Before scaling, validate the project configuration and run a pilot migration.
The goal is to prove the process before putting dozens or hundreds of users through it.
Phase 6: Pre-Stage and Cut Over
Where the migration scenario supports it, pre-stage data before the final cutover. Moving data ahead of time reduces the amount that needs to be processed during the final migration window.
The cutover itself should be treated as a coordinated business event—not simply a technical task.
Plan the required domain and DNS changes, final migration passes, user configuration, permissions, communications, and support coverage.
Maintain a detailed runbook with owners and timing for each step.
Phase 7: Validate and Support
The project doesn’t end when the final migration pass completes.
Validate the migrated data, confirm user access, monitor support requests, and obtain business sign-off for each migration wave.
Keep migration statistics and project records for future reference.
Only retire source tenants after the business has confirmed that the required data, applications, identity, compliance, and retention requirements have been addressed.
The Spreadsheets That Keep the Project Organized
A few core planning documents can make a complex M&A migration much easier to manage:
- Project Charter: Scope, stakeholders, timeline, and key decisions.
- Environment Inventory: Tenants, users, domains, mailboxes, SharePoint, Teams, and other workloads.
- User Mapping: Source identity, destination identity, migration wave, and status.
- Wave Plan: Users, data volumes, dates, dependencies, and owners.
- MigrationWiz Project and License Register: Projects, workloads, licensing, and status.
- Cutover Runbook: Tasks, owners, timing, and validation.
- Communications Plan: User communications and support information.
- RAID Log: Risks, assumptions, issues, and dependencies.
These documents create a single source of truth for everyone involved in the migration.
The Bottom Line
An M&A migration doesn’t start when you click Start Migration. It starts with discovery and planning.
Understand the environments. Map the users. Resolve identity and domain issues. Build manageable migration waves. Prepare the destination. Test the process before scaling.
MigrationWiz can handle the heavy lifting of moving supported Microsoft 365 workloads, but the quality of the migration depends heavily on what happens before the first data moves.
Plan the environment. Map the users. Build the waves. Test the process. Then migrate.
That preparation is what helps turn a high-pressure M&A migration into a controlled transition — and gives users a better Day 1 experience.
For more details, check out our recent live demo on-demand.