Exchange Online is often one of the most critical workloads in a Microsoft 365 tenant-to-tenant migration. During mergers, acquisitions, divestitures, or tenant consolidations, organizations need to move mailboxes without disrupting email delivery, calendar access, or day-to-day business operations.

Microsoft provides native cross-tenant mailbox migration capabilities, but moving mailbox data is only part of the process. Recipient mapping, permissions, mail flow, domain ownership, and coexistence all need careful planning.

In this article, we look at the key considerations for Exchange Online cross-tenant mailbox migrations and some common challenges organizations should address before moving their users.

Mailbox Moves: Start with the Prerequisites

Microsoft’s native cross-tenant mailbox migration uses the Mailbox Replication Service (MRS) to move supported mailbox content between tenants. Before creating migration batches, both environments must be prepared.

Key prerequisites include:

• Configuring the required migration application, organization relationship, and migration endpoint.
• Provisioning destination MailUser objects with the correct attributes.
• Assigning the required migration licenses and permissions.
• Validating mailbox identities, Exchange GUIDs, UPNs, and SMTP addresses.
• Reviewing mailbox holds, retention requirements, and migration eligibility.

Mailbox mapping deserves particular attention. In acquisitions, the destination UPN may differ from the source UPN, even when the user’s email address remains unchanged. Incorrect recipient attributes can lead to migration failures or mail-routing problems.

Microsoft recommends submitting migration batches approximately two weeks before cutover to allow synchronization and preparation. Batch sizes and timelines should be planned according to Microsoft’s current guidance and the organization’s mailbox volumes.

Hybrid Environments: Understand What Remains

Organizations with hybrid Exchange environments need additional planning. A mailbox hosted on-premises cannot automatically be treated like an Exchange Online mailbox for native cross-tenant migration.

Before starting, identify where each mailbox resides, how recipient attributes are managed, and whether on-premises Exchange, Active Directory synchronization, or existing connectors remain part of the messaging architecture.

Moving mailboxes to another tenant does not necessarily eliminate the need for on-premises Exchange infrastructure or recipient-management capabilities.

Recommendation: Document hybrid dependencies before migration and agree on the decommissioning strategy with the identity and messaging teams. Do not retire existing infrastructure simply because mailbox migration has completed.

Shared and Resource Mailboxes Need Special Attention

Shared mailboxes, meeting rooms, and equipment mailboxes often support business processes that are easy to overlook during migration planning.

For shared mailboxes, document Full Access, Send As, and Send on Behalf permissions. Although supported mailbox content and some mailbox permissions are retained during migration, cross-tenant delegation relationships and calendar permissions may need to be recreated and tested.

For room and equipment mailboxes, review booking policies, resource delegates, calendar processing settings, and room-list membership. Validate that users can still book rooms and that approval or automatic acceptance workflows behave as expected.

Treat these mailboxes as business services, not just additional items in a migration batch.

Mail Flow and MX Cutover

Mail flow is one of the most sensitive parts of a cross-tenant migration. A mailbox may move successfully while messages still fail because recipient routing, connectors, or domain configuration has not been updated correctly.

During coexistence, source-tenant MailUser objects can route messages to mailboxes that have moved to the destination tenant. This allows migrated and unmigrated users to continue communicating, provided the required routing configuration is correct.

The MX cutover is a separate consideration. The MX record determines where external mail servers deliver inbound email, but changing it does not move mailboxes or transfer a custom domain between tenants.

Microsoft 365 custom domains cannot simply remain configured as accepted domains in both tenants simultaneously. Domain release, destination verification, recipient configuration, and DNS changes must therefore be coordinated carefully.

Before cutover, validate:

• Accepted domains, connectors, transport rules, and routing addresses.
• Internal and external mail flow in both directions.
• Application-generated email and SMTP relay dependencies.
• MX records, SPF, DKIM, and DMARC configuration.
• Third-party email security gateways and TLS requirements.

Lowering DNS TTL in advance can help reduce the impact of DNS caching, but it does not guarantee an immediate transition.

Coexistence and User Communication

In larger organizations, moving everyone at once is rarely practical. Department-based, geographic, or phased migration waves allow teams to validate the process before expanding it across the organization.

However, coexistence introduces its own challenges. Users in different tenants may need to share calendar availability, access delegated mailboxes, schedule meetings, or book rooms. These scenarios should be tested before production migration waves begin.

User communication is equally important. Employees should know when their mailbox will move, whether their sign-in details will change, what to expect in Outlook and on mobile devices, and where to get help.

Prepare the service desk with migration schedules, destination account details, troubleshooting procedures, and escalation paths for identity, mail flow, and permissions issues.

A successful migration is not simply a completed mailbox move. It is a transition in which users can continue working without unexpected disruption.

How Olive + Goose Can Help

Olive + Goose helps organizations plan and execute Microsoft 365 tenant-to-tenant migrations with a focus on technical readiness, business continuity, and post-migration validation.

Our approach can support Exchange Online assessment, mailbox mapping, hybrid dependency reviews, migration-wave planning, mail-flow architecture, domain cutover, and post-migration testing.

We also consider the wider Microsoft 365 environment, including Microsoft Entra ID, Teams, SharePoint Online, and Power Platform. These workloads often have dependencies that must be addressed alongside mailbox migration.

By identifying risks early and coordinating the migration across workloads, organizations can reduce avoidable incidents and establish a clearer path to a successful transition.

Conclusion

Exchange Online cross-tenant migration provides a supported way to move mailbox data between Microsoft 365 tenants, but enterprise success depends on much more than the migration process itself.

Correct recipient mapping, shared mailbox permissions, hybrid dependencies, mail routing, domain ownership, and user readiness all need to be addressed.

The most effective approach is to plan these components together, test representative scenarios before cutover, and validate the business-critical services users rely on every day.

References

• Cross-tenant mailbox migration
• Exchange mailbox migration
• Exchange Online mail flow best practices

This article is part of the Olive + Goose series on Microsoft 365 cross-tenant migration risks, planning, and best practices.