The Complete Exchange to Microsoft 365 Migration Checklist

Exchange migrations do not fail on the hard parts. The mailbox move itself is mature, well-documented technology. They fail on the forgotten parts: the scanner nobody listed, the DNS login nobody has, the 90 GB mailbox that was still syncing on cutover night. A migration checklist exists to make the forgotten parts impossible to forget.

This is the working structure we use on real projects, organized into six phases. It applies whether you are doing a cutover, a hybrid, or a tool-based migration; where a step is method-specific, we say so. If you have not chosen a method yet, read cutover vs staged vs hybrid first, because the method decides several items below.

Phase 1: Discovery and inventory

Everything that goes wrong later is something discovery should have found. Take this phase seriously.

• Record the Exchange version and build, server health, and database sizes. The version constrains your method: cutover works from Exchange 2003 onward for smaller organizations, staged only applies to 2003/2007, hybrid needs 2010 or later and works best on 2013+.
• Export a full mailbox inventory with sizes and last-logon dates. Flag oversized mailboxes (they dominate sync time) and stale ones (do not pay to migrate mail nobody will read).
• Inventory shared mailboxes, resource mailboxes (rooms, equipment), distribution groups, and mail contacts.
• Inventory public folders: total size, folder count, and every mail-enabled public folder. These migrate through a separate batch process; see the public folders guide.
• Hunt down every mail-connected device and application: copiers and scanners (scan-to-email), backup and monitoring alerts, UPS units, door systems, ERP and CRM notifications, website forms, anything relaying through the server. This list is the single most commonly skipped item and the most common source of post-cutover tickets.
• Locate PST files on desktops and file shares, and decide the policy now: import to Microsoft 365, leave in place, or archive.
• Confirm who controls DNS for every mail domain, and that you can actually log in. Check current MX, SPF, and Autodiscover records.
• List retention, journaling, and compliance requirements that must survive the move.

Phase 2: Design and preparation

• Choose the migration method based on version, mailbox count, and downtime tolerance, and write down why, so the decision survives personnel changes.
• Set up the Microsoft 365 tenant: verify domains, assign licenses, configure baseline security (MFA for admins at minimum).
• Plan identity: directory synchronization for hybrid and staged scenarios, or cloud-only accounts for a clean cutover. Decide how passwords will work on day one.
• Build the batch plan (who moves when) and the communications plan (what users are told, and when). Users forgive a planned outage; they do not forgive a surprise.
• Reduce the data before you move it: shrink deleted-items bloat, archive the stale mailboxes you flagged, and get oversized mailboxes under control where possible.
• Lower the TTL on your MX and Autodiscover DNS records ahead of cutover so the eventual switch propagates quickly.
• Prepare the rollback position: what happens if cutover night goes badly, and who makes that call.

Phase 3: Pilot

• Migrate a small pilot group: a few technically tolerant users plus one real-world normal user, with real mailboxes.
• Validate mail flow in both directions, calendar and free/busy behavior, mobile device reconnection, and Outlook profile behavior for your specific method (cutover requires profile recreation; hybrid moves usually reconnect automatically).
• Time the pilot sync and extrapolate honestly. Microsoft 365 throttles migration ingestion, so per-mailbox throughput has a ceiling; the pilot tells you what your real combined bandwidth-plus-throttling rate is, which is the number your cutover date depends on.
• Fix everything the pilot surfaces before scheduling the first production batch. The pilot exists to be embarrassing in private.

Phase 4: Data synchronization

• Start the initial full sync of all mailboxes days or weeks before cutover, oversized mailboxes first. The source server keeps running normally; users notice nothing.
• Monitor sync progress daily and chase per-item errors (corrupt items, oversized attachments) while there is still time to fix them.
• Start the public folder migration batch on its own track, since it finishes on its own schedule.
• Run delta syncs so the cloud copy stays within a small gap of the live server as cutover approaches.

Phase 5: Cutover weekend

The weekend itself should be the least dramatic part of the project, because everything above already happened. The sequence:

1. Final delta sync, and verify every mailbox batch reports complete with zero unresolved errors.
2. Switch MX records to Microsoft 365, update SPF, and add DKIM. Mail now flows to the cloud.
3. Point Autodiscover at Exchange Online so Outlook and mobile clients find the new home.
4. Reconfigure every mail-connected device and application from the Phase 1 inventory with its new SMTP settings.
5. Recreate Outlook profiles where the method requires it, and verify a sample of mobile devices reconnect.
6. Test the unglamorous paths: sending to external addresses, receiving from external addresses, scan-to-email, calendar invites, shared mailbox access.

Phase 6: Post-migration and decommission

• Run heightened support for the first two or three business days; this is when stragglers, forgotten devices, and PST questions surface.
• Complete and verify the public folder migration, including mail routing for mail-enabled folders.
• Execute the PST policy decided in Phase 1.
• Decommission the old Exchange server properly, which is its own careful procedure, not just a power button. In hybrid scenarios, decide whether a management server stays behind.
• Harden the tenant: MFA for all users, anti-phishing and anti-spoofing policies, backup for Microsoft 365 data, license right-sizing.
• Update documentation and the DR plan to reflect the new world, and restore your DNS TTLs.

The gotchas, collected

How long the whole checklist takes depends on size: small cutovers run one to two weeks end to end, mid-size batched projects four to eight weeks, large hybrids several months. We break that down in our timeline guide, and if your priority is that users never notice, read how to migrate without downtime.

You can absolutely run this checklist yourself. The value a migration partner adds is having run it enough times that Phase 1 finds the scanner, the pilot math is honest, and cutover night is boring. If you would rather this be our checklist to own, tell us what you are running.