In merger and divestiture projects, cross-tenant mailbox migration tends to be the biggest headache in Microsoft 365. In the tenants I work with, attention has recently moved to Microsoft's own tooling for moving Exchange Online mailboxes and OneDrive data between tenants. Not long ago, that job belonged almost entirely to third-party tools. Now the so-called migration application and cross-tenant mailbox migration (official docs) offer a first-party, multi-step approach. As usual, though, things are messier in practice than on paper.

Native cross-tenant mailbox migration needs groundwork in both tenants

Everything starts in the target tenant. You register a migration application in the Entra admin portal (Entra ID → Applications) so the two tenants can establish trust. After that, organization relationships have to be configured in both tenants, and you do this in Exchange Online PowerShell, not the admin portal. People miss that surprisingly often. In each source tenant you create a mail-enabled security group that scopes the users to be migrated. In the target tenant you create MailUser objects for those users. They need the correct ExchangeGuid and legacyExchangeDN properties, and the legacyExchangeDN has to be added as an X500 proxy address. Get this mapping wrong and the migration fails. It happens a lot, especially when user objects were only synced and never properly configured. If you want to see where cross-tenant synchronization comes in, have a look at my post on cross-tenant synchronization.

Every user you migrate needs a Cross-Tenant User Data Migration licence in the target tenant. Skip it and the migration stalls, and teams usually notice late in the project. I wouldn't rely on automatic licence assignment alone. I've seen that go wrong more than once.

# Assign Cross-Tenant Migration licence
you need PowerShell 7, Microsoft Graph PowerShell module, and Global Admin or licence admin in the target tenant
Update-MgUserLicense -UserId [email protected] -AddLicenses @(@{SkuId = 'c1d23c74-d3e9-43b1-8c5e-d9c1b0cc1d48'})

OneDrive migration has improved but still leaves things behind

OneDrive now has a native migration option too (docs), and it uses the same trust setup as mailboxes. The flow looks familiar. In the target tenant you use a migration application to connect source and target through the OneDrive admin center, then start the migration with a PowerShell script or in the portal. Keep in mind that content gets copied, but not all of it. Sharing links outside the tenant, external sharing permissions and workflows don't come across. Also left behind are Personal Vault, OneDrive settings and any files whose sensitivity labels the target tenant doesn't recognize.

Tip from practice: Before cutover, test how sharing links and permissions behave after migration. External sharing causes surprises regularly, even in pilots that were well planned.

MailUser objects, identities and cross-tenant sync have to line up

Mailbox migration only works if the user's identity already exists in the target tenant. That means either cross-tenant synchronization (Entra ID cross-tenant sync) or MailUser objects you create by hand. Synchronization usually runs alongside the migration so user identities and Azure AD objects stay consistent. The result is a coexistence period between the tenants, and it has to be managed carefully. If you haven't rolled out cross-tenant sync yet, think through whether it suits your scenario. I've written up my hands-on experience in Cross-tenant synchronization: B2B users provisioned at scale.

The ExchangeGuid and legacyExchangeDN mapping on MailUser objects matters a great deal, because Outlook profiles and recurring meetings in particular depend on it. Leaving out the X500 proxy address, or cleaning it up too soon after migration, is a classic mistake. That address is what keeps autocomplete, replies to old mail and calendar features working without hiccups.

This simple flowchart shows the technical stages of cross-tenant mailbox migration:

flowchart TD
    Source["Source tenant"] --> OrgRelSrc["Org. relationship config"]
    Target["Target tenant"] --> OrgRelTgt["Org. relationship config"]
    OrgRelSrc --> MigrationApp["Register migration app"]
    OrgRelTgt --> MigrationApp
    MigrationApp --> Licence["Assign licence"]
    Licence --> MailUser["Create MailUser object"]
    MailUser --> StartMigration["Start migration"]
    StartMigration --> Mailbox["Mailbox migrated"]

Figure: Native cross-tenant mailbox migration workflow

Several things stay behind and cutover needs careful planning

The tooling has improved, but there are still clear gaps. Mailbox settings, compliance and litigation hold data, and audit logs do not move. People keep asking me whether Teams chats, Planner tasks or delegated access move with the mailbox. They don't. On the OneDrive side, links shared with external users stop working, and Power Automate flows or complex sharing setups stay in the original tenant. Tell affected users about this before the migration, not after.

Most teams underestimate cutover planning. The final switch and the follow-up work (recreating Outlook profiles, checking proxy addresses, adjusting signatures and rules) often take longer than anyone expected. What has worked best for me is a full pilot with a small group first, OneDrive included, so the surprises surface before the bulk migration. Microsoft's M&A/divestiture playbook is a good overview, but it doesn't replace testing it yourself.

Native migration is real progress but still leaves a lot to do yourself

As an admin, I see native cross-tenant mailbox migration in Exchange Online and OneDrive as genuine progress, particularly for larger projects that want to avoid third-party tools. There's still a fair amount of manual work around identity mapping and licence assignment, though. Take the coexistence phase with cross-tenant sync seriously, because that's where many proxy address and permission problems show up. With good preparation, a pilot group and close attention to ExchangeGuid, X500 and licences, migrations today are far more reliable than they were just two years ago.