Merging Microsoft 365 Tenants: What Happens on Cutover Weekend

A tenant-to-tenant migration succeeds or fails on what happens to mail flow and sign-in between the moment you start and the moment everyone is on the new tenant. Get coexistence right and most staff will not notice the weekend it happened.

Mergers, acquisitions, demergers and years of separate tenants all lead to the same request: put these people, mailboxes and files into one Microsoft 365 environment. The technical steps are well understood. The difficulty is doing them while two organisations keep working.

The short answer

Plan a tenant migration as a sequence, not an event. Prepare the target tenant, licence the users, migrate content in waves while both tenants stay live, keep mail flowing between them during the transition, and only then move the domain and switch users over. The cutover itself should be the shortest and least interesting part of the project.

Why two tenants are harder than they look

A tenant is more than a list of mailboxes. It holds identities, licences, groups, policies, sharing settings, applications and years of accumulated configuration. Two organisations arrive with different naming conventions, different security policies and different answers to who owns what.

Merging them means deciding, item by item, which settings win. That decision work is usually the slowest part of the project, and it is best done before any data moves.

What can move, and what needs care

• Mailboxes move well, including mail, calendar and contacts, and are usually the first workload migrated.
• OneDrive and SharePoint content can be migrated, but sharing links, permissions and site structure need to be planned rather than copied blindly.
• Teams needs the most expectation setting. Team structure and channel content can be moved with the right tooling, but private chat history and some settings have limits, so agree in advance what staff will and will not see afterwards.
• Groups, distribution lists and shared mailboxes must be recreated and mapped, and are often forgotten until someone cannot email their department.
• Applications and integrations that sign in through the old tenant need to be repointed, and each one is a small project of its own.

The domain can only live in one place

A custom domain can belong to only one Microsoft 365 tenant at a time. That single fact shapes the whole plan, because it determines when addresses switch over and how mail behaves in between.

Until the domain moves, users in the new tenant work under a temporary address, and mail sent to the old address must still reach them. That is what coexistence is for.

Coexistence: how both sides keep working

Coexistence means that during the transition, people in both tenants can still find each other, see availability and exchange mail as if nothing had changed. Done well, it lets you migrate in waves, a department at a time, instead of moving everyone in one risky weekend.

It also gives you somewhere to stop. If a wave surfaces a problem, the remaining users are still working normally on the old tenant while you fix it.

A sensible order of work

1. Discovery. Inventory users, mailboxes, shared resources, groups, applications and third-party services tied to the old tenant.
2. Target tenant preparation. Security policies, conditional access, licensing and naming conventions in place before the first user arrives.
3. Identity mapping. Decide how each user in the source corresponds to a user in the target.
4. Pilot wave. Move a small group, including someone from finance and someone who travels, and learn from it.
5. Content waves. Migrate mail, files and Teams content department by department, with coexistence keeping everyone reachable.
6. Cutover. Move the domain, update mail routing, switch sign-in and reconfigure devices and Outlook profiles.
7. Hypercare. A short period of close support for the problems that only appear when real people use the new environment.
8. Clean-up. Decommission the source tenant on a schedule, once retention and audit needs are met.

What staff notice, and how to reduce it

The visible disruption is rarely the data. It is the sign-in prompt that appears on Monday morning, the Outlook profile that has to be rebuilt, the phone that needs its mail account re-added, and the shared calendar that has gone missing.

Clear, short instructions sent before the cutover, and support available on the day, remove most of the friction. A one-page guide and a named person to call do more for a smooth weekend than any amount of technical preparation.

Security during the transition

A migration temporarily creates accounts, permissions and connections that would not normally exist. Treat them as time-limited. Use accounts created for the migration only for that purpose, remove them when the project ends, and confirm at the end that the new tenant enforces multifactor authentication and blocks legacy sign-in, rather than inheriting whatever the old one allowed.

Frequently asked questions

How long does a tenant-to-tenant migration take?

It depends on the number of users, the volume of mail and files, and how many applications are tied to the old tenant. Discovery and preparation usually take longer than the data transfer itself, so give them proper time in the plan.

Will staff lose their email?

Not if the migration is planned properly. Mailbox content is migrated in advance and coexistence keeps mail flowing between the two tenants while the transition is under way.

Can we keep our email addresses?

Yes, but the domain has to be moved from one tenant to the other, and that step has to be sequenced carefully so mail is never left without a home.

What happens to Teams chats and channels?

Teams and channel content can be migrated with suitable tooling, but some elements, including private chat history, have limits. Agree in advance what will move so nobody is surprised afterwards.

Do we need to migrate everything?

Not necessarily. A migration is a good moment to archive what is no longer needed and retire what nobody uses. Moving less is faster, cheaper and leaves a cleaner tenant.

Where to start

Begin with an inventory of what the source tenant holds and which decisions the merger forces, before anyone talks about dates. Onprem2Cloud IT Solutions Co. is a Microsoft CSP partner based in Muntinlupa City, Metro Manila, working with businesses, local government units and national agencies. See our Microsoft 365 tenant migration service, or contact us to plan yours.

If the move is part of a wider shift to the cloud, our Azure migration checklist covers the workloads around it.