If you need an email migration checklist, start with this rule: email is not a folder drag-and-drop job. It is a live system with changing message states, aliases, forwarders, throttling, broken clients, and users who keep sending mail while you work. That is why sloppy cutovers fail. If you're still deciding where your mail should live after the move, read business email for small business first. If you already know you have to migrate, use this runbook and keep the move boring.
The problem is simple. Most teams copy mail, flip MX, and hope. Then the missing items show up on Monday: the founder's archive, the invoice forwarder, the shared mailbox that was really five people logging into one account. This email migration checklist fixes that by forcing discovery, pre-stage sync, verification, retries, and rollback into one operating document.
| Approach | Old Way | New Way |
|---|---|---|
| Planning | Copy everything in one weekend | Audit, stage, cut over, verify, and lock down the source |
| Success metric | Mailbox size looks close | Item counts, failed-item logs, and test sends match |
| Failure handling | Retry until someone complains | Defined backoff, owner, and rollback trigger per error |
| Aftercare | Leave old mail live for days | Block zombie access and rebuild broken clients fast |
Email Migration Checklist Before You Copy a Single Message
An email migration checklist starts with visibility. Before you move one byte, you need a programmatic inventory of mailboxes, aliases, forwarding rules, mailbox sizes, and source-side limits. If discovery is weak, every later step gets slower, riskier, and more expensive.
Do not trust HR exports or whatever spreadsheet the client emailed last month. Pull data from the source platform and build an inventory that answers five questions:
- Which mailboxes exist, and which ones still receive mail?
- Which aliases and role accounts map to those mailboxes?
- Which users are storage outliers?
- Which inbox, transport, or mailbox-level forwarding rules are active?
- Which accounts are actually shared operational addresses, not personal mailboxes?
That last point matters more than people admit. invoices@, support@, and hello@ often look like ordinary mailboxes until cutover day. Then nobody knows who owns them, nobody knows which device is still logged in, and replies go missing.
Run a dirty-data pass too. Look for malformed MIME, oversized attachments, and absurd folder trees. IMAP can move a lot, but it won't turn broken source data into clean destination data. Also remember what IMAP does not move well or at all. TrekMail's migration flow is mail-only, so calendars and contacts need a separate plan. TrekMail's IMAP migration overview is clear on that boundary.
Example: a mailbox has 14,200 items in source, but two messages are corrupt and one 80 MB attachment exceeds destination policy. If your runbook says "size looks fine," you miss it. If your runbook says "item counts plus failed-item log review," you catch it before users do.
Email Migration Checklist for Cutover Design
Your email migration checklist should choose the migration architecture before anyone schedules a weekend cutover. Small mailboxes can survive a big-bang move. Real businesses usually cannot. Pre-stage the historical mail, leave recent changes for the final delta, and cut DNS only when the slowest mailboxes are already mostly done.
There are three common patterns:
| Pattern | Best for | Main risk |
|---|---|---|
| Big bang | Tiny teams with light mailboxes | No buffer if throttling or corruption hits on cutover night |
| Pre-stage plus delta | Most SMB and MSP migrations | Needs disciplined logs and a second pass |
| Hybrid | Large Exchange environments | Complexity that most small teams do not need |
For most readers, pre-stage plus delta is the right answer. A practical email migration checklist timeline looks like this:
- T-minus 14 days: migrate old mail first and identify slow mailboxes.
- T-minus 7 days: confirm aliases, forwarding rules, and destination mailbox mapping.
- T-minus 2 days: lower DNS TTL, test authentication, and review failed-item logs.
- T-zero: switch MX, update SPF and DKIM, run delta sync, then remediate clients.
- T-plus 1 day: verify counts, test inbound and outbound mail, then disable old access.
If you mess up DNS, mail flow breaks. Lower TTL at least 48 hours early, then verify the destination records against TrekMail's required DNS records.
example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# DKIM value is generated per domain in the TrekMail dashboard.During the first 24 to 48 hours after MX changes, a temporary p=none DMARC policy can reduce self-inflicted rejection while caches settle. After the move is stable, tighten policy back to enforcement. That advice matters even more if you send significant volume to Gmail. Google's sender guidelines now enforce SPF, DKIM, alignment, TLS, and DMARC for bulk senders.
Email Migration Checklist for Pre-Stage and Delta Sync
The middle of an email migration checklist is about physics, not optimism. IMAP copies messages folder by folder, and large providers impose bandwidth and throttling limits. Your job is to move older mail early, keep retries controlled, and make the final delta pass small enough to finish inside the cutover window.
This is where many migrations blow up. IMAP relies on message identifiers and mailbox state. RFC behavior around UIDs and UIDVALIDITY in RFC 3501 is why reindexed or damaged folders can trigger ugly resync behavior. If your migration tool supports duplicate skipping or content-based matching, use it. TrekMail's dashboard import wizard includes a skip-duplicates option, and the live steps are documented in Starting a Migration in the Dashboard.
For operators who test with command-line tools before touching production, this companion guide on imapsync is worth keeping open.
imapsync \
--host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--syncinternaldates \
--exclude 'Calendar|Contacts' \
--skipsize
Do the bandwidth math before promising a weekend finish. Google publishes Gmail IMAP bandwidth limits, including a 2,500 MB daily IMAP download cap per account. Microsoft is different, but not kinder. Microsoft says migration performance varies and is shaped by service throttling, which is exactly why one giant mailbox can wreck your schedule if you discover it late.
Also keep the destination realistic. TrekMail is IMAP only, not a full office suite. That is a good thing during mail migration because scope stays clean: move the mail, verify the mail, then handle calendars and contacts separately instead of mixing failure domains.
Email Migration Checklist for Verification After DNS Flips
A solid email migration checklist treats verification as a separate phase, not a quick glance at mailbox size. Size lies. Encoding changes, attachment handling differs by platform, and server-side storage math is inconsistent. Item counts, spot checks, test sends, and failed-item review tell you whether mail actually survived the move.
Use a simple verification matrix for every mailbox class: executives, shared accounts, ordinary users, and oversized users.
| Check | What to compare | Pass condition |
|---|---|---|
| Item count | Source folder totals vs destination folder totals | Exact match, or explained deltas in error logs |
| Mail flow | External inbound, external outbound, internal mail | All three succeed and land in the expected mailbox |
| Aliases | Reply and receive tests for every alias | No bounce, correct mailbox delivery |
| Forwarding | Known business-critical forwards | Rules recreated and documented |
| Client access | Outlook, Apple Mail, mobile clients | New profile or re-add works without stale source auth |
This email migration checklist should also include a zombie-mailbox step. After delta sync completes, cut users off from the old platform. Otherwise a stale phone or Outlook profile can still send or receive against the source, and those messages get stranded.
On TrekMail, client settings are straightforward: IMAP host imap.trekmail.net, port 993, and full email address as username. POP3 is not supported. The exact values are in TrekMail's IMAP and SMTP settings guide. If Outlook keeps clinging to the old server, stop patching and build a new profile.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
Email Migration Checklist for Retries, Logs, and Rollback
The last third of an email migration checklist defines what happens when the plan goes red. You need retry rules, log fields, escalation owners, and a rollback threshold before the first mailbox starts. If you invent those under pressure, you will make bad calls.
Your log should capture mailbox, folder, timestamp, source server, destination server, item count attempted, item count copied, bytes copied, retry count, final status, and human-readable error. Then classify failures fast:
| Failure | Meaning | Operator action |
|---|---|---|
| Auth failure | Wrong password, app password missing, or source login blocked | Fix credentials, retest on one mailbox, then resume batch |
| Connection refused | Bad port, SSL mismatch, firewall block, or source host issue | Validate host and port 993, then test manually before retry |
| Throttle or 429-style backoff | Provider is rate limiting requests | Reduce concurrency, wait 5 to 10 minutes, resume slowly |
| Duplicate flood | Folder reindexed or migration state drifted | Stop batch, enable duplicate skipping, re-run only affected folders |
| Missing recent mail | Delta was incomplete or old clients kept writing to source | Run final delta again, then disable source access immediately |
Rollback does not mean "put everything back because one user complained." A serious email migration checklist defines rollback triggers in advance. Good triggers include broad inbound failure after MX change, large unexplained item-count gaps in critical mailboxes, or destination auth failure that blocks the whole tenant. Bad triggers include one stale mobile device or one user who never updated their password.
If rollback is needed, keep it narrow. Restore mail flow first, communicate one status message, and preserve all logs. Do not restart three tools at once and create a bigger mess than the original failure.
Why This Email Migration Checklist Works Better on TrekMail
This email migration checklist gets easier when the destination platform is built for mail, not bundled seat economics. The old way is paying per user for a suite you barely use, then treating migration as a side quest. The new way is moving to a mail-first platform with predictable storage, clear DNS, and an IMAP migration path that matches the job.
TrekMail fits that model well. It supports custom domains, IMAP mailboxes, catch-all, mailbox forwarding, server-side migration, an SPF/DKIM/DMARC wizard, BYO SMTP or included SMTP, and an API. Paid plans start at $3.50 per month on Starter, and the built-in migration tool is available on paid plans. If you want to test paid features, there is a 14-day free trial with a credit card required. If you just want to start without a card, the Nano plan is always free.
The operational win is pooled storage and flat-rate multi-domain management. One oversized mailbox does not force you into a per-seat licensing tax across the whole company. That matters for agencies, MSPs, and anyone running role accounts across many domains. If that is your environment, read TrekMail's take on multi domain email hosting next. For pricing and plan fit, go straight to TrekMail pricing.
This is also cleaner from an execution standpoint. You add the domain, create the destination mailbox, run server-side IMAP migration, validate DNS, and cut clients over. No POP3 detours. No mystery proprietary connector. Just standard IMAP and SMTP with explicit settings.
Conclusion: Keep the Email Migration Checklist Boring
The best email migration checklist is the one nobody remembers a month later. Inventory the source, pre-stage old mail, flip DNS with intent, run the delta, verify with counts, kill zombie access, and keep rollback narrow. If you do that, migration stops being a gamble and turns into ordinary operations, which is exactly what production email should be.
