Microsoft 365 Cross-Tenant Migration Planning Guide

A Microsoft 365 cross-tenant migration moves users and supported data from one independent Microsoft 365 tenant to another. These projects commonly follow mergers, acquisitions, divestitures, tenant consolidation, or organizational restructuring, and they require planning beyond mailbox copying because identities, domains, mail flow, coexistence, workload dependencies, and target readiness may all affect the cutover. This guide focuses on those cross-tenant planning decisions and shows where EdbMails fits in the mailbox-migration workflow. For the complete EdbMails click-by-click procedure, use the tenant-to-tenant migration step-by-step guide.

For commercial evaluation of the migration software, see the Office 365 tenant-to-tenant migration tool.

Why organizations perform cross-tenant migrations

Cross-tenant projects commonly arise during mergers and acquisitions, divestitures, tenant consolidation, internal restructuring, or rebranding. Some projects move most users in one coordinated cutover, while larger or more complex environments may use multiple migration waves. If users must retain the same custom domain, treat the domain handoff as a separate cutover workstream and use the dedicated same-domain guidance linked below.

Why cross-tenant migration is more complex

A cross-tenant migration crosses an organizational boundary between two separate Microsoft 365 tenants. The project therefore involves more than mailbox data transfer. Administrators may need to coordinate source and target identities, target-recipient readiness, UPN or SMTP changes, domain ownership, mail flow, coexistence, workload dependencies, mapping, migration waves, and cutover sequencing.

• Identity and target readiness: Source users and target users are separate identities. Plan how UPNs, SMTP addresses and target recipients will correspond before production migration.
• Domains and mail flow: Decide whether users will use a different target domain or retain the same custom domain, and plan DNS/mail-flow changes only where the scenario requires them.
• Coexistence: In a phased migration, some users may be active in the target while others remain in the source, creating routing, calendar/free-busy, address-book, collaboration and application-access considerations.
• Workload dependencies: Exchange mailbox migration is only one workstream. SharePoint, OneDrive, Teams, Groups, identity and device work may require separate products or Microsoft configuration.
• Migration waves and cutover: Pilot users, wave sequencing, incremental passes and validation reduce the risk of discovering identity, mapping or mail-flow issues during the final cutover.

For broader migration issues such as throttling and network performance, see Office 365 Migration Challenges and Solutions.

Discover source and target dependencies before migration

• Mailbox inventory: Record user, shared and archive mailboxes, public folders, mailbox sizes, aliases, permissions and relevant retention/hold requirements.
• Workload inventory: Identify Exchange, OneDrive, SharePoint, Teams, Groups and any collaboration data that must move through separate workflows.
• Identity inventory: Document source and target UPNs, SMTP addresses, target recipients, guest/member objects where relevant, authentication and application dependencies.
• Domain and mail-flow inventory: Document custom domains, accepted domains, MX/Autodiscover dependencies, and whether the same custom domain must transfer.
• Business dependencies: Identify departments, VIPs, critical calendars or applications, support coverage and communication requirements.

Identifying a dependency does not mean the EdbMails mailbox migration workflow migrates or configures that dependency automatically.

Identity and target-user readiness

Keep Microsoft-native cross-tenant requirements separate from the EdbMails workflow. Microsoft's native cross-tenant mailbox migration can require specially prepared target MailUser objects and native configuration. Microsoft-native requirements may differ from EdbMails prerequisites, so use the current EdbMails documentation when preparing the source and target tenants.

For an EdbMails project, prepare the target recipients according to the selected workflow, confirm the target licensing needed for final user and mailbox access, document source-to-target UPN/SMTP changes, and verify how each mailbox will map to its intended target. EdbMails mailbox migration should not be described as Microsoft Entra ID identity migration.

Plan cross-tenant coexistence for phased migrations

In a phased cross-tenant migration, migrated users may be active in the target tenant while other users remain in the source tenant. Plan the coexistence period separately from mailbox data transfer. Depending on the project, administrators may need to address mail routing, calendar/free-busy visibility, address-book experience, Teams or cross-tenant collaboration, application access, and user communications. These coexistence functions may require separate Microsoft configuration or specialist coexistence solutions and are not configured automatically as part of the EdbMails mailbox migration workflow.

Big-bang or phased cross-tenant migration?

Pilot and migration-wave planning

• Run a representative pilot before production waves; include different mailbox sizes and relevant mailbox types.
• Group waves by business dependency, department, geography, mailbox size or support requirements rather than random order.
• Avoid splitting tightly coupled users or applications in ways that create unnecessary cross-tenant dependencies.
• Review migration reports, target-user access and coexistence behavior after each wave before expanding scope.

These planning practices are recommendations for reducing migration risk and are not mandatory steps required by the EdbMails software.

Separate mailbox, collaboration, identity and device workstreams

High-level EdbMails cross-tenant mailbox migration workflow

1. Assess the source and target tenants and define mailbox scope.
2. Prepare target recipients, licensing and the domain approach.
3. Connect the source tenant in EdbMails using the current supported authentication method.
4. Select the source mailboxes and supported mailbox data in scope.
5. Connect the target Microsoft 365 tenant.
6. Map source mailboxes to the intended target recipients.
7. Run a representative pilot or first migration wave.
8. Review migration reports and resolve failed or skipped items.
9. Run supported repeat or incremental passes before final cutover.
10. Validate target mailboxes and complete the scenario-specific cutover.

For screenshots, connection settings, UI labels and the complete procedure, use the tenant-to-tenant migration step-by-step guide.

Plan source-to-target mailbox mapping

Cross-tenant mapping should be planned before production migration. Confirm how each source mailbox corresponds to a target recipient, especially when UPNs, SMTP addresses, or domains change. Use the EdbMails-supported automatic, manual, or CSV-based mapping methods only as verified by current product documentation, and review unmatched users before starting a migration wave. Mailbox mapping does not replace identity migration, domain transfer, or coexistence planning.

Use incremental or repeat migration before cutover

Cross-tenant projects are often completed in more than one pass. After an initial or pre-stage migration, source mailboxes may continue receiving or changing data until cutover. Use the verified EdbMails incremental/repeat migration process for supported new or changed mailbox items before the final cutover, and review the migration report after each run. Do not describe this as universal synchronization, guaranteed zero duplication, or guaranteed zero data loss across every workload.

Domain, mail-flow and cutover planning

At planning time, identify whether users will use a different target domain or retain the same custom domain, document UPN and SMTP changes, and coordinate mail-flow or DNS changes only where the scenario requires them. If the same custom domain must move, use the dedicated Office 365 migration with the same domain guide rather than duplicating the domain-release and DNS/MX sequence here.

• Define the final migration wave and final incremental/repeat pass.
• Confirm target sign-in and mailbox readiness before irreversible changes.
• Coordinate domain, DNS and mail-flow changes only where required.
• Communicate the cutover window and expected user actions.
• Use a go/no-go checkpoint for unresolved identity, mapping, domain or mail-flow blockers.
• Keep source access available until technical and business validation is complete.

Validate the cross-tenant migration before source retirement

• Technical: Review migration reports, failed/skipped/warning items, representative mailbox/folder/item checks and mail flow.
• Identity and access: Confirm target sign-in, target addresses, authentication and relevant application access.
• User: Validate Outlook/client access, calendars, mobile access and Teams only where separately migrated.
• Business: Obtain representative user or department-owner sign-off before source decommissioning.

Cross-tenant migration risks and contingency checks

• Identity mismatch: Validate the source-to-target identity list before production waves.
• Incorrect mapping: Review automatic, CSV or manual mappings and unmatched recipients.
• Unsupported workload: Keep mailbox, collaboration, identity and device workstreams separate.
• Same-domain dependency: Use the specialist same-domain plan and go/no-go checks.
• Coexistence gap: Plan routing, free/busy and collaboration separately where the project requires them.
• Licensing or target-readiness gap: Confirm target services and licensing before each wave.
• Throttling or large-mailbox delay: Pilot, batch and monitor reports instead of relying on fixed speed or concurrency promises.
• Incomplete validation: Keep the source available until technical, user and business validation is complete.

Microsoft 365 cross-tenant migration FAQs

---

Additional Resources:

• Office 365 tenant-to-tenant migration tool
• Tenant-to-tenant migration step-by-step guide
• Office 365 migration with the same domain
• Office 365 to Office 365 migration
• Office 365 migration guide