The plumbing is in place. Now you actually move the mail.
The consent is granted, the endpoint exists, the target MailUsers are stamped. This is the part where mailboxes leave one tenant and arrive in another — the batch, the move, and the one command that flips the source mailbox into a forwarding stub.
New to cloud? CAMPUX is a free, build-first course. Start here →
This is the execution half of a two-part job, and it only works if the first half is done. If you have not already built the migration application, granted consent on both sides, created the endpoint, and provisioned the target MailUsers with matching ExchangeGUIDs, stop and go run the prerequisites first — this article assumes all of that is finished. It is part of the broader Azure tenant-to-tenant migration guide, and it picks up at the moment you are ready to move real mail.
The target tenant does the pulling
Here is the mental model that trips people up: the mailboxes do not get pushed out of the old tenant. They get pulled in by the new one. Microsoft is explicit that cross-tenant migrations are initiated from the target tenant as migration batches, and that the process is similar to an on-boarding move from Exchange on-premises into Microsoft 365. The source tenant already gave its consent and published the scope group during the prerequisite work; from here, you run everything from the target side.
Before you create a batch, prove the endpoint actually answers. From the target tenant, run Test-MigrationServerAvailability against your cross-tenant endpoint with a target MailUser as the test mailbox. If that comes back healthy, the OAuth trust, the endpoint, and the object are all wired correctly and you can move on. If it fails, you have a consent or attribute problem to fix before a batch will ever sync.
Creating and starting the batch
You create the move with New-MigrationBatch, which is exposed through the Move Mailboxes management role. You feed it the cross-tenant endpoint as the source, a CSV of users, and a target delivery domain. One detail that costs people an afternoon: the email address in the CSV must be the address in the target tenant — the new onmicrosoft.com or verified domain — not the address the mailbox currently uses in the source. A minimal batch looks like this:
New-MigrationBatch -Name T2Tbatch -SourceEndpoint your_endpoint -CSVData ([System.IO.File]::ReadAllBytes('users.csv')) -Autostart -TargetDeliveryDomain northwindtraders.onmicrosoft.com
With -Autostart, the batch begins syncing straight away and the Mailbox Replication Service starts copying content into the target MailUser. The move is a conversion, not a double copy — MRS connects the source mailbox to the target object and pulls the data across once, rather than staging a full second copy somewhere in between. You can also submit the batch from the new Exchange admin center by choosing the cross-tenant option, if you would rather not touch PowerShell for this step.
Two different licenses are in play, and confusing them wrecks a batch. Every user needs a Cross-Tenant User Data Migration license — a one-time per-user fee you can assign on either the source or the target object. Without it the move fails with a plain licensing error, and Microsoft grants no exceptions. Separately, the target MailUser needs an ordinary Exchange Online license, but timing matters: apply it only after the ExchangeGUID and proxy addresses are set. License the object too early and Exchange provisions a brand-new empty mailbox on it, which no longer matches the source and cannot receive the move.
Watching the move without guessing
Once the batch is syncing, you monitor rather than babysit. Get-MigrationBatch gives you the batch-level status, and Get-MigrationUser drills into individual users. Because the underlying mechanism is an MRS move, you can also inspect the move requests directly, and there is a neat filter for cutting through the noise: Get-MoveRequest -Flags "CrossTenant" shows only the cross-tenant moves and hides your ordinary on-boarding and off-boarding activity. For per-mailbox byte counts and percentage complete, Get-MoveRequestStatistics is where you look.
The bulk sync runs while people keep working. Only completion is the cutover.
The batch reaches a status of Synced (or SyncedWithErrors) and then holds there. That is by design — the initial copy is done, incremental syncs keep it current, and the mailbox is still live in the source tenant. Nothing has cut over yet. Users are still reading and sending from their old mailbox while all of this happens in the background, which is exactly what you want on a weeknight before a weekend cutover.
Completion is the moment that matters
When you are ready to flip users to their new home, you finalize. Run Complete-MigrationBatch against the batch once it is Synced, and for each mailbox it does three things: a final incremental synchronization, a reconfiguration of the Outlook profile to point at the new target domain, and the conversion of the source mailbox to a mail-enabled user. That last step is the whole point of the exercise. The source mailbox becomes a MailUser, its ExternalEmailAddress — the targetAddress — is stamped with a routing address to the destination tenant, and the visible content in the source is deleted. Mail sent to the old address now forwards cleanly to the mailbox in its new tenant. If you would rather not run a separate completion step, you can pass -AutoComplete when you create the batch, and each mailbox finalizes as soon as its own initial sync finishes.
One caution worth stating plainly: after completion the source mailbox is gone. Microsoft's language is blunt — under no circumstances is the source mailbox available, discoverable, or accessible in the source tenant afterward. There is no undo button hiding in the portal. Complete when you mean it.
The first morning in the new tenant
Completion is not quite the end of the human experience. Because a domain can belong to only one tenant, the old primary SMTP address does not follow the user into the target, so their existing Outlook profile cannot find the migrated mailbox. On day one, users rebuild their Outlook profile with the new UPN and primary address and let the OST resync. Plan your completion batches around that — a few hundred clients pulling fresh OST and OAB files at once is real network load. In a hybrid target, if you want these users to appear as remote mailboxes on-premises, run Enable-RemoteMailbox against the migrated MailUser, and update the targetAddress on the corresponding on-premises objects in both directories so free/busy and routing keep pointing at the right place.
The takeaway
The execution is smaller than the prep, which is the whole reason the prep matters. From the target tenant you test the endpoint, create the batch against the cross-tenant source with target-tenant addresses in the CSV, let MRS sync in the background while people keep working, then run Complete-MigrationBatch to cut over. Completion converts the source mailbox to a forwarding MailUser and deletes the original, so there is no going back and no double copy — just one clean handoff. Get the licenses right, watch the batch reach Synced, and finalize on a schedule that gives your users' laptops room to rebuild.
Questions people also ask
Which tenant runs a cross-tenant mailbox migration?
The target tenant, the one receiving the mailboxes. Cross-tenant moves are initiated from the target as migration batches against the cross-tenant endpoint, and the Mailbox Replication Service pulls the content across. The source tenant grants consent and scope up front, but it does not push the data. This mirrors how an on-boarding move from Exchange on-premises to Microsoft 365 works.
What happens to the source mailbox after a cross-tenant migration?
On completion, the source mailbox is converted to a MailUser and its ExternalEmailAddress, the targetAddress, is stamped with a routing address to the destination tenant. The visible content in the source mailbox is deleted and is no longer discoverable there. The leftover MailUser exists so mail keeps routing to the mailbox in its new home.
Do you need a license for cross-tenant mailbox migration?
Yes. Each user needs a Cross-Tenant User Data Migration license, a one-time per-user fee you can assign on either the source or target object. Without it the move fails with a licensing error, and Microsoft grants no exceptions. Separately, the target MailUser needs an Exchange Online license, but apply that only after the ExchangeGUID and proxy addresses are set.
How do you complete a cross-tenant migration batch?
Once the batch reaches Synced or SyncedWithErrors, run Complete-MigrationBatch to finalize it. That runs a final incremental sync, points the Outlook profile at the new target domain, and converts the source mailbox to a mail-enabled user. You can also pass AutoComplete when you create the batch, which finalizes each mailbox as soon as its initial sync finishes.
Is there downtime during a cross-tenant mailbox migration?
The bulk sync runs in the background with the user still working in the source mailbox, so most of the move is invisible. The cutover happens at completion. After that, because the old primary address belongs to a different tenant, users rebuild their Outlook profile with the new UPN and address and resync the OST, so plan the finalization for a quiet window.