Microsoft 365 migration: a checklist with no surprises

Two kinds of migration

This checklist covers two common scenarios: from on-premises Exchange to Exchange Online, and from one Microsoft 365 tenant to another, for example after an acquisition or merger. The phases are largely the same. The biggest difference lies in identity and domains: in a tenant-to-tenant migration a domain can only be verified in one tenant at a time. You therefore have to remove it from the source tenant before you add it to the target tenant, and that forces a hard switchover moment.

Phase 1: Inventory

• User mailboxes, with size, item count and archive mailboxes.
• Shared mailboxes, room and equipment mailboxes, with their permissions (Full Access, Send As, Send on Behalf).
• Distribution groups, mail-enabled security groups and Microsoft 365 groups.
• Forwarding rules, transport rules, connectors and devices or applications that send mail via SMTP.
• Public folders, if there are any. They need their own migration path.
• OneDrive and SharePoint data, including size, sharing links and external sharing.
• Teams: teams, channels, owners, apps and guest users. Chat history is hard to move in a tenant-to-tenant migration; agree up front what will and will not move.
• Retention policies, litigation holds and eDiscovery requirements.

In Exchange Online this gives a quick overview per recipient type:

Get-EXOMailbox -ResultSize Unlimited | Group-Object RecipientTypeDetails | Select-Object Name, Count

Phase 2: Identity and licences

• Choose how identities get into Entra ID: synchronisation from Active Directory with Microsoft Entra Connect Sync or Entra Cloud Sync, or cloud-only accounts.
• Make sure UPNs use a routable, verified domain and preferably match the primary email address.
• Understand how matching works. A soft match links a synced object to an existing cloud account based on the primary SMTP address or the UPN; a hard match uses the source anchor (ImmutableId). Test this beforehand with a few accounts.
• Decide which licences are needed and assign them in good time, preferably through group-based licensing. In a hybrid scenario, take care that assigning a licence does not accidentally create a second, empty cloud mailbox alongside the on-premises mailbox.
• For tenant-to-tenant: decide whether users get new accounts in the target tenant, how passwords and MFA are handled and what happens to the old accounts.

Phase 3: Choose a migration method

• Cutover migration: all mailboxes moved from on-prem to Exchange Online in one go. Suitable for smaller environments without synchronisation and without the need for a longer coexistence period.
• Staged migration: in batches. Microsoft only supports this for very old Exchange versions, so in practice it is rarely relevant any more.
• Hybrid migration: on-prem Exchange and Exchange Online temporarily work together, with shared free/busy information and moves in batches. The best choice for larger environments or if you use directory synchronisation. It requires a supported, patched Exchange environment; Exchange 2016 and 2019 have been out of support since October 2025, so plan this carefully.
• Tenant-to-tenant: Microsoft offers cross-tenant mailbox and OneDrive migration, which requires an additional per-user licence. There are also various third-party migration tools that move Teams and SharePoint as well. Compare them on what they actually migrate, how they handle permissions and how delta synchronisation works.

Phase 4: Prepare DNS

• Lower the TTL of the MX, autodiscover and SPF records well in advance.
• Prepare the new MX record; copy the exact value from the admin centre, as it differs per domain.
• Check the autodiscover record (CNAME to autodiscover.outlook.com) and remove outdated SRV or A records that send Outlook the wrong way.
• Update SPF. Make sure all legitimate senders are included and that you stay under the limit of ten DNS lookups.
• Enable DKIM in the new environment using the CNAME records the portal shows.
• If you don’t have DMARC yet, start with p=none and reporting, so you can see who sends mail on behalf of your domain. Only tighten it after the migration.

Phase 5: Pilot

Choose a pilot group of five to ten people with different roles: someone with a shared mailbox, someone who shares a lot of calendars, someone who mainly works on mobile and, preferably, a critical colleague. Let them work for at least a week and record every problem.

Phase 6: Communication

• Announce the migration two to three weeks in advance, with the date, what users will notice and what they need to do themselves.
• Send a short guide for Outlook, mobile and Teams.
• Tell them where to go with questions on the first working day, and make sure someone is physically present or directly reachable that morning.

Phase 7: The cutover weekend

1. Freeze changes: no new mailboxes, groups or permissions in the source.
2. Run the last incremental synchronisation.
3. Change MX and autodiscover (for tenant-to-tenant: remove the domain from the source and add it to the target tenant).
4. Use an external tool to check that the new DNS records are visible, and test inbound and outbound mail.
5. Run a final delta sync for mail that still arrived in the source.
6. Test with the pilot users: Outlook, webmail, mobile, shared mailboxes and Teams.

Phase 8: Rollback plan

Decide beforehand what the decision point for a rollback is and who makes that call. With a cutover, rolling back usually means restoring the DNS records and putting the source mailboxes back into use; mail that has meanwhile arrived in the new environment then has to be brought back. With hybrid you can move mailboxes back to on-prem. With tenant-to-tenant, rolling back after the domain move is the hardest, so test most thoroughly there beforehand.

Phase 9: Aftercare and checks

• Outlook: for tenant-to-tenant, preferably create a new profile. Check that the cache has been rebuilt and that shared mailboxes appear automatically.
• Mobile devices: in many cases the account has to be added again in Outlook Mobile or the built-in mail app.
• Shared calendars and delegate access: test that permissions came across correctly.
• Permissions on shared mailboxes, Send As and Send on Behalf.
• Forwarding rules, signatures, room bookings and scan-to-email.
• Mail flow: check message trace for rejections and spam classification during the first days.

Phase 10: Decommissioning

• Keep the source environment available read-only for an agreed period.
• Check that retention obligations and backups are covered before you delete any data.
• For hybrid: decide whether you need to keep an Exchange server for recipient management or can move to the management tools without a running server, following Microsoft’s current guidance.
• Cancel licences in the source tenant, disable old accounts and clean up outdated DNS records, connectors and relay settings.