Email Migration Checklist: Pre-Flight to Post-Cutover (2026)

Email Migration Checklist: Everything to Verify Before and After Cutover

If you treat email migration as a copy-and-paste operation, you'll face silent data loss, broken reply chains, and a support queue full of "User Unknown" bounces. A proper email migration checklist built for operators eliminates those surprises.

This email migration checklist is for the person who can't afford downtime. It skips the theory and focuses on the architectural requirements of a zero-loss cutover. For the complete methodology, see the full email setup guide.

Pre-Flight: The Forensic Inventory

You can't migrate what you don't see. The most common failure mode is shadow IT—objects that exist in the directory but not in your user list. The first section of any email migration checklist must address this blind spot.

1. Infrastructure and Identity Map

• Map all object types: Don't just count users. Inventory distribution lists, shared mailboxes, and public folders.
• Capture proxy addresses: Ensure every proxyAddress on the source is mapped to the destination.
• Exchange migration critical: Map the LegacyExchangeDN (X.500) to the new system as an x500: proxy. Failing to do this causes internal replies to bounce with IMCEAEX non-delivery reports.

Audit Hidden Forwarding

Server-side forwarding rules don't migrate via IMAP. Expose them before you start:

2. The Whale Hunt

• Flag mailboxes over 20 GB. Most providers throttle IMAP ingestion. A 50 GB mailbox won't migrate in a single weekend—you must pre-stage these users weeks in advance. The Google Workspace migration documentation details these limits.
• Folder depth check: Exchange Online hard-limits folder depth to 300 levels. Deep hierarchies get silently truncated if you don't flatten them first.

3. DNS Preparation (The 300-Second Rule)

• Lower TTLs for MX, SPF, and DMARC records to 300 seconds—48 hours before cutover.
• Set DMARC to p=none. Enforcing p=reject during a migration guarantees legitimate mail fails alignment and gets blocked.

For a full DNS cutover procedure, see how to set up email on your domain.

The Sync Phase: Moving Data Without Triggering Throttles

The goal is to move 90% of data while users are still working, without tripping provider rate limits. This phase of the email migration checklist is where most operators underestimate complexity.

Pre-Stage Strategy

1. Sync old mail first: Configure your tool (or imapsync) to migrate items older than 30 days
2. Remember the IMAP reality: As defined in RFC 3501 (IMAP), the protocol moves email only. Calendars, contacts, tasks, and rules stay behind. Export calendars to .ics and contacts to .csv for local archiving.

Throttling Reference

Error Handling

• HTTP 429/503: Back-off signals. Your tool must implement exponential backoff (wait 5s, then 10s, then 20s).
• Corrupt items: Set a tolerance threshold (e.g., 50 items). Stopping a 10 GB migration for one corrupted 2 KB header is operational failure.

The Cutover: Routing and Final Delta

Execute during a planned maintenance window. Speed matters here. This is the most time-sensitive section of the email migration checklist.

The Freeze

Disable user access to the old system or enforce a strict stop-work order. Then run the final delta sync to catch mail received during the pre-stage window.

UIDVALIDITY warning: If the source server re-indexed folders, the tool may attempt to re-download duplicates. Always run a dry run first.

DNS Switch

1. Update MX records to the new provider. With a 300s TTL, propagation takes minutes.
2. Update SPF: Add the new provider's include (e.g., include:spf.trekmail.net). Watch the RFC 7208 limit of 10 DNS lookups—flatten records if needed.
3. Publish DKIM: New selector keys go live immediately.

Post-Cutover Verification: The Email Migration Checklist

"It looks fine" is not a validation strategy. Here's what to actually check.

The Golden Metric: Item Counts

Ignore total size—compression varies between providers. A 10 GB mailbox on Gmail may show as 8 GB on the destination. Compare item counts per folder instead.

Client Remediation

• New profiles: Don't patch old Outlook profiles. Create fresh ones for a clean .ost file.
• Kill zombie connections: Block ports 993/443 on the old server. Otherwise, mobile devices reconnect to the old server and create a split-brain experience.

Troubleshooting Quick Reference

TrekMail Handles the Hard Parts of This Email Migration Checklist

The manual checklist above requires PowerShell scripts, DNS propagation monitoring, and throttling management. TrekMail treats migration as infrastructure, not a consulting project.

For Small Businesses

TrekMail includes a native IMAP migration engine. Enter your old credentials (Gmail, cPanel, Exchange), and the system handles sync, folder mapping, and retries automatically. No scripts, no command line.

Learn about business email hosting built for teams that don't want to manage infrastructure.

For Agencies

Instead of juggling 50 storage quotas, TrekMail offers pooled storage across all client domains. Managed SMTP handles delivery reputation so you skip the IP warm-up entirely.

All paid plans come with a 14-day free trial (card required). The Nano plan needs no card.

Conclusion

An email migration checklist isn't about being thorough for the sake of it. Each item on this list maps to a specific failure mode that has burned real operators. Inventory your shadow objects, pre-stage the whales, drop your TTLs, run the delta sync, and verify with item counts—not gut feeling.

Ready to check off every item on this email migration checklist? Start your free TrekMail account and let the built-in migration engine handle the infrastructure.