Home › Blog › Tenant migration
Guide · Tenant migration
Free, built into Exchange Online, higher fidelity than copying items, and with prerequisites that stall most first attempts. What has to exist before the batch runs, the sequence, and what it leaves for other tools.
By Alex Makey · 6 September 2026 · 7 min read · Verified against Microsoft documentation, September 2026
For years the only way to move mailboxes between tenants was a third-party tool. Microsoft now has its own: cross-tenant mailbox migration, built into Exchange Online. It is free, it moves mailboxes at the Exchange level rather than copying items, and it has a set of prerequisites that stop most people on the first attempt. Here is what it does, what it needs, and where it is not enough.
It moves a mailbox from one tenant to another the way an on-premises to cloud migration moves one: the whole mailbox, with folder structure, item properties and retained metadata intact, using the same migration service that runs onboarding batches. After the move, the source mailbox becomes a mail-enabled user pointing at the target, and the target mailbox is the real one.
What it does not do: files, Teams, groups, SharePoint. It is a mailbox move, and only a mailbox move.
An organisation relationship in both directions. The two tenants have to know about each other and trust each other for migration. This is configured in Exchange Online PowerShell on each side with the other tenant’s identity.
A migration application registered in the target tenant and consented in the source. The target creates an Entra application with the mailbox migration permission; the source grants consent to it. This is the step that trips people up: consent has to be granted by a Global Administrator in the source, using the target’s application ID, and the permission is specific.
A migration endpoint in the target pointing at the source, created with the application’s identity.
Mail-enabled user placeholders in the target for every mailbox you intend to move, with matching attributes — most importantly the source mailbox’s ExchangeGuid and the source tenant’s legacy DN as an X500 address. Without the GUID the move has nowhere to land. The usual method is a script that reads them from the source and stamps them on the target objects.
Licences in the target for every user, assigned before the batch runs. A move into an unlicensed target object fails.
A verified domain in the target for the target addresses. The source domain does not move yet; that is a separate, later step.
New-MigrationBatch with a CSV of the users; start itMicrosoft’s documentation has the exact cmdlets and a preparation script for step 5. The names have changed across versions; work from the current page rather than a blog post, including this one.
Fidelity. A native move preserves things item-level copies lose: item identifiers, some calendar internals, recoverable items, the archive as a unit. Recurring meetings survive better. Cost: there is no per-mailbox licence. And it is Microsoft’s own mechanism, which matters when something goes wrong and you need support.
Everything that is not a mailbox. OneDrive, SharePoint, Teams and groups need another method. Most consolidations still end up with a third-party tool for the file side and the native move for mail.
Coexistence. The native move does not give you free/busy between tenants during the transition; that is a separate organisation relationship for calendar sharing. It does not handle mail flow during cutover either.
Preparation at scale. Stamping a thousand mail-enabled users with the right attributes is scripting work, and a mistake in it surfaces as a failed batch with an unhelpful error. This is where the time goes.
The concurrency ceiling still applies. It is the same migration service, with the same limits, so the same arithmetic on schedule.
For mail, use it. It is better than copying items and it costs nothing. Budget the preparation honestly — the placeholders and the consent are where a first attempt stalls — and plan the file and Teams side separately, because Microsoft has not given you a native answer for those and probably will not.
One email a month, at most
Postmortems, timelines, licensing changes that cost people money. If a month has nothing worth your time, you hear nothing.
Please enter a work email address.
Done. Unsubscribe by replying to any email; we will not argue.
Related questions
Yes: cross-tenant mailbox migration in Exchange Online. It moves whole mailboxes with metadata intact using the migration service, at no per-mailbox cost. It covers mailboxes only; files, Teams and groups need another method.
An organisation relationship between the tenants, a migration application registered in the target and consented in the source, a migration endpoint, mail-enabled user placeholders in the target carrying the source mailbox ExchangeGuid and X500 address, and target licences assigned before the batch runs.
Most often because the target mail-enabled user is missing the source ExchangeGuid or X500 address, because the target object has no licence, or because consent to the migration application was not granted by a Global Administrator in the source tenant.
For mailbox fidelity, usually yes: it preserves item identifiers, recoverable items and archives as a unit, and costs nothing per mailbox. Third-party tools remain necessary for OneDrive, SharePoint and Teams, and offer easier preparation and coexistence features.
No. The domain move is a separate, later step. Mailboxes move onto target addresses on a domain the target already holds, and the source domain is moved after the mailboxes are in place.
Rather not do this yourself?
Describe the situation and you get back a sequence, an honest view of what will be slow, and a fixed price — usually within one business day. Or ask one question and get one answer.