QG Professional Services
- Microsoft & Cloud
Tenant-to-tenant migration is the project where Microsoft 365 experience is earned. A merger or acquisition closes, two organisations must become one, and everything lives in two tenants: identities, mailboxes, files, Teams, devices, applications. Executives assume it is an IT formality; anyone who has run one knows it is the most intricate project in the Modern Workplace portfolio, with legal holds, licensing, DNS and human behaviour all conspiring against the timeline.
This is the checklist we run, organised by phase. It follows Microsoft's native cross-tenant tooling, which means data moves within the Microsoft cloud rather than through third-party infrastructure. That toolset has widened: cross-tenant user data migration covers mailboxes and OneDrive, and cross-tenant SharePoint site migration now moves site content between tenants, leaving a redirect at the original location so existing links keep working. Two caveats belong in your plan from the start: Teams channel structure and Teams content are not covered by the SharePoint site migration (a Teams-connected site migrates its SharePoint content only, and cross-product Teams migration is handled through the Microsoft 365 Orchestrator tooling), and the cross-tenant shared data migration capability has its own licensing and agreement prerequisites. Confirm both against current Microsoft documentation before committing to a scope.
Phase 1: Discovery (know both tenants before promising anything)
- Inventory both environments completely: users, mailboxes (sizes, archives, shared and resource mailboxes), OneDrive volumes, SharePoint sites, Teams (including private channels, a recurring complication), Power Platform assets, Intune-managed devices, and every third-party integration touching either tenant.
- Map identities. Duplicate people, contractors in both tenants, naming-convention collisions, and the target UPN scheme. The cross-tenant identity mapping is the document everything else depends on.
- Find the legal holds and retention policies early. Mailboxes under litigation hold need explicit handling decisions with legal counsel before any migration plan is real. Discovering holds mid-migration is a project-stopping event.
- Audit licensing in the target. Migrated users need licences on arrival day: procurement lead times belong on the critical path, not discovered during cutover week.
- Register the domain question. The source domain cannot exist in two tenants simultaneously; domain cutover is its own choreographed sub-project with a hard DNS sequence.
Phase 2: Design (the decisions that shape everything)
- Coexistence period design: cross-tenant synchronisation for the GAL, Teams external access settings, calendar free/busy sharing. How long will the organisations work side-by-side, and with what experience?
- Migration architecture: establish the cross-tenant organisation relationships, mailbox migration endpoints, OneDrive cross-tenant configuration and — where in scope — the SharePoint site migration configuration. Then decide the Teams approach separately, because it is the piece the native site migration does not carry. Apply realistic content triage throughout: migrating ten years of abandoned sites is a choice, not a default, and a merger is the one moment when deleting them is politically possible.
- Wave planning. Pilot group first, then production waves grouped to keep collaborating teams together: splitting a department across waves creates weeks of degraded collaboration between them.
- Device strategy. Intune-managed devices need re-enrolment to the target tenant; decide between reset-based and migration-tooling approaches and test both against your estate's reality.
Phase 3: Prepare and pilot
- Configure org relationships, run test migrations of representative mailboxes and OneDrives, and validate mail flow, permissions behaviour, and what breaks (delegates, shared-mailbox access and calendar permissions frequently need re-establishment; script it, don't discover it per-ticket).
- Pilot with a real, mixed user group: not just IT. IT users tolerate friction and know workarounds; pilots composed only of IT report false success.
- Prepare the communication plan. Users need to know what changes, what they must do (device sign-in, mobile re-enrolment, MFA re-registration), and where help lives. Under-communication is the top complaint in every post-migration review.
Phase 4: Migrate (the cutover discipline)
- Run production waves with a defined validation gate per wave: mail flow, OneDrive access, Teams functionality, line-of-business app sign-ins, confirmed by sampled users before the next wave proceeds.
- Domain cutover, where in scope, follows its documented runbook (removal from source, verification in target, UPN updates, DNS propagation) in a maintenance window with rollback criteria decided in advance.
- Hypercare, staffed properly, for at least the first week per wave. Ticket volume triples; pre-drafted fixes for the predictable issues (mobile profiles, cached credentials, delegate access) keep it survivable.
Phase 5: Decommission and operate
The forgotten phase. Source-tenant retention obligations satisfied and documented, licences reclaimed, the source tenant wound down deliberately, and governance re-established in the merged tenant; Conditional Access and security baselines re-validated for the doubled user population, because two merged security postures equal neither original.
Practical steps
If a merger is on your horizon, start the discovery inventory now: it is weeks of work, it commits you to nothing, and it converts every later conversation from guesswork to plan. And be sceptical of anyone quoting a timeline before seeing both tenants' inventories. Tenant migration is QG's flagship Modern Workplace engagement: assessment, identity mapping, pilot, waved cutover and hypercare, delivered on Microsoft's native cross-tenant framework so your data never leaves the Microsoft cloud.