The Email Migration Checklist Every Admin Should Run Through

A migration goes wrong in one of two ways: you missed something obvious in planning, or you discovered something at 2am during cutover that you should have found two weeks earlier. This checklist exists to push those discoveries to the left, into discovery and pilot, where they cost hours instead of weekends. Work through it sequentially. If a phase has open items, do not start the next one.

How to use this checklist#

Each phase below ends in a go/no-go gate. Do not skip ahead. The checklist assumes you are moving between IMAP-capable providers (Gmail, Microsoft 365, Yahoo, iCloud, Fastmail, hosted Exchange, custom IMAP). Tenant-to-tenant Exchange and PST-source migrations have additional steps covered in the complete email migration guide.

Print it. Tick the boxes. The point of a checklist is that you do not trust your memory at 2am.

Phase 1: Discovery#

Discovery is where you find out what you actually have. Most projects underrun discovery and overrun cutover for this reason.

1. Inventory every mailbox

   Export a full list from the source provider's admin panel. Include user mailboxes, shared mailboxes, distribution lists, resource calendars (rooms, equipment), and aliases. Distribution lists and resource calendars are the two categories most often forgotten.

2. Capture mailbox sizes

   Get the size in GB for each mailbox. Anything over 25GB will need special handling: longer pilot window, dedicated batch slot, possibly an archive split. Mailboxes over 50GB may exceed source-side per-message or per-folder limits.

3. Map folder counts and depth

   Folders, not just mailbox size, predict migration time. A 5GB mailbox with 800 folders takes longer than a 20GB mailbox with 40 folders because IMAP traversal is per-folder. Note any mailboxes with more than 500 folders.

4. Identify shared mailbox permissions

   Export who has access to what. Permissions do not migrate automatically; you will reapply them on the destination. Missing this step is a leading cause of post-cutover tickets.

5. Check DNS and MX state

   Document current MX records, SPF, DKIM, DMARC. Note TTLs. Long TTLs (24+ hours) need to be lowered ahead of cutover or your switch will hang for users on slow-refreshing resolvers.

6. Find the integrations

   Who is sending mail on behalf of the domain? Marketing platforms, ticketing systems, monitoring alerts, CI/CD notifications. Each one is a separate authentication update at cutover. Ask Finance about anything that mails invoices.

Discovery gate. You should now know: total mailbox count, total data volume, the 10 largest mailboxes, every shared mailbox and resource, current DNS state, and every system sending mail from the domain. If any of these are unknowns, do not move on.

For a deeper discovery process, the pre-migration assessment covers the same territory with more detail.

Phase 2: Planning#

Now that you know what you have, decide how you will move it.

• Pick the migration approach: cutover, staged, or hybrid. Cutover vs staged vs hybrid covers when each makes sense.
• Lock the cutover date. Coordinate with anyone who runs end-of-month or end-of-quarter processes. Avoid Mondays (no buffer if cutover slips) and Fridays (weekend pager).
• Choose your tool. Confirm it handles your specific source-destination pair, your authentication method (OAuth, app password, basic), and your mailbox sizes.
• Define batches. Group mailboxes by team, time zone, or risk profile. Plan 50–150 mailboxes per batch for staged migrations.
• Build the communication plan. Three pre-cutover emails minimum: 4 weeks out, 1 week out, day before. The project plan post covers a full comms template.
• Identify the pilot group. 5–15 users, mixed roles, including at least one heavy user and one shared-mailbox user.
• Define success criteria. "Migration complete" means what, exactly? Folder count match, message count match within tolerance, calendar items count, shared mailbox access verified.
• Set a rollback plan. If cutover fails, what is the path back? Who authorises it? Have the rollback DNS records ready in advance.
• Reduce DNS TTLs at least 48 hours before cutover. Drop MX, SPF, DKIM TTLs to 300 seconds.

Planning gate. You have a written plan, a cutover date, a batch list, a tool selection, a pilot group identified, and a rollback path. The plan is reviewed by someone other than its author.

Phase 3: Pilot#

The pilot is a real migration in miniature. Treat it that way.

• Migrate the pilot group fully. Do not just test the connection; move the data.
• Have pilot users verify their own mailboxes for 48 hours. Calendar invites, send-from-shared, mobile sync, signature, search.
• Measure throughput. How long did the pilot take, by mailbox size? Use this to predict production timing.
• Collect every error from the tool's log. Categorise: auth, throttle, malformed message, folder name encoding, attachment size.
• Verify shared mailboxes specifically. Pilot one shared mailbox even if no pilot user owns one personally.
• Test the rollback path on one pilot mailbox. Switch them back to source, confirm mail flows.

Pilot gate. Pilot users sign off in writing that their mailboxes are usable. Every pilot error is either fixed in tooling or documented as a known issue for production. Throughput measurements feed into the production schedule.

Phase 4: Production migration#

Production is the bulk move. With a good pilot behind you it is mechanical.

1. Pre-stage data

   Begin copying data from source to destination several days before cutover. The first pass moves everything; subsequent delta passes catch new and changed items. Pre-staging is the difference between a 4-hour cutover and a 4-day cutover.

2. Run delta syncs

   Daily delta syncs leading up to cutover. The last one runs hours before MX switch and catches the final tail. Monitor for batches that fall behind.

3. Reapply shared mailbox permissions

   Do this during pre-stage, not cutover. Permissions take time to propagate, especially on Microsoft 365 (often 15–60 minutes per change).

4. Pre-create distribution lists and groups

   On the destination side, in advance. Cutover should not include "and then create 80 groups".

5. Stage Outlook profile changes

   For Microsoft destinations, prepare new Outlook profiles ahead of time. The SkyKick-style profile remediation tools, or scripted Autodiscover, save significant cutover time.

Phase 5: Cutover#

Cutover is the moment of switch. Plan it for a low-traffic window: Friday evening or Saturday morning for most western markets, ideally not overlapping a release or month-end.

• T-2 hours: confirm pre-stage and delta status. Stop if any batch is materially behind.
• T-1 hour: run the final delta sync. Stop sending from the source side.
• T-0: update MX records to point at the destination. Update SPF to include the destination's send infrastructure. Republish DKIM if the selector is changing.
• T+15 minutes: verify MX has propagated for at least two external resolvers (1.1.1.1 and 8.8.8.8 are easy).
• T+30 minutes: send a test message from an external account. Confirm it arrives at the destination.
• T+1 hour: run a final delta to catch anything that arrived during the switch window.
• T+2 hours: enable user access on the destination. Send the "you are live" communication.
• T+24 hours: monitor closely. Most cutover failures show up within the first day.

Phase 6: Validation#

Validation is where you confirm the migration actually worked. Skipping this is the most common project failure mode.

• Compare folder count per mailbox. Source and destination should match within tolerance (some tools merge or rename folders predictably).
• Compare message count per folder for a sample of 10% of mailboxes. Allow ±0.5% tolerance for spam and duplicate handling.
• Pull a random message from 20 mailboxes and confirm it opens fully with attachments.
• Verify every shared mailbox is accessible by its expected users.
• Verify every distribution list and resource calendar.
• Confirm mobile devices sync correctly. Spot-check three OS versions if you can.
• Verify the SPF/DKIM/DMARC alignment on outbound mail. Send a test to a check-auth service and confirm pass.
• Confirm every external integration is sending and receiving correctly.

The post-migration validation guide has scripts and queries for automating most of this.

Validation gate. Folder and message counts match. Shared mailboxes accessible. Outbound mail authenticates. External integrations functional. You can now communicate "migration complete" with confidence.

Phase 7: Closeout#

Often skipped, always worth doing.

• Write a post-mortem. What surprised you? What would you change on the next project? Future-you will thank present-you.
• Update the runbook. If you discovered a new auth quirk, throttling number, or workaround, log it.
• Decommission source mailboxes per the retention policy. Set a 2-week minimum delay.
• Decommission tool licences if billed per-project.
• Send the final invoice if billing externally.
• Schedule a 30-day check-in with the customer or business owner. Trailing issues surface around the one-month mark.

A printable summary#

If you remember only one thing from this checklist, remember this: the order matters. Discovery before planning, planning before pilot, pilot before production, production before cutover, cutover before validation, validation before closeout. Every project that skips a phase ends up doing it eventually — usually under worse conditions. The checklist is cheaper than the rework.

FAQ#