Cross-tenant mailbox migration: the prerequisites nobody reads until a batch fails
The move itself is one cmdlet. The reason your first batch fails at 2 a.m. is an attribute you didn't stamp on a target object three days earlier — and the service doesn't tell you until it tries.
New to cloud? CAMPUX is a free, build-first course. Start here →
Cross-tenant mailbox migration is the native Microsoft path for moving Exchange Online mailboxes from one Microsoft 365 tenant to another during a merger or divestiture. It is part of the wider Azure tenant-to-tenant migration guide, and it is the piece people underestimate most. The move engine is mature — you point New-MigrationBatch at a scoped group and MRS does the copy. What sinks projects is everything you had to build before that command runs. Miss one prerequisite and the batch doesn't half-work; it refuses. Below is the setup in the order it breaks batches, with the reason each item exists.
The migration application and consent in both tenants
The move is authorized by an app, not by a person. You register a multi-tenant application in the target tenant, remove the default User.Read permission it ships with, and add the Office 365 Exchange Online Mailbox.Migration application permission — that single scope is what lets MRS pull content across the boundary. Then both tenant administrators grant admin consent to it. The target consents in its own portal. The source administrator consents by opening an admin-consent URL you build from the app's client ID against the source's onmicrosoft.com name. This is not a formality: if the source has not consented when you run New-MigrationEndpoint in the target, that command fails with an authentication error, and you cannot proceed. Two organizations, one app, two consents — get all three wrong and nothing downstream works.
The organization relationship and the scoping group
Consent proves the app is trusted. The organization relationship is what actually opens the door for mailbox moves, and it is asymmetric. On the target you create a relationship with MailboxMoveCapability Inbound pointed at the source tenant ID. On the source you create the mirror with RemoteOutbound, pointed at the target tenant ID, carrying the app's ID and — critically — a MailboxMovePublishedScopes value. That scope is a mail-enabled security group in the source tenant. Microsoft's wording is blunt: the group is "used to scope the list of mailboxes that can move from source tenant to the target tenant," which lets the source administrator "restrict or scope the specific set of mailboxes" and prevent unintended users from being migrated. If a user isn't in that group, the source will not release the mailbox, full stop. For moves over 10,000 users, Microsoft recommends splitting into multiple groups for performance; nested groups work but are discouraged.
The scoping group is a safety catch, not a nicety. The source tenant will not release a mailbox that isn't inside it — which is exactly what you want the night someone fat-fingers a batch file.
The license, before you plan a single batch
This is the prerequisite that turns a planning meeting into an invoice. Every mailbox needs a Cross-tenant User Data Migration add-on license — a per-user, one-time charge assignable on either the source or target object, which also covers that user's OneDrive move. Without it the migration fails with CrossTenantMigrationWithoutLicensePermanentException, and Microsoft's documentation is unusually direct: "Microsoft doesn't offer exceptions for this licensing requirement." The add-on rides on the usual Microsoft 365 and Office 365 subscription plans, so both sides also need appropriate Exchange Online licensing on every user involved. Confirm you can actually purchase these licenses before you commit to a cutover date. Teams discover this at the worst possible moment — with a change window booked and no way to buy licenses in time.
The target MailUser and its attributes
Here is where most first batches die. For every mailbox you move, a MailUser object must already exist in the target — not a mailbox. If the target user already has an Exchange Online mailbox provisioned, the move fails. The MailUser is a placeholder, and it has to carry specific attributes copied from the source, because MRS validates identity before it moves a byte:
- ExchangeGUID — must match the source mailbox GUID. The move does not proceed if it is absent on the target.
- ArchiveGUID — must match, and is required only if the source mailbox is archive-enabled.
- LegacyExchangeDN — must be present on the target MailUser as an
x500:proxy address, and you must copy all x500 addresses from the source across too. Miss these and replies to pre-migration mail bounce with a 5.1.1 NDR, because Outlook's autocomplete cache resolves against the old LegacyExchangeDN. - Primary SMTP address — on a domain verified in the target tenant (the user's new company domain). A domain belongs to exactly one tenant, so you cannot carry the source vanity domain onto the target object.
- ExternalEmailAddress (targetAddress) — the routing address back to the still-live source mailbox, so mail flows during coexistence. Set the primary SMTP alongside it, or this value silently becomes the primary and the move fails.
Every attribute above is really one requirement: the person must exist as the same Exchange identity on both sides before content moves. That is downstream of a bigger question — who owns identity in the target, and is Entra provisioning them cleanly? If you haven't sorted directory sync, UPN alignment, and domain verification first, you are hand-stamping GUIDs onto objects that Entra will overwrite tomorrow. Settle identity — the foundation the whole tenant-to-tenant migration rests on — before you touch a mailbox batch.
The takeaway
Cross-tenant mailbox migration fails at the prerequisites, not the move. Register the migration app in the target with Mailbox.Migration, get admin consent in both tenants, build the inbound and outbound organization relationships with a mail-enabled security group scoping who is allowed to move, buy the per-user license, and provision every target user as a MailUser carrying the source ExchangeGUID, ArchiveGUID, LegacyExchangeDN as x500, and a primary SMTP on a verified domain. Do that and the batch is boring. Skip one and you lose a night reading MRS validation errors. Build the checklist once, verify it against a pilot user, and only then point a batch at production.
Questions people also ask
What are the prerequisites for cross-tenant mailbox migration?
You need a migration application registered in the target tenant with the Exchange Mailbox.Migration permission, admin consent granted in both tenants, an organization relationship on each side pointing at the other tenant ID, a mail-enabled security group in the source that scopes which mailboxes can move, a per-user migration license, and a target MailUser for every mailbox carrying the source ExchangeGUID, ArchiveGUID, and LegacyExchangeDN as an x500 proxy.
Can you do a cross-tenant mailbox migration without a third-party tool?
Yes, for mailboxes. Microsoft's native cross-tenant mailbox migration moves Exchange Online mailbox content directly between tenants using New-MigrationBatch and MRS, no third-party product required. It covers mailboxes only, though. OneDrive has a separate native path, and SharePoint, Teams, and identity mapping are where most teams still reach for a migration vendor to fill the gaps.
Why does the target need a MailUser instead of a mailbox?
The migration moves content into a mailbox it provisions during the move, so the target must be a MailUser, not an existing mailbox. If the target user already has an Exchange Online mailbox, the batch fails. The MailUser is a placeholder object carrying the routing address and the matched identity attributes; the service turns it into a real mailbox as the content lands.
Do both tenants need to grant admin consent to the migration app?
Yes. The migration application is registered once in the target tenant, but it is multi-tenant, and both tenant administrators must grant admin consent to it. The target consents in its own portal; the source consents by opening an admin-consent URL built from the app's client ID. If the source has not consented, creating the migration endpoint fails with an authentication error.
How much does a cross-tenant mailbox migration license cost?
Microsoft charges a per-user, one-time Cross-tenant User Data Migration add-on license, assignable on either the source or target object, and it also covers OneDrive migration for that user. Without it the move fails with a CrossTenantMigrationWithoutLicense error. Microsoft grants no exceptions to this, so confirm you can purchase the licenses before you plan a single batch.
What happens to the source mailbox after a cross-tenant migration?
After a successful move the source mailbox is deleted and converted to a MailUser whose targetAddress points at the destination tenant, which keeps mail routing and coexistence working. Only user-visible content — email, contacts, calendar, tasks, and notes — moves. Once deleted, the source mailbox is not discoverable or accessible in the source tenant under any circumstances, so verify before you cut over.