Publish Date
24/09/2026
Categories
Blogs
One business shouldn’t feel like two. But after a merger, acquisition or restructuring, separate Microsoft 365 environments can leave teams dealing with different sign-ins, disconnected files, inconsistent security policies and different ways of working.
Bringing those environments together is not simply a case of transferring data from one place to another. A successful Microsoft 365 tenant-to-tenant migration starts with deciding which tenant the business will keep and what each team needs to carry on working.
Those decisions shape the migration plan long before the first mailbox moves.
What is a Microsoft 365 tenant-to-tenant migration?
A Microsoft 365 tenant-to-tenant migration involves moving agreed users, data and workloads from one Microsoft 365 tenant to another.
There are several reasons why a business might need one. An acquisition could require a newly purchased business to move into the parent company’s Microsoft 365 environment. A divestiture could involve separating users and data into a new environment. Businesses that have accumulated multiple tenants through growth may also decide to consolidate them.
It is important to distinguish migration from cross-tenant collaboration.
Organisations can enable people in separate tenants to collaborate without permanently moving them into the same environment. A tenant migration goes further by changing where selected users, workloads and data are ultimately managed.
This is also why a Microsoft tenant-to-tenant migration should not be viewed purely as an email project. Exchange mailboxes might be a significant part of the move, but organisations may also need to consider OneDrive, SharePoint, Teams, applications, identities, devices and security settings.
Which Microsoft 365 tenant should the business keep?
One of the first decisions is where everything is going.
Sometimes there is an obvious destination tenant. In other cases, particularly following a merger or acquisition, both environments may contain important services and applications.
Rather than assuming that the larger organisation’s tenant should automatically become the destination, discovery should assess factors including:
- Tenant ownership and administration
- Existing user and identity configuration
- Security and compliance controls
- Microsoft 365 licensing
- Applications connected to each tenant
- Power Platform and Power BI dependencies
- Existing SharePoint and Teams environments
- Device management and endpoint configuration
This assessment can expose dependencies that would otherwise only become apparent once migration work was underway.
For example, during Cobweb’s discovery work for Project Better Energy (see the case study here), the Project Solar UK tenant was selected as the destination environment. Existing Power BI and Power Platform dependencies contributed to that decision, helping to avoid unnecessary additional work and cost.
The important principle is that the destination should be selected based on business and technical requirements, rather than organisational assumptions.
What needs to move, stay or be rebuilt?
Once the destination has been agreed, the next step is understanding what actually exists.
A useful Microsoft 365 tenant migration checklist starts with an inventory covering workloads such as:
- User and shared mailboxes
- OneDrive accounts
- SharePoint sites
- Microsoft Teams
- Groups and shared resources
For each area, record its owner, approximate data volume, business importance and any dependencies.
The next layer is configuration. Permissions, external guest access, security policies, device management and connected applications all need consideration alongside the data itself.
This distinction matters because migrating content does not necessarily reproduce the way the source environment works.
For example, moving files into SharePoint is different from ensuring the correct people can access those files afterwards (see here for our SharePoint Migration Planning Guide). Similarly, transferring mailbox data does not automatically resolve identities, applications or every user experience associated with the old environment.
Each workload should therefore have a defined scope covering:
- What should migrate?
- What should remain or be archived?
- Where should it go?
- How will it be migrated?
- How will the result be checked?
The answers may differ considerably between workloads. Migration tooling also varies in what it supports, so object types, limitations and prerequisites should be understood before the project plan is finalised.
How will identities, domains and access change?
For end users, identity and access can be one of the most noticeable parts of a tenant migration.
The project needs to map users in the source environment to their identities in the destination. Duplicate or conflicting accounts should be identified and resolved, while any changes to usernames, sign-in processes and email addresses need to be agreed.
Domains require particular attention.
If users are expected to retain an existing email domain, the migration plan needs to establish how and when that domain will transition between tenants. DNS changes, mail routing and the coexistence period all have to fit into the wider cutover sequence.
The target environment must also be ready for its new users. That can include appropriate Microsoft licensing, security configuration, authentication requirements and access to the services employees need to do their jobs.
Crucially, the technical plan and communication plan need to align.
Someone should own DNS changes, somebody should be responsible for user communications, and the support team should know exactly what changes employees are going to experience. These responsibilities should be documented in the cutover plan rather than decided on migration day.
How should a cross-tenant migration be phased and tested?
For most organisations, moving everyone at once introduces unnecessary risk.
A representative pilot provides an opportunity to test the migration process and user experience before committing the wider business.
The pilot group should reflect the organisation rather than simply containing the easiest accounts to migrate. Ideally, it will include users with a range of workloads, permissions and business applications.
Testing might cover:
- Sending and receiving email
- Calendar access
- Shared and delegated mailboxes
- OneDrive and SharePoint files
- Teams access and collaboration
- Permissions
- Business-critical applications
- Sign-in and authentication
Once the pilot has been validated, the remaining migration can be broken into logical batches.
Those batches should take account of how people work together. Moving individuals without considering shared resources and team dependencies can leave technically migrated users unable to follow their normal business processes.
Before each cutover, there should also be clear go/no-go criteria, a recovery approach if something does not behave as expected, and named escalation contacts.
Microsoft native migration capabilities and specialist migration tools can support different scenarios. The correct migration approach depends on the workloads being moved, the source and destination environments and the level of coexistence required.
How long does a tenant-to-tenant migration take?
There is no reliable fixed number of days per user.
A realistic schedule depends on several factors, including:
- Number of users
- Data volumes
- Workload complexity
- Application dependencies
- Identity and domain requirements
- Required coexistence
- Migration tooling and licensing
- Testing requirements
- Support arrangements
Discovery and a representative pilot provide much better information for planning than a generic per-user estimate.
What happens after cutover?
Migration day is not the end of a Microsoft 365 tenant-to-tenant migration.
After each batch moves, validate both user access and business workflows. Can employees sign in? Can they access the files, mailboxes and Teams environments they require? Are business-critical applications still functioning?
Permissions also deserve specific attention because successful data transfer does not necessarily mean access has been reproduced as intended.
Any migration exceptions should be recorded and assigned for resolution, while employees need a clear support route if they experience problems.
There is then the question of what happens to the source tenant.
It should not simply be switched off as soon as the final users have moved. The business first needs to confirm that required information has been migrated or appropriately retained, outstanding dependencies have been resolved, and relevant retention requirements have been met.
Finally, ownership needs to move from the migration project to business-as-usual operations, with clear responsibility for security, Microsoft 365 licensing, administration and user support within the consolidated environment.
Microsoft 365 tenant migration planning checklist
Before moving users and workloads, aim to have a clear planning output for each of these areas:
| Decision | Useful planning output |
|---|---|
| Destination | Selected tenant and documented reasons for choosing it |
| Scope | Workload inventory with owners, dependencies and exclusions |
| Identity and access | User mapping, domain plan and agreed access changes |
| Pilot and cutover | Test results, migration batches and go/no-go criteria |
| Completion | Acceptance checks, support handover and source-tenant retirement plan |
The value of this checklist is not simply having another project document. It creates an agreed definition of what a successful migration actually looks like before changes begin.
Microsoft 365 Tenant-to-tenant FAQs
Not through a single “merge” switch. Tenant consolidation typically involves migrating agreed workloads into a destination tenant and resolving differences in identities, configuration, security and applications.
Often they can, but it needs to be planned. Domain ownership, the sequence of the domain transition, mail routing and the chosen migration approach will determine what users experience during the change.
Not always. Some providers bundle licensing with their service, while others provide management services separately.
The timeline depends on the number of users, workloads, data volumes, dependencies and complexity of the environments. Discovery and pilot migrations provide the information required to build a more realistic project schedule.
No. Migration coverage differs between Microsoft 365 workloads and tooling. Security policies, devices, permissions and connected applications may require separate migration or reconfiguration work and should be assessed during discovery.
The technical transfer is only one part of a successful tenant migration. Decisions about the destination environment, workload scope, identities, domains, testing and cutover can have just as much impact on the outcome.
Completing that discovery work early gives the project a defined destination, a measurable scope and a clearer view of the risks and dependencies involved.
Ready to plan your Microsoft 365 migration?
Talk to Cobweb’s Microsoft 365 migration team about your source tenants, destination options and workload requirements by filling out this form. We can help you assess the existing environments, define the migration scope and build a practical route to consolidation.