A tenant-to-tenant migration moves users, mail, files and devices from one Microsoft 365 tenant to another. It usually follows a merger or a consolidation. I delivered one that brought two Entra ID and Microsoft 365 tenants together: over 1,000 mailboxes, SharePoint Online, OneDrive and over 500 Intune devices. We kept the existing domain names, so users did not have to re-register their devices.
These are the stages I would plan again, in the order I would plan them.
Start with discovery
Build an inventory before you design anything. You need users, groups and licences, mailboxes (size, shared, resource and archive), distribution lists, SharePoint sites, OneDrive usage, Intune policies, apps and devices, Conditional Access policies, applications that use single sign-on, third-party tools that connect through Microsoft Graph, mail flow connectors and the DNS records for every domain.
The inventory shows what has to move, what can stay behind and what nobody has touched for years.
Decide what moves and what is rebuilt
Policies and Conditional Access are usually rebuilt in the target tenant, not copied, because the target has its own standards. Data moves with migration tooling. Settle the identity question early: whether users keep their existing identities or receive new ones, and when each user changes sign-in name.
Domains need special care. A domain name can belong to only one tenant at a time, so moving a domain is a planned cutover step. Done carelessly, it causes a mail outage. Write down the exact order of removing the domain from the source tenant and verifying it in the target, and test the mail flow immediately after.
Prepare the target first
Before any user moves, build the target: licences, groups, Conditional Access, Intune enrolment settings and Autopilot profiles, SharePoint structure, and mail-enabled objects. Moving users into an unprepared tenant turns every missing setting into a support call.
Run a pilot
Choose a pilot group that includes IT staff, one typical user from each department and a few awkward cases: a shared mailbox, a very large mailbox, someone with a managed phone. Take the pilot through the complete cutover steps, including a rollback test. Anything that surprises you in the pilot is cheap. The same surprise in the main wave is not.
Write the cutover runbook
The runbook lists each step with a time, an owner, a check and the expected result. It includes a go or no-go point before anything that cannot easily be undone. For mail and files, copy the bulk of the data ahead of cutover and finish with a short final pass, so the cutover window stays small.
Tell users what to expect before, during and after. Give them one place to ask for help on day one.
Plan the rollback
Decide where the point of no easy return sits. In most migrations it is the domain move. Before that point, rollback should be simple and rehearsed. Keep the source tenant intact until validation is finished.
Validate and support
Check each user against the same list: sign-in, multi-factor authentication, mail send and receive, calendar, OneDrive files, SharePoint access and device compliance. Use a sample for hands-on checks and reports for everyone else. Staff the help route for the first few days after each wave.
The technical steps matter, but most of the risk sits in the plan and the communication. A short, announced delay is easy for people to accept. A surprise on the morning of a working day is not.