Email Migration Steps: Day-by-Day Timeline for Zero Downtime

Email Migration Steps: The Day-by-Day Timeline That Avoids Downtime

These email migration steps are not a file copy. They manage a state transition between two live databases while users actively modify data on both ends. If you desynchronize the data layer (IMAP) from the routing layer (DNS), you create split-brain routing—half your organization gets mail on the old server, the other half on the new one.

This runbook gives you the exact email migration steps, day by day, from T-minus 7 through T-plus 1. No theory, just the execution sequence. For the architectural deep dive, see the full email setup guide.

The Three Layers You're Managing

Every set of email migration steps involves three layers. Failure in any one causes downtime.

1. Data Layer: The historic emails (IMAP)
2. Routing Layer: The DNS records (MX) that dictate where new mail lands
3. Identity Layer: The client configuration (Outlook, mobile apps) used to access mail

T-7 Days: Discovery and Hygiene

You can't migrate what you don't know exists. A user list is not an inventory. These first email migration steps are about building a complete picture.

Inventory Everything

• Map all object types: Mailboxes, aliases, distribution lists, public folders
• Identify the whales: Scan for mailboxes over 20 GB. Google limits IMAP downloads to roughly 2,500 MB/day. A 50 GB mailbox takes weeks, not hours. The Google Workspace data migration guide documents these throttling limits in detail.
• Clean dark data: Ex-employees don't need active mailboxes. Export them to local archives.

If migrating from Exchange, use PowerShell to get the real item count (size in GB is unreliable due to compression):

T-2 Days: The Pre-Stage Sync

Don't wait until Friday night. Move 90% of historical data while users are still working. These email migration steps reduce cutover risk dramatically.

Start the Sync

Configure your migration tool (or imapsync) to migrate email older than 30 days. Monitor for HTTP 429 (Too Many Requests) or Google 11001 errors.

Throttling Limits to Know

Gmail warning: Do not migrate the "All Mail" folder. It contains duplicates of every message in every label. Map labels to folders but exclude Gmail/All Mail.

T-1 Day: The TTL Drop (The 300-Second Rule)

DNS records typically cache for 24 hours (TTL 86,400). Among all email migration steps, the TTL drop is the one most often skipped—and most often regretted. If you switch MX records without lowering the TTL first, the internet routes mail to the old server for a full day after you switch.

1. Log into your DNS provider (Cloudflare, Route53, etc.)
2. Locate your MX records
3. Change the TTL to 300 seconds (5 minutes)
4. Do not delete the old records yet—just update the TTL

Verify with dig:

T-0 (Friday Evening): The Cutover

Users have stopped working. Execute the switch. These are the most critical email migration steps.

Step 1: The Freeze

Tell users to stop sending mail. If possible, lock accounts on the source to prevent orphan emails.

Step 2: Delta Sync

Run the migration tool again. This pass grabs the last 30 days plus any new items. Since the bulk data is already moved, this should take minutes.

Watch for UIDVALIDITY issues: If the source server re-indexed folders, the tool may re-download duplicates. Always run a dry run first. The IMAP RFC 3501 explains UIDVALIDITY semantics in detail.

Step 3: Switch MX Records

Update your MX records to the new provider. TrekMail users:

With a 300-second TTL, traffic shifts in about 5 minutes.

Step 4: Update SPF and DKIM

Update your SPF record immediately to authorize the new IPs. For details on setting up email authentication on your domain, see our dedicated guide.

T+1 (Monday Morning): Verification

The final email migration steps focus on validation. Don't assume success—verify it.

Item Count Verification

Compare source item counts to destination. Under 1% variance is acceptable (usually corrupt MIME items). Over 5% means something went wrong systemically—folder depth limits or filter misconfiguration.

Client Reconfiguration

Users must remove the old account and add the new one in their mail clients.

Calendars and Contacts

TrekMail is professional email hosting for businesses. We don't host server-side calendars (CalDAV) or contacts (CardDAV). Users should export calendars (.ics) and contacts (.vcf) from the old provider and import them locally into Outlook, Thunderbird, or Apple Mail.

Go/No-Go Verification Gates

The Rollback Plan

If the new system rejects mail or critical data is missing:

1. Revert MX: Point MX records back to the old provider (takes 5 minutes with 300s TTL)
2. Export the gap: Any mail delivered to the new provider during the window must be exported (EML/MBOX) and imported to the old server
3. Diagnose: Check for 550 5.7.1 (Relay Access Denied) or firewall blocks before retrying

TrekMail Automates These Email Migration Steps

Manual migration is high-risk labor. TrekMail automates the infrastructure layer so you can focus on clients.

For Small Businesses

Stop paying for features you don't use. TrekMail's built-in migration tool handles the IMAP handshake, retries, and throttling logic. Enter credentials; we move the mail.

For Agencies and MSPs

Bulk provisioning for 100+ domains. Pooled storage across all clients instead of per-user limits. Managed SMTP with no IP warm-up required.

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

Conclusion

These email migration steps follow a strict timeline for a reason: each phase depends on the one before it. Skip the TTL drop and you get 24 hours of split-brain routing. Skip the pre-stage and your Friday night cutover turns into a Saturday morning disaster.

Follow the timeline, verify with item counts, and keep a rollback plan ready. That's the whole formula.

Ready to start? Create your free TrekMail account and use the built-in migration engine to handle the heavy lifting.