The deal completes on a Friday, and by Monday somebody has asked when everyone will be on the same email domain. You have two Microsoft 365 tenants, two sets of administrators, two ways of signing in and a date that was agreed by people who weren’t thinking about either. Moving users and data between tenants is doable, but it’s not a single operation, and the questions that decide whether it goes smoothly are mostly answered before any migration tool is opened.
This is the order we’d work through them in. It’s aimed at IT managers in organisations big enough to have several workloads and policies to carry over, and it assumes you have admin rights in both tenants. If you’re after the broader picture of tenant migration and consolidation as a service, that’s covered separately.
Pick the surviving tenant on evidence, not seniority
The default answer is “the acquirer’s tenant”, and it’s often right, but it’s worth checking against what each tenant holds. Look at licences and what they entitle people to, how much Conditional Access and device policy has been built, which tenant has the cleaner Entra ID setup, whether either one is hybrid with an on-premises Active Directory, and which one third-party apps and integrations are registered in. A tenant with a few years of tidy policy is a better destination than a larger one nobody dares touch.
Settle this in writing and with the people who will inherit the result. Everything after it is a consequence, including whether you’re moving, say, 400 users one way or 120 the other.
Domains decide your cutover shape
Email addresses are what users notice, so domains drive the plan more than anything else. Microsoft’s page on cross-tenant mailbox migration said the source and target tenants must use different domain names for the move, and that a domain belongs to one Entra ID or Exchange Online tenant only. So we’d expect a migrated user to start in the target tenant on an address from the target’s domain, with the old domain becoming a deliberate step later.
So decide early what each person’s final address will be, when the old domain moves, and what happens to mail sent to the old address in between. Shared mailboxes and distribution groups belong in this conversation too, because someone owns every one of them and nobody has a list.
What Microsoft’s native routes covered
The position depended on the workload, and it was uneven. The table summarises where Microsoft’s documentation stood, and you should check the current pages before planning against it.
| Workload | Native route documented | Status at the time | Worth knowing |
|---|---|---|---|
| Exchange mailboxes | Cross-tenant mailbox migration | Documented, with no preview label on the page | Mail, contacts, calendar, tasks and notes move; holds block a move; Microsoft 365 Groups (the group mailbox) aren’t supported by this route |
| OneDrive | Cross-tenant OneDrive migration | Documented, with no preview label on the page | A move, not a copy; no delta passes; target OneDrive must not already exist |
| SharePoint sites | Cross-tenant SharePoint migration | Private preview, for Enterprise Agreement customers who sign up | Teams content, channels and structure are excluded |
| Teams | None found in the pages we read | Not covered | Chat folder content doesn’t travel with a mailbox |
A few details change how you plan. Mailbox and OneDrive migration both need a per-user Cross Tenant User Data Migration licence, and migrations fail without it, so that’s a purchasing question to raise at the start and not the week before cutover. Mailboxes on hold aren’t migrated, and a hold policy blocks a OneDrive account too, which means someone has to decide how legal holds are handled before the move. And when a mailbox moves, its Teams meeting links aren’t updated, so Teams meetings will need recreating.
The OneDrive and SharePoint tools are one-way moves. Incremental and delta passes can’t be performed, and the OneDrive page adds that a redirect is left at the source. That’s fine for a clean cutover and awkward if you want to run both sides for a while, so it shapes the next section.
Teams is where expectations most often outrun the tooling. The SharePoint site migration page says plainly that its migration doesn’t include Teams content, channels or associated structure, so a Teams-connected site would arrive as a SharePoint site only and, as far as those pages go, the team around it would need rebuilding. We’d plan that as design work, with owners deciding which teams and channels are worth recreating. Where the native routes don’t reach, third-party migration tools are another option. Ask the same of any you consider: what it moves, what you rebuild, what happens to permissions and what it costs.
Cutover or coexistence
A single cutover weekend is simpler to communicate and leaves no long period of two tenants. It suits small user counts, a single workload or a hard deadline. Coexistence suits larger populations, because mailboxes can be moved in batches. Batches of no more than 2,000 mailboxes are the recommendation, submitted about two weeks before the cut-over date.
Coexistence has its own costs. Mail flow after a move works much like Exchange hybrid, with inbound filtering and transport rules running in the source tenant first and then the target, so you’re maintaining two sets of rules for the duration. Cross-tenant synchronization in Entra ID looks tempting for shared visibility, but Microsoft’s overview described it as not suitable for use across organisational boundaries, so don’t count on it to make the two tenants look alike while you migrate.
Coexistence earns its keep when the user count is large or the business can’t tolerate a day of disruption. We’d also fix the date coexistence ends in advance, because without one it tends to become the permanent state.
Identity, devices and apps need their own planning
The migration pages above don’t describe Conditional Access policies, MFA registrations, device enrolment or app registrations as moving between tenants, so, as planning advice and not a product claim, we’d plan on rebuilding them. We’d treat each as its own workstream with its own question. For identity, what is the final sign-in name for each person and who gets MFA re-registered, and when? For devices, how does each one leave the old tenant’s management and join the new, and is that done before or after the user’s mailbox moves? For apps, which integrations and enterprise applications authenticate against the old tenant, and who has to reconfigure them?
The device and app questions are the ones most likely to be missed because nobody sees them on a migration plan. Build an inventory from both tenants’ sign-in logs and app lists, not from memory, and mark each item as rebuilt, retired or still undecided.
Tell people twice, and keep a way back
Users will care about three things: whether their address changes, when they’ll need to sign in again and what they have to do on their phone and laptop. Say it once as a general notice and again individually shortly before their move, with the specific action required. Decide beforehand who answers the questions that follow, because they tend to arrive in a rush after each batch.
Rollback deserves a realistic look. For mailboxes, the page has a section on moving a mailbox back to the original source, though it means running the same steps again in both tenants, with some differences. After a successful move the source mailbox is deleted, so rolling back means moving it back and not reverting. For OneDrive and SharePoint, with moves that can’t be repeated incrementally and a source that’s emptied, going back means a second migration. So rollback is a decision about when you’re willing to stop being able to undo: test with a pilot group first, keep the source tenant intact until the target has run for an agreed period, and write down who calls the go or no-go.
A merger timetable rarely waits for the tenants to be ready, and the sooner the surviving tenant, the domains and the licence question are on paper the less that timetable can hurt you. If you’d like help with that early planning, get in touch with roughly how big each tenant is and when the business expects them to be one.
