Consolidation
Tenant consolidation
Two or more Microsoft 365 tenants becoming one. Tenant-to-tenant migration is the same work under the other name buyers use for it. Identity, mailboxes, SharePoint, OneDrive and Teams move into a single environment, in an order that has to be decided before anything moves.
Most of what makes this different from a single migration is that the target already has people in it. A move into an empty tenant is a transfer. A move into an occupied one is a merge, and a merge needs a decision about every account that exists on both sides.
What a second tenant changes
Three things exist in a consolidation that do not exist in a single-tenant move of the same size.
- A mapping decision for every account
- In a single migration an account moves. Here it has to be matched to a person who may already exist on the other side, and the answer differs per account.
- A period where both tenants are live
- People on either side still have to work, and to book each other, while some have moved and some have not.
- A domain that can only be in one place
- Microsoft allows a verified domain in exactly one tenant, which makes the domain move a cutover rather than a copy.
Consolidations arrive from two directions: a transaction that created the second tenant — M&A technology integration — or tenants that accumulated without one — disconnected Microsoft 365 environments.
Identity is the dominant driver
Everything else is sequenced behind this. Mailboxes, files and devices all resolve to accounts, so the account model has to be settled before any of them move.
What has to be decided, per account: whether the person exists on both sides, which identity survives, what happens to the address that does not, and whether the account should exist in the target at all. Service accounts and shared mailboxes each need their own answer, and neither has a person to ask.
Groups and permissions do not survive as names. A group is a set of members that resolve to accounts — when the accounts are remapped, the membership has to be rebuilt against the new identities rather than copied.
Where either side runs on-premises Active Directory, the directory and the tenant are one identity system. Which side is authoritative after the merge, and what happens to the on-premises directory afterwards, are decisions rather than defaults.
Both tenants are live at once
The middle state is the one most plans leave out, and it is where most of the elapsed time goes.
BeforeTwo estates, no shared anything
Tenant A
- Its own users and groups
- Its own domains
- SharePoint, OneDrive, Teams
Tenant B
- Its own users and groups
- Its own domains
- SharePoint, OneDrive, Teams
Nothing in either directory says which account is which person on the other side.
DuringBoth tenants live at the same time
Coexistence
- Mail routes between the two
- Free/busy and directory sync so people can still book each other
- Some users moved, some not
Waves
- A pilot group first
- Then groups in a planned sequence
- A rollback position at each stage
This is the state that takes the time, and the one most plans leave out.
AfterOne tenant, and a decision about the old one
Target tenant
- One identity model
- Domains moved and mail flowing
- SharePoint, OneDrive and Teams in one place
- Devices enrolled against one tenant
Source tenant
- Decommissioned on a decision, with a date
- Never assumed to be finished
What happens to the old tenant is planned work, not a side effect of the last wave.
Mail routes between the two tenants. Free/busy is shared so people can still book each other. The directory is synchronized enough that the two halves can find each other at all.
Users move in waves, not all at once. A pilot group first, then groups sequenced by dependency. The people who work together move together, because splitting a working group across two tenants is what generates the complaints.
Every wave has a rollback position, defined before the wave runs. It states how far the wave can be taken back, and what has to be true before the next group starts. Where the source survives the move it is part of that position. With Microsoft's own cross-tenant move it is not, because the source mailbox is removed once the move completes.
How waves are sequenced
A wave is not just a convenient group of people. Microsoft's own migration has a scoping object with rules attached, and those rules decide where the boundaries can fall.
A scope is a security group, and nobody can be in two of them. The objects to be moved are named through mail-enabled security groups, and Microsoft is explicit that an object belonging to more than one scope risks its mapping being overwritten. That single rule does more to shape a wave plan than any preference about which department goes first.
Every object in a wave has to reach a completed state before any mailbox in it moves. Identity mapping writes the attributes that make the move possible: the mailbox and archive identifiers, and the X.500 addresses that keep old mail replyable. The move does not proceed for an object where any of them is missing, so a wave is gated on its slowest object rather than its average one.
Licensing the target user too early breaks the migration. Identity mapping has to run before workload licenses are applied. A licensed account is given a mailbox, and a mailbox already sitting in the target is exactly what a cross-tenant move cannot accept. It is an ordinary administrative act performed in the wrong order, and it is the failure most likely to be introduced by someone helpful.
Some objects cannot be in a wave at all until something changes.Mailboxes on any kind of hold are blocked from migration. Microsoft supports moving users with no more than twelve auxiliary archive mailboxes. A batch is documented not to exceed two thousand mailboxes. Legal hold in particular is a governance question with a legal owner, which is why it is found during discovery rather than on the night.
Batches are submitted well ahead of the switch. Microsoft recommends submitting them substantially before the cut-over date, because synchronization has no effect on the people being migrated — the visible event is the switch, not the copy. The consequence is that a wave plan is mostly quiet work with a short loud moment at the end.
Published by Microsoft: Cross-Tenant Identity Mapping · Cross-tenant mailbox migration
Domains and mail flow
Moving a domain means removing it from the source and adding it to the target. Mail addressed to it is affected in the window between those two events.
The removal is the part that is underestimated. Microsoft will not release a domain while anything still references it. That means any user whose sign-in name, email address or proxy address uses it, any group with an address on it, and any application whose identifier is built from it. Every one has to be renamed off the domain first, and finding them is the work.
There is a forced option, and its cost is why it is rarely the plan. It renames every reference to the tenant's default onmicrosoft.com address and disables the user accounts it touches. It also refuses outright above a thousand references, on a multi-tenant application, or where the domain is federated. Microsoft documents the deletion itself as an asynchronous operation that may take up to twenty-four hours to complete.
That window is the reason the sequence exists. The domain cannot move before the mailboxes that use it are ready to receive on the other side, and those mailboxes cannot receive until the domain is there. The order is fixed by that dependency rather than chosen for convenience.
Everything that sends mail as the domain has to be found first. The scanner, the alerting system, the application that emails invoices. These are the things nobody has a list of, and they are why discovery precedes the cutover.
The commitment here is a stated cutover window with a rollback plan, and a pilot before it.
Published by Microsoft: Add and verify custom domain names
What actually moves
SharePoint, OneDrive and Teams move with the tenant, and each carries more than its files.
- Entra ID
Users, groups, guest accounts and the Conditional Access policies that govern them. Everything below depends on this landing first.
- Exchange Online
Mailboxes, shared mailboxes, distribution groups, transport rules and the connectors nobody documented.
- SharePoint
Sites, document libraries, permissions, and the sharing links embedded in documents.
- OneDrive
User files, and the sharing that came with them.
- Teams
Teams, channels, membership, and chat and channel history.
- Intune
Enrollment, compliance policies, BitLocker keys and Autopilot registrations. Devices do not follow the mailbox.
Platform names identify the workloads this work covers. Sunrise is not affiliated with or endorsed by their owners.
Buyers often name the workload rather than the tenant. A SharePoint, OneDrive or Teams tenant-to-tenant migration is not a separate engagement from the one above. It is this work, described by whichever part of it mattered most to whoever went looking.
What completion looks like
One identity model. One set of domains with mail flowing. SharePoint, OneDrive and Teams in one place, and devices enrolled against a single tenant.
The source tenant is decommissioned on a decision, with a date — never automatically, and never as a side effect of the last wave. There is usually data, licensing and at least one integration still attached to it, and each of those is a decision with an owner.
What is scope-dependent
These are the variables that determine what a consolidation involves.
- The number of tenants, and how much their user populations overlap
- Whether either side runs on-premises Active Directory or Exchange
- How much of the estate is outside Microsoft
- Whether a domain has to move at all
- How many applications authenticate against the source
- Whether the source tenant is being retired or kept
Questions people ask before committing
Can the same domain be used in both tenants during the move?
No. Microsoft will not verify a domain in more than one tenant, which is why the domain move is a cutover rather than a copy.
It also has a one-way quality worth knowing before the day: once a domain has been deleted from a tenant and verified somewhere else, it cannot simply be added back.
What happens to the email address people no longer have?
The old address cannot come across as an address. A domain belongs to one tenant, and that constraint applies to a single person exactly as it applies to the estate.
What does come across is the old identity in an internal form, and its job is that replies still work. Outlook stores the sender of an existing message, and the entries in its autocomplete, as that internal identity rather than as an email address. If it is missing on the other side, a reply to any pre-migration message fails to deliver. It is invisible when done correctly and unmistakable when it is not.
Can people still see each other's calendars while both tenants are live?
Yes, and it is configured deliberately rather than inherited. Free/busy sharing between two organizations is a setting each side turns on for the other, and the level is a choice — availability only, or availability with subject and location.
It also has to be arranged in both directions. The control is inbound: each organization decides what the other may see. A one-sided configuration produces the familiar situation where one half of the company can book the other and not the reverse. Microsoft is moving this to Cross-Tenant Access Policy, because the older mechanisms depend on a protocol being retired. Which method applies is therefore a fact about your tenants on the day, not a settled answer.
Does Teams chat history come across?
It depends on how the estate is moved, and the honest answer is that no single method moves everything a tenant contains.
What each method does and does not carry is set out on how an estate moves. The limits there are taken from the vendors' own documentation rather than from a capability list.
What decides how long this takes?
Four things, and none of them is the number of mailboxes. How much the two user populations overlap. Whether either side runs on-premises directory or Exchange. How many applications authenticate against the source. And whether a domain has to move at all.
Discovery is what turns those into a date. A firm quoting a consolidation timeline before it knows the answers is pricing an assumption, and the assumption that fails is usually the applications nobody had a list of.
What happens if a wave goes wrong?
Every wave has a rollback position defined before it runs. It states how far the wave can be taken back, and what has to be true before the next group starts.
Where that position sits depends on the method, and it is worth being specific. With Microsoft's own cross-tenant move the source mailbox is removed once the move completes, so the rollback lives in the wave boundary and the plan rather than in an intact source.
Does the second tenant get shut down at the end?
On a decision, with a date — never automatically, and never as a side effect of the last wave finishing.
There is usually data, licensing and at least one integration still attached to it, and each of those is an owned decision rather than a cleanup task.
Published by Microsoft: Cross-Tenant Access Policy for Free/Busy · Cross-Tenant Identity Mapping · Add and verify custom domain names
Start with what is actually there
The order of a consolidation is decided by what discovery finds, which is why the first engagement is usually an assessment rather than a migration.