Workstream 01
Decide whose data and identity are actually moving
Inventory every mailbox in scope, including shared and resource mailboxes, delegates, archives, auto-forwarding, aliases and whether the domain itself will move. Record the source tenant ID and target tenant ID, the owner authorised to approve each move and any users who will remain in the former organisation. The licensing decision is per user, not an assertion that one broad Microsoft 365 licence automatically covers a cross-tenant migration.
Ask legal and records owners about retention holds and eDiscovery before choosing a destructive or non-reversible route. Microsoft's native cross-tenant process removes the migrated source mailbox after a successful move; it is not a second independent archive you can search later. If preservation is required, agree a defensible source-side arrangement before making changes.
| Decision | Evidence before work | Who approves |
|---|---|---|
| User and mailbox set | Source recipient list, delegate and archive inventory | Mail owners |
| Target identity | MailUser attributes, ExchangeGUID, address mapping | Target identity administrator |
| Licensing | Cross-Tenant User Data Migration licence and normal workloads | Commercial/licensing owner |
| Retention | Legal holds, search requirements and preservation method | Records/legal owner |
Workstream 02
Prepare the organisations before building a batch
Exchange administrators need the correct application permissions, an organisation relationship and a source security group defining which mailboxes are eligible to move. Validate the trust configuration and target MailUser objects with a limited non-critical cohort. A poorly mapped recipient can interrupt address resolution or produce a target mailbox that is not the intended recipient.
Include public-facing services in the cutover rehearsal: SMTP delivery, delegate access, Outlook profiles, distribution lists, mobile authentication and sign-in from managed devices. A completed job is not sufficient evidence that a department can work. Keep a separate acceptance sheet signed off by the customer rather than assuming the migration dashboard tells the whole story.
What to capture before the decision
- Record source and target tenant IDs and accountable admins
- Review licence entitlement for every participating account
- Validate target MailUser attributes before assigning conflicting licences
- Pilot mail flow, delegate access and client sign-in
- Agree preservation, rollback options and acceptance owner
Workstream 03
Know what a cross-tenant mailbox move does not include
Moving an Exchange mailbox does not automatically reconfigure every Teams team, SharePoint site, OneDrive library, device registration or third-party integration used by that employee. These workloads often need different tools, permissions and acceptance criteria. Treat the full-company migration as several coupled projects with one cutover plan rather than quoting it from a mailbox count.
Schedule coexistence and communications according to actual users. A phased move might need different domains and routing arrangements for employees who have not yet migrated. Build a clear stop/go checkpoint with IT owners and avoid promising a zero-interruption cutover. Microsoft describes some workloads and scenarios as unsupported; confirm applicability for the actual tenants.
Workstream 04
The target MailUser checklist that prevents a failed move
Native Microsoft cross-tenant mailbox moves rely on properly prepared recipient objects in the destination. Confirm the destination MailUser uses the source ExchangeGUID, the matching ArchiveGUID where applicable, and source LegacyExchangeDN and X500 addresses. Verify the target routing address and primary SMTP assignment. Assigning Exchange Online licensing before the GUID and proxies are prepared can accidentally create a target mailbox; Microsoft's instructions make the order important.
Review source and target organisation relationships, scoped security groups, the migration application permissions and add-on migration licensing. Mailboxes on qualifying holds are blocked by the native feature. Archive, eDiscovery and preservation needs require an authorised compliance decision before any change. One pilot cannot prove eligibility for every employee; maintain an exception list by mailbox.
| Prerequisite | What to verify | Typical failure if missed |
|---|---|---|
| ExchangeGUID and ArchiveGUID | Match source values where required | Target recipient cannot be matched |
| LegacyExchangeDN and X500 | Preserve old reply identity paths | Reply failures and recipient resolution problems |
| Cross-tenant add-on | Required licence assigned to migrating user | Move blocked before or during processing |
| Hold status and preservation | Compliance owner approves permitted method | Native mailbox move blocked |
Workstream 05
Measure what the move actually moved
Cross-tenant Exchange migration transfers user-visible mailbox content; it is not a full tenant clone. Treat Teams chat history, SharePoint sites, OneDrive and application access as separate scopes. If the business needs these workloads, request a separate plan with separate acceptance tests instead of describing everything as an Exchange migration.
Have pilot users test historical mail search, replies to old threads, delegated access, archive expectations, external inbound/outbound mail and required retention access. Document the source mailbox conversion and aftercare responsibilities. A green migration batch without user-visible acceptance is insufficient for sign-off.
What to capture before the decision
- Recipient attributes and add-on licensing checked per user
- Held and compliance-controlled mailboxes listed separately
- Batches scoped and pilot users approved
- Reply routing and X500 history tested
- Other Microsoft 365 workloads excluded or separately planned
A sensible initial engagement is a documented eligibility and recipient audit, not a promised cutover date. The audit should tell the organisation which mailboxes can be moved, what data must be preserved, and what it must still pay for or configure.
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.