Cross Tenant Mailbox Migration Services By WME
Two tenants. One deadline. Zero tolerance for mail disruption.
M&A, Consolidations, and Separations All Land Here
Mergers. Acquisitions. Company splits.
Every one of them leaves IT teams with the same problem: Exchange Online mailboxes remain split across separate Microsoft 365 tenants after the organizational change.
Cross-tenant mailbox migration fixes that.
User mailboxes, shared and archive mailboxes, and public folders, moved from the source tenant to the destination tenant, sequenced so users stay operational throughout.
This covers:
Two organizations merging into a single new tenant
- Two organizations merging into a single new tenant
- A business unit separating into its own 365 tenant
- IT teams consolidating multiple tenants post-acquisition
- Exchange on-premises environments moving into a new Exchange Online tenant simultaneously
Trusted by 500+ Global Brands and Backed by Industry Leading Tech Partners
What Makes Tenant-to-Tenant Moves Hard
Microsoft 365 does not treat cross-tenant mailbox moves as a simple transfer. Every 365 tenant is isolated.
Getting mailboxes across requires satisfying a long prerequisite list, on both the source tenant and target organization, before a single Move Mailboxes request is submitted.
Identity mismatch kills batches
Every source mailbox needs a pre-created MailUser object in the destination tenant. EmailAddresses, proxy addresses, and ExchangeGuid must align exactly. User identity is mapped using UPNs or SMTP addresses tied to matching Microsoft Entra ID objects in both tenants. One mismatch and the migration batch fails.
Application setup has no shortcuts
The migration application must be registered in Microsoft Entra on both tenants. Application ID, API permissions, client secret, targetTenantId, adminconsent, SourceEndpoint, and DomainNames all configured correctly. Miss one step and the Cross-TenantMoves configuration can fail completely.
Not everything moves with the mailbox
Shared, even archive mailboxes, and public folders sit outside the standard migration batch flow. Mail-enabled security groups don't migrate; they get rebuilt. Distribution lists must be validated for membership accuracy and mail routing behavior after migration. Mailbox sizes affect batch sequencing.
Permissions don't carry over
Send As, Full Access, delegate access, and whatnot, mailbox permissions must be re-applied manually in the target organization. Mailbox access breaks immediately post-migration if this is skipped.
User experience takes the hit
Outlook profiles break after every cross-tenant move. Email domains need careful handling during transition. Without a cutover plan, the helpdesk gets flooded the morning after migration.
Your users need one environment.
Your IT team needs one tenant.
Your business needs a successful migration.
What Gets Locked In Before Anything Moves
|
READINESS AREA |
REQUIREMENT |
|
OrganizationRelationship |
Established between source and destination tenant |
|
MailUser Objects |
Pre-created with correct EmailAddresses, proxy addresses, userId |
|
Microsoft Entra |
App registrations, application ID, API permissions, client secret, adminconsent |
|
targetTenantId & SourceEndpoint |
Configurations are validated through Exchange Online PowerShell before migration batches are executed. |
|
DomainNames |
Configured in the target organization |
|
Migration License |
Assigned in the new tenant before move completes |
|
CSV File |
Validated with correct dataType and userId fields |
|
Migration Scope |
User mailboxes, shared mailboxes, archive mailboxes, public folders, mailbox sizes, retention policies |
|
Testing |
Test-MigrationServerAvailability -EndPoint run on test user before production |
|
Mailbox Permissions |
Documented and scheduled for re-application post-migration |
This is the migration assessment phase. Skipping it is what turns migration projects into incidents.
Phased batches. Not a big bang
Using a Demand Migration approach, business-critical user mailboxes move first. The remaining number of users follow in controlled waves. Mail flow stays intact. IT teams stay in control.
Mail flow continuity is sequenced
DNS records and MX changes are tied to each migration batch completion. Mail routing gaps during the transition window cause message loss. Zero downtime on mail flow is a sequencing discipline instead of being a promise.
End users need preparation
Outlook profiles require reconfiguration after moving to the new organization. SharePoint Online access and Microsoft Teams continuity need separate validation. Neither is covered by the Exchange Online mailbox migration itself.
Validation happens immediately
Email addresses, proxy addresses, mailbox access, address list membership, and mailbox permissions, verified early post-cutover. Technical support is live during the migration window, not available the next business day.
Cutover Planning Is Where Projects Fail or Succeed
Assessment
Full audit of user, archive, and shared mailboxes, public folders, mail-enabled security groups, distribution lists, mailbox permissions, sizes, content, and retention policies. Migration scope is defined before any configuration begins.
Configuration
Complete setup across both tenants. Exchange Online PowerShell is used throughout. dataType parameters validated. Migration configurations documented end to end. CSV file verified before batch submission.
Execution
Migration batches built, submitted, and monitored in real time via Exchange Online PowerShell and admin center. Move Mailboxes requests tracked across both source tenant and target organization. Demand Migration sequencing applied for large Exchange migration projects. Quest On-Demand Migration tooling used where applicable.
Validation
Every migrated mailbox checked. Email & proxy addresses, mailbox access and permissions, Outlook profile connectivity, Microsoft Teams access, SharePoint Online access, email domains in the new organization. Full handoff report delivered to IT teams with next steps.
How We Execute It
One Tenant. One Environment. WME Gets You There.
Every day your organization runs split across two Microsoft 365 tenants, the cost compounds. Licensing waste, security gaps, fragmented communication, and a migration that gets harder the longer it waits.
The split is temporary. The damage from a bad migration isn’t.
WME has executed cross-tenant mailbox migrations across M&A, consolidation, and separation projects. We know where these migrations break, and how to make sure yours doesn’t.