Exchange On-Premises to Multiple Exchange Online Tenants Migration - Guidance Required for Multi-Entity Mailbox Design

Hi Muhammad Adeeb

Based on my research, this scenario is best viewed as a tenant carve-out (divestiture) rather than a traditional Exchange migration. The technical migration is only part of the project; the larger challenge is defining ownership of mailboxes, SMTP addresses, archives, groups, resources, permissions, and compliance data across the future Microsoft 365 tenants.

A few key principles should drive the target-state design:

• Every SMTP address must have a single authoritative owner.
• Every mailbox, shared mailbox, room mailbox, and archive should have a clearly defined owning entity.
• Microsoft migration tools move mailboxes as whole objects and do not natively split mailbox content across multiple destination tenants.
• A custom domain can only be verified and used in one Microsoft 365 tenant at a time.

Mailbox Ownership and Target Tenant Design

For a mailbox such as:

Primary SMTP:
******@abc.ae
Aliases:
******@xyz.ae
******@fyp.ae

the first decision should be ownership. In most cases, the mailbox is migrated to the tenant corresponding to the user's primary legal or business entity.

Native Microsoft migration tools move mailboxes as whole objects and do not split mailbox content across multiple destination tenants.

If separate mailboxes are required in XYZ and FYP, they should be provisioned as new mailboxes in those tenants and assigned the appropriate SMTP addresses after ownership has been determined.

Historical content is usually retained with the primary mailbox unless legal, regulatory, or business requirements mandate data segregation. If historical data must be separated, this typically requires eDiscovery exports and/or third-party migration tooling.

Alias Separation

SMTP aliases cannot remain attached to a mailbox located in another tenant once the corresponding domain is moved.

For example:

******@abc.ae -> ABC tenant
******@xyz.ae -> XYZ tenant
******@fyp.ae -> FYP tenant

Each SMTP namespace should be assigned to only one tenant. Exchange Online requires unique ownership of SMTP addresses and does not support the same SMTP address being assigned to multiple mail-enabled objects. In most tenant carve-out projects, unresolved SMTP ownership decisions are one of the most common causes of migration delays.

Enterprise Vault Archives

Enterprise Vault should be treated as a separate workstream. Microsoft does not provide native tooling to migrate Enterprise Vault archives directly into Exchange Online. Typical approaches include PST export, archive rehydration, or the use of specialized archive migration tools, depending on archive size, retention requirements, and the target architecture.

Where possible, mailbox ownership and archive ownership should remain aligned to preserve retention, legal hold, audit, and eDiscovery integrity. If archive data contains content from multiple legal entities, decisions regarding archive splitting should be made jointly by compliance, legal, and business stakeholders.

Employees Working Across Multiple Entities

There are two common approaches:

• Option A: Separate Mailbox per Tenant

ABC Tenant
******@abc.ae
XYZ Tenant
******@xyz.ae
FYP Tenant
******@fyp.ae

This approach provides the cleanest separation between entities, with independent compliance boundaries and full functionality within each tenant. However, it typically results in higher licensing costs, increased administrative overhead, and a more complex user experience for employees who operate across multiple entities.

• Option B: Primary Mailbox + Cross-Tenant Collaboration

The user has one primary mailbox and accesses resources in other tenants through capabilities such as Microsoft Entra B2B Collaboration, Cross-Tenant Synchronization, and Multi-Tenant Organization (MTO).

This model generally provides a simpler experience and lower licensing costs while still enabling collaboration between tenants. Microsoft 365 Multitenant Organization capabilities are designed to improve collaboration across related tenants.

Shared Mailboxes and Resource Mailboxes

Shared mailboxes, room mailboxes, and equipment mailboxes should be assigned to the tenant that owns the business function or physical resource.

Examples:

******@abc.ae -> ABC tenant
******@xyz.ae -> XYZ tenant
Room-Dubai-101 -> Tenant that owns the site

Multi-entity shared mailboxes often require redesign rather than a direct migration. Access to shared mailboxes and resource mailboxes is typically simplest when users have identities within the hosting tenant, as Exchange permissions remain tenant-scoped.

Distribution Lists, Dynamic Groups, and Contacts

Distribution Lists and Dynamic Distribution Groups should be reviewed and redesigned based on the future organization structure. Dynamic Distribution Groups only evaluate recipients within their own directory and do not span multiple Entra tenants.

For cross-tenant membership requirements, organizations commonly leverage Mail Contacts, guest accounts, Microsoft 365 Groups, or Teams shared channels, depending on the desired collaboration experience.

Mail Flow and Third-Party Services

Significant redesign work should be expected around Proofpoint integration, SMTP relay services, mail connectors, transport rules, signature management solutions, and email authentication technologies such as SPF, DKIM, and DMARC.

The current centralized mail flow model generally needs to be redesigned once separate Microsoft 365 tenants are introduced. Mail sent between the new tenants will normally be treated as external email unless additional cross-tenant mail flow and collaboration configurations are implemented.

For more information, you can refer to:

Cross-tenant mailbox migration | Microsoft Learn

Cross-Tenant Migration - FastTrack – Microsoft 365 | Microsoft Learn

Plan for multitenant organizations in Microsoft 365 - Microsoft 365 Enterprise | Microsoft Learn

Set up a multitenant org in Microsoft 365 - Microsoft 365 Enterprise | Microsoft Learn

As an additional consideration, the most successful tenant carve-out projects typically begin with a comprehensive discovery and assessment phase. This should include identifying all mailboxes, SMTP addresses, shared mailboxes, room and equipment mailboxes, distribution groups, archives, permissions, application dependencies, and existing mail flow configurations. The outcome of this exercise is usually an ownership matrix that clearly defines which tenant will own each mailbox, address, archive, group, and resource after the separation.

Once ownership decisions have been finalized, the future identity model can be established and the target Microsoft 365 tenants configured accordingly. Before moving production workloads, many organizations find value in running a pilot that includes representative scenarios such as single-entity users, users who operate across multiple entities, shared mailboxes, resource mailboxes, and Enterprise Vault archives. This helps validate the target architecture, coexistence strategy, access model, and overall user experience before a broader rollout.

It is also worth noting that, in most complex carve-out projects, the mailbox migration itself is often not the most significant challenge. Greater effort is typically required around SMTP namespace ownership, archive retention and eDiscovery requirements, cross-tenant permissions and delegation, calendar and resource access, SMTP relay dependencies, third-party integrations such as Proofpoint and email signature management platforms, and defining the long-term operating model for users who work across multiple entities. Addressing these considerations early in the planning phase can significantly reduce project risk and help ensure a smoother migration experience.

Overall, the most important activity before beginning the migration is establishing authoritative ownership for every mailbox, SMTP address, archive, shared mailbox, resource mailbox, and distribution group. Once those ownership boundaries are clearly defined, the technical migration becomes significantly more manageable, and decisions regarding compliance, collaboration, mail flow, and long-term operational ownership become much easier to implement and support.

I hope this information helpful.