Microsoft 365 tenant-to-tenant migration checklist

By Akash Sengar · 6 October 2026 · 7 min read

Why companies move between tenants

A Microsoft 365 tenant is the container for your users, mailboxes, files, Teams and security settings. Most businesses never think about it until something forces a move. The common triggers are:

• Acquisition or merger: two companies want one directory, one email domain and one place for files.
• Rebrand: a new company name and domain, sometimes with a fresh tenant to leave years of clutter behind.
• Demerger or carve-out: part of the business is sold and must take its users and data with it.
• Leaving a reseller-controlled tenant: the tenant was set up by a previous provider who still holds the admin accounts or billing, and you want a clean tenant you control.

Before you plan a migration, check that you really need one. If the problem is only billing or admin access, it may be fixed by moving the subscription to a new licensing partner and recovering global admin rights, which is far less disruptive than moving every mailbox.

The domain rule that shapes every plan

A custom domain such as example.com can be verified in only one Microsoft 365 tenant at a time. To use it in the target tenant, you must first remove it from the source: every user, group, contact and alias using that domain has to be changed to another address, usually the source tenant's onmicrosoft.com address. Only then can the target tenant verify it.

This is why tenant moves need a cutover window. Between removing the domain from the source and verifying it in the target, mail for that domain cannot be delivered to either tenant as normal. Lower the TTL on your MX and Autodiscover records a few days before, and plan the window for a quiet period such as a weekend.

If both tenants will keep running for a while, an alternative is to move users to the target tenant first under a temporary domain and switch the main domain later. Microsoft's native cross-tenant mailbox migration supports this kind of coexistence: after a move, the source mailbox becomes a mail user that forwards to the target, so internal mail keeps flowing (Microsoft Learn).

Microsoft's native tools: what they move

Microsoft offers built-in cross-tenant migration for Exchange Online mailboxes and OneDrive, and an orchestrator that coordinates moves of users and workloads. According to Microsoft Learn, these need a one-time, per-user Cross-Tenant User Data Migration licence, available as an add-on to Microsoft 365 Business, E and F plans and others, assigned on either the source or target user.

Cross-tenant mailbox migration

• Each migrating user must already exist in the target tenant as a MailUser with specific attributes; the move fails for users not set up correctly (Microsoft Learn).
• Mailboxes on any type of hold are not migrated, so review litigation and retention holds first.
• Only user-visible content moves: email, contacts, calendar, tasks and notes. Microsoft's Exchange team notes that Teams chat data stored in the mailbox is not migrated (Exchange Team Blog).
• After a successful move, the source mailbox content is deleted and cannot be accessed in the source tenant, so take any copies you need for legal reasons before you start.

Preparing target users

Target users must not have mailboxes or OneDrive sites provisioned before migration, and they must not be licensed for Exchange or OneDrive until identity mapping is complete (Microsoft Learn). Assigning licences too early is one of the most common causes of rework.

Native tools or a third-party migration tool?

Many commercial tools also perform tenant-to-tenant moves. Neither route is right in every case. Questions that help you choose:

• Which workloads must move: only mail and OneDrive, or also SharePoint sites, Teams channels and chats, Planner and shared mailboxes?
• Do you need a long coexistence period with calendar free/busy across both tenants?
• Are you comfortable with PowerShell and Exchange administration, which the native route relies on?
• What does each option leave behind, and how will you handle it?

Whichever you choose, run a pilot with a handful of real users before the main move.

Identities, licences and devices

1. Export the source directory: users, shared mailboxes, groups, distribution lists, aliases and licence assignments.
2. Decide naming for the target: same user principal names after cutover, or new ones.
3. Buy licences in the target tenant before cutover, and plan when to cancel the source subscriptions.
4. Plan devices. Windows PCs joined to the source Entra ID and enrolled in its Intune will not follow the user automatically; they usually need to be reset or re-joined to the target.
5. Re-register multi-factor authentication for every user in the target tenant.

Teams and SharePoint

Teams and SharePoint are where moves get complicated. List every team and site, decide which ones are still needed, and agree an owner for each. Channel files live in SharePoint, so they move with site content, but chat history, meeting recordings, apps and permissions need separate decisions. Archiving rarely used teams instead of migrating them saves time.

Tell users plainly what will and will not appear in the new tenant. Lost chat history causes more complaints than anything else in a tenant move.

A realistic timeline

For a small or mid-sized business, a tenant move is usually planned in four stages. The length of each depends on user numbers, data volume and how much coexistence you need, so treat this as a sequence rather than a schedule.

1. Discovery: inventory users, mailboxes, sites, teams, devices, apps using single sign-on and every system sending mail as your domain. Agree what will not move.
2. Preparation: build the target tenant, buy licences, apply the security baseline, create target users as mail users, set up the migration tooling and test it on a few test accounts.
3. Pilot: move a small group of real users from different teams, including at least one heavy calendar user and one shared mailbox owner. Fix what they find.
4. Main move and cutover: migrate the remaining batches, run final passes, switch the domain and support users closely for the first week.

Communicate at each stage. Users need to know when their mailbox moves, what changes on their phone and laptop, and who to call. A short page with screenshots of the first sign-in saves many help desk calls.

Common mistakes to avoid

• Licensing target users before identity mapping, which creates empty mailboxes and blocks the move.
• Forgetting mailboxes on hold until the migration batch fails.
• Removing the domain from the source without first changing every alias, group and contact that uses it; the removal will not complete until they are cleared.
• Leaving scanners, printers, websites and line-of-business apps sending through the old tenant's mail settings.
• Deleting the source tenant before legal retention and audit needs are confirmed.
• Skipping the DKIM setup in the target, which hurts deliverability on day one.

Cutover and rollback

1. Freeze changes to users and groups a few days before.
2. Run the final mailbox and OneDrive passes.
3. Remove the domain from the source, verify it in the target, and update MX, Autodiscover, SPF and DKIM.
4. Switch users to their final addresses and test sign-in, mail flow and file access with the pilot group first.
5. Keep the source tenant and its data intact until the post-move checks pass.

Your rollback plan is the reverse DNS change and a list of who switches back. Write it down before cutover, with the decision point and the person who makes the call.

Post-move checks

• Mail flow in and out, including from your website forms, scanners and line-of-business apps.
• SPF, DKIM and DMARC pass for the domain from the new tenant. Our free email security check shows this in seconds.
• Shared mailboxes, calendars and delegate access work.
• Conditional Access, MFA and the security baseline are applied in the target. See our Microsoft 365 security baseline.
• Old admin accounts in the source tenant are removed once it is no longer needed.