Microsoft 365 Tenant-to-Tenant Migration: What Actually Breaks

The acquisition closed on a Friday. By Monday someone in the integration meeting says the line that starts every bad quarter: just move the mailboxes. The estimate that follows is built on mailbox sizes and a per-user migration tool, and it is wrong by about three months.

Mailbox content is the easy part. It copies in the background, it can run for weeks, and nobody has to be awake for it. The hard part is a single constraint in Microsoft Entra ID that governs the entire schedule.

A custom domain can exist in exactly one tenant

Microsoft's Entra documentation states it plainly: Microsoft will not allow a domain name to be verified with more than one Microsoft Entra tenant. There is no shared mode, no overlap window, no split verification. The acquired company's domain lives in the source tenant until the moment it does not, and only then can it be verified in the target.

That single fact reorders the whole project. You are not scheduling a content migration with a domain change attached. You are scheduling a domain removal, and everything else is arranged around it. The mailbox moves are preparation. The domain move is the event.

It gets sharper. The same documentation warns that once you delete a domain name from your tenant, you cannot re-add or re-verify it with your tenant if it is subsequently added and verified with another tenant. The removal is one-directional in practice. You cannot rehearse it. There is no staging environment where you pull the domain out, watch what breaks, and put it back. You get one attempt, live, with the business watching.

What must be cleaned up before Microsoft will release the domain

Microsoft blocks the removal until nothing references the domain. Entra's guidance is specific: you cannot delete a domain name if any user has a username, email address, or proxy address that includes it; if any group has an email address or proxy address that includes it; or if any application in your Entra tenant has an app ID URI that includes it.

The Microsoft 365 admin center adds its own preconditions before a domain can be removed:

• The domain is not the default domain
• No users, shared mailboxes, resource mailboxes, or contacts use the domain
• No Microsoft 365 groups, distribution lists, or teams use the domain
• The domain is not used for sign-in by any admin accounts
• You understand how mail flow changes if the domain has MX records pointing to Microsoft 365

Read that list against a real tenant and the scope becomes obvious. It is not just the mailboxes people talk about. It is every proxy address on every object: the room and equipment mailboxes, the mail contacts nobody has touched in years, the distribution lists that fire once a year, the Microsoft 365 group behind each team, and the app ID URIs on line-of-business applications registered by someone who has since left.

ForceDelete is not the escape hatch it looks like

Entra offers a ForceDelete option that asynchronously rewrites references from the custom domain to the initial default domain on the onmicrosoft.com name. It has hard limits. It fails if the number of objects to be renamed is greater than 1,000. Exchange mail-enabled security groups and distribution lists must still be updated or removed by hand. And it does not work at all if the domain uses federated authentication. On a tenant of any size with an on-premises federation history, ForceDelete is unavailable exactly when you would want it most.

What Microsoft moves natively, and what it charges for

Native cross-tenant migration exists and has grown, but it is licensed and it is bounded. Cross-tenant moves require a Cross-Tenant User Data Migration license, a one-time per-user fee assignable to either the source or target user object. Microsoft's warning is blunt: migrations fail if this step is not completed, and Microsoft does not offer exceptions for this licensing requirement.

Microsoft's migration orchestrator covers four workloads: Exchange mailboxes, OneDrive, Teams chats, and Teams meetings. Teams meeting migration depends on mailbox migration, and a batch fails to initiate if meetings are selected without also selecting chats and mailboxes.

What it does not cover is stated just as directly: the Cross-Tenant User Data Migration solution does not migrate shared data, such as Teams and Channels or SharePoint sites, and that data remains in the source tenant. SharePoint sites are a separate product, Cross-Tenant Shared Data Migration, licensed per 100 GB of data moved and currently available only to Enterprise Agreement customers. Even that one carries a carve-out: it does not include migration of Teams content, channels, or associated structure. Migrate a Teams-connected SharePoint site and you get the site content, not the team.

OneDrive has its own shape. Cross-tenant OneDrive moves are one-and-done, with no incremental or delta passes, and they leave a redirect at the source location so existing shared links continue to resolve until the source tenant is deprovisioned. Accounts with hold policies applied are blocked until the hold is removed.

Teams is where the expectation gap lives

Users assume Teams moves because their chats moved. Channel conversations are the surprise. Channel messages are shared data, they stay in the source tenant, and no native tool brings them across. Third-party tooling can reconstruct channel history, but reconstruction is the right word: messages are re-posted through import APIs, and what arrives is a readable transcript rather than the original threads with original authorship intact.

Even the chats that do migrate arrive incomplete. Microsoft's own known-issues list for the orchestrator includes:

• Reactions to chat messages are not migrated
• Apps are not migrated, including polls, and app messages are not migrated
• Deleted messages and self-chats are not migrated
• Messages over 4 MB, messages with code snippets, and attachments that are not common image formats do not migrate
• Meeting recordings, transcripts, recaps, and attendance reports are not migrated
• Channel and shared channel meetings are not migrated, and all responses are reset

There is a further wrinkle worth flagging to anyone who thinks a second attempt is available. Migrated chat threads remain accessible in the source tenant and are not locked, but new messages sent there after migration do not migrate. And the same set of users cannot be migrated again to a different target tenant once source objects are deleted or mail forwarding is disabled. Scope this honestly at the start. Users told in advance that reactions and polls will not survive accept it. Users who discover it on Monday morning file tickets.

The mailbox details that get missed

Cross-tenant mailbox migration moves user-visible content: email, contacts, calendar, tasks, and notes. Several things do not follow it.

Mailboxes on any type of hold are not migrated, and the move for those mailboxes is blocked. On an acquisition with any litigation or compliance history, that can be a meaningful slice of the user base, and each one has to be resolved individually before it will move.

Permissions are the scheduling trap inside the scheduling trap. Mailbox permissions stored in the mailbox move with the mailbox only when both the principal and the delegate move together. Cross-tenant mailbox and calendar permissions are not supported, so principals and delegates must be organized into consolidated batches and moved at the same time. The executive and both assistants go in one wave, or the assistants lose access until the last of them lands. Send on behalf is stored in the directory rather than the mailbox, so it has to be restamped on the target after the mail user converts to a mailbox.

Microsoft 365 groups are not supported by cross-tenant mailbox migration at all. Mailbox signatures are not migrated and must be recreated. Teams chat folder content inside the mailbox does not migrate, though a source-tenant administrator can still search and export it. And after a successful migration the source mailbox is deleted, so it is not available, discoverable, or accessible in the source tenant afterward. Anyone expecting to fall back to the old mailbox is expecting something that no longer exists.

One sequencing detail causes avoidable rework: do not assign the target Exchange Online license before stamping the mailbox GUID attribute, or the mail user conversion fails and a brand new empty mailbox is created instead.

Identity, devices, and the re-registration tax

Cross-tenant synchronization is often proposed as the identity answer. Microsoft says otherwise: it is not a migration tool, because the source tenant is required for synchronized users to authenticate. It creates external members or guests in the target, it does not move accounts, and devices and contacts are not supported.

A migrated user is a new object in a new directory. Authentication methods are managed on the user object within a tenant, and Microsoft documents no mechanism to transfer them between tenants. Every user re-registers multifactor authentication: a new authenticator entry, a new passkey or security key registration, new phone verification. That lands on cutover day, alongside everything else.

There is a related trap for organizations that set up a multitenant organization for day-one collaboration. Converting those guests into internal members is a required migration step, and Microsoft notes that this conversion breaks the multitenant collaboration experience. Keeping both means provisioning separate user objects for migration.

Devices are harder, because they are physical. Autopilot registration associates a device's hardware identity with a tenant ID. Devices leaving one organization for another have to be deregistered from Autopilot, removed from Intune, and cleaned out of Entra, in that order, because skipping steps or removing records out of order can result in orphaned records or unrecoverable devices. Then each machine re-enrolls, re-applies configuration and compliance policy, and re-syncs OneDrive from scratch. Multiply that across a fleet and it becomes a bandwidth problem, a helpdesk problem, and a schedule problem at once.

Coexistence costs money and degrades quietly

Between announcement and cutover, both tenants run. All users in both organizations must be licensed with the appropriate Exchange Online subscriptions, on top of the per-user migration licenses. That overlap is real money that rarely appears in the integration budget, and it grows every week the cutover slips.

Free and busy sharing across tenants is changing underneath these projects. Cross-Tenant Access Policy is now the standard for sharing availability, calendars, and mail tips between Microsoft 365 tenants, replacing organization relationships and sharing policies, because the older path relies on Exchange Web Services, which is being deprecated in Exchange Online. It is an inbound setting, so both organizations must create complementary policies for sharing to work in both directions. Anyone reusing a runbook written a few years ago is configuring a mechanism on its way out.

Mail flow during coexistence works by referral. Once a mailbox moves, the source object becomes a mail user stamped with a target address pointing at the destination tenant, and mail routes onward from there. Availability lookups do not follow the same path: while mail routing can follow referrals across multiple mail users, availability lookups must target the location of the mailbox itself. Calendar visibility therefore degrades on a different schedule than mail delivery, which is why calendar complaints tend to arrive in week two rather than on cutover night.

The part that cannot be tested

This work overruns because of a mismatch between what gets rehearsed and what carries the risk. Content migration is rehearsable and mostly forgiving. You can validate the configuration with a migration endpoint test, run pilot batches, check results, and run more. When a single user's move fails, the blast radius is one user.

The domain move is neither rehearsable nor contained. Every proxy address has to be off it, every group renamed, every app ID URI rewritten, admin sign-in moved elsewhere, and MX changed, in a window where mail is landing somewhere and users are authenticating against something. Build the plan backward from that hour. Inventory every object carrying the domain in week one rather than week ten, because that inventory is the actual work breakdown structure for the project. Mailbox size only determines how early the copying starts. It has no bearing on the one moment that can go wrong in a way you cannot undo.