Free technical decision aid · no tenant access required

Cross-tenant migration: what evidence is still missing?

A tenant merger can look straightforward until a held mailbox, incorrectly prepared target MailUser or domain conflict blocks the move. Use this matrix to assign evidence before approving an Exchange Online batch. This is a planning record, not an eligibility test or change-authorisation tool.

Discuss a scoped migration

Ten checks before the migration window

Select a status for each item. The summary runs entirely in your browser; it does not upload, persist or validate your answers. "Evidence recorded" means you have checked it, not that this website has verified it.

Workstream and evidence	Risk if missed	Your status
01. Confirm the migration method Owner: Both IT owners Written source/target tenant IDs; decide which workloads are Exchange mailbox moves and which require separate projects.	A mailbox move does not migrate Teams conversations, SharePoint sites or identity configurations.	Evidence status
02. Identify mailboxes subject to holds Owner: Compliance owner Per-mailbox hold/retention decision, reviewed by the legal or records owner.	Microsoft says mailboxes under any hold are blocked from cross-tenant mailbox migration.	Evidence status
03. Check destination and add-on licensing Owner: Licensing owner Eligible Exchange subscription and per-user Cross Tenant User Data Migration licence verified against current requirements.	Without the required add-on, the migration fails; licensing before proper MailUser preparation can also create the wrong object.	Evidence status
04. Map the target MailUser Owner: Target Exchange administrator Matching ExchangeGUID; ArchiveGUID when relevant; source LegacyExchangeDN/X500 values and correct routing addresses.	A missing or mismatched GUID or old address can block a move or later mail reply.	Evidence status
05. Scope permitted users Owner: Source administrator Source mail-enabled security group and organisation relationship for the intended migration cohort.	A loose or wrong migration scope risks unexpected moves.	Evidence status
06. Prove tenant trust and permissions Owner: Both tenant administrators Application, migration endpoint, cross-tenant organisation relationship and approved administrative access.	An assumed connection is not proof that tenant authorisation and endpoint configuration work.	Evidence status
07. Inventory domains, aliases and mail routing Owner: Messaging owner Source/target SMTP domains, accepted domains, coexistence routes, connectors, third-party senders, SPF/DKIM/DMARC.	A domain belongs to one tenant at a time. Source proxies must not be copied blindly into the target.	Evidence status
08. Separate Teams, OneDrive and SharePoint Owner: Collaboration owner Independent transfer decisions for sites, permissions, sharing links, meetings and cloud files.	Teams meeting URLs may require recreation after migration; mail-only acceptance is insufficient.	Evidence status
09. Agree representative pilot and acceptance Owner: User representative Named test users, signed criteria for login, Outlook profiles, inbound/outbound mail, shared resources and access.	An API reporting success does not establish business continuity.	Evidence status
10. Approve cutover and recovery Owner: Business sponsor Cutover owner, change window, exception register, go/no-go criteria, escalation plan and retained evidence.	Some moves are not reversible by clicking undo; avoid promising zero downtime.	Evidence status

Working summary

10 items not reviewed. No item is confirmed by this tool.

Three distinctions that commonly change the quote

Mailbox move versus collaboration move

The native cross-tenant Exchange path concerns mailbox content; SharePoint, OneDrive, Teams, identity objects and domain changes require separate evaluation. Do not treat one completed batch as whole-estate acceptance.

Target object before licence

Microsoft's guidance requires matching identifiers on the target MailUser and warns about provisioning a destination mailbox before the correct ExchangeGUID has been established. Validate the specific current method first.

Retention is not optional

Holds can block native cross-tenant mailbox moves. Retention and discovery requirements belong to the client's legal/records owner; the delivery plan must account for them before any change.

What to give the engineer

Send a sanitised inventory showing counts, workload types, accountable owners, blocked categories and the intended migration window. Do not email GUID exports, administrator passwords, tokens, customer datasets or identifiable employee records through the public enquiry route.

Download an acceptance-test template or estimate transfer effort with your own assumptions.

Official references

Editorial candidate, checked against Microsoft documentation on 9 November 2026. Independent technical review still required before indexing.