Workstream 01
Start with an ownership map, not an export
Identify the legal and technical owner of each tenant, the verified domain names and the organisations that can approve access. For an acquisition, confirm which records can legally be transferred and which must stay with the seller. Record shared service accounts and enterprise applications whose owners may sit outside the acquired business.
For every user, map source UPN, target identity, primary SMTP address, proxy addresses, mailbox type, group membership and critical collaboration spaces. Collisions in naming or domain ownership should be resolved before the cutover window is booked.
| Workload | Migration question | Who signs off? |
|---|---|---|
| Exchange Online | Is the source mailbox eligible and the target MailUser correctly prepared? | Messaging administrator |
| OneDrive | Is owner mapping and post-move sharing understood? | User/data owner |
| SharePoint | Are sites, permissions, external guests and metadata mapped? | Site owners |
| Teams | Which conversations, apps, meetings and linked files are in scope? | Collaboration owner |
| Identity / domains | When may addresses and sign-in identities change? | Tenant/domain owner |
Workstream 02
Check the Exchange blockers explicitly
Microsoft requires cross-tenant migration licensing and correctly configured target MailUser objects. Target ExchangeGUID and proxy-address preparation must be sequenced carefully: assigning an ordinary Exchange licence too early can create an unintended target mailbox. Microsoft also documents that mailboxes on certain holds are blocked from the native cross-tenant move.
Those are not administrative footnotes. A single held executive or legal mailbox can delay a cutover if eligibility was never assessed. Put exceptions into a separate decision list and agree an alternative approach with the organisation’s compliance owner.
What to capture before the decision
- Source and destination tenant IDs, delegated administrators and approval owners
- Cross Tenant User Data Migration entitlement for in-scope users
- MailUser attributes, ExchangeGUID and address mapping
- Hold, archive and eDiscovery considerations
- Coexistence and mail routing between the organisations
Workstream 03
Run coexistence and acceptance as separate workstreams
The source and destination may need to operate together for a defined period. Document how mail finds moved and unmoved users, whether free/busy information works, and who owns internal collaboration links during the transition.
Do not define success solely as completed migration batches. Test user sign-in, mailbox delegation, high-value SharePoint repositories, external guest access, Teams meetings and applications that depend on old identities. Agree whether remediating historic links is included or separately scoped.
Workstream 04
Commercial scope should follow the workload boundaries
Price the identity and domain work, mailbox moves, OneDrive/SharePoint content, Teams and third-party apps separately. Include source-tenant retention planning, user communications, cutover support and a written acceptance process.
For carve-outs, a good proposal must also say what it will deliberately not copy. Doing less may be the legally correct answer, even when a tool can technically move more.
Workstream 05
Identity and domain cutover decisions that cannot be delegated to the migration tool
A domain cannot be verified simultaneously in two unrelated Microsoft 365 tenants. Before moving a shared corporate domain, map which tenant currently uses it for sign-in, mailboxes, aliases, groups, applications and collaboration invites. Plan temporary routing namespaces and the sequence for removing and reassigning domain references. This often requires a coordinated change across identity, Exchange Online, DNS, end-user sign-in and application integrations.
A divestiture brings a second constraint: contractual data ownership may be different from technical access. The seller's retention, eDiscovery and records obligations must be resolved with counsel and compliance before deleting source information or changing holds. Record the authorised target identity, residual source responsibilities and any data that intentionally must not transfer.
| Decision | Evidence to request | Approval |
|---|---|---|
| Domain release | Export of every recipient and application dependency | Both tenant owners and DNS administrator |
| User mapping | Source and target UPN, SMTP and immutable identifiers | Identity lead |
| Retention and legal holds | Purview policies, preservation and discovery requirements | Legal or compliance owner |
| Guest and app access | Named app registrations, guest identities and connected resources | Application and collaboration owners |
Workstream 06
Design a phased move with a documented stop rule
Separate coexistence preparation from the irreversible steps. First validate licensing, permissions, target recipient objects, batch scoping and a pilot that includes a large mailbox, shared mailbox, archive and a user with delegated access. Next establish which calendar, Teams, OneDrive, SharePoint and app behaviours remain outside the Exchange move. Only then book the domain transition and the user communications window.
A go/no-go checklist should include eligible mailbox counts, held-mailbox exceptions, target licensing, mail flow tests, restoration strategy, migration-wave owner and how long the source service must remain supported. If a legal hold blocks a move, treat that as a stop condition requiring a separately approved method, not a setting to work around casually.
What to capture before the decision
- Confirm cross-tenant add-on and target service licensing per migrating user
- Validate matching ExchangeGUID and archive attributes before licensing target
- Verify X500 addresses and forwarding/coexistence routing
- Document separate Teams, SharePoint and OneDrive scope
- Require explicit compliance approval for held mailboxes
The first deliverable worth paying for is a tenant-to-tenant dependency map with a feasible sequence and an exception register.
Source documents and limitations
These references establish current vendor behaviour; they do not verify an individual customer's configuration or imply Microsoft affiliation. Technical claims should be rechecked before execution.