Email Migration Checklist for a Clean IMAP Cutover

If you need an email migration checklist, you probably already know the risk. Mail migrations don’t usually fail in the copy job. They fail in the edges: hidden aliases, stale DNS, cached Outlook profiles, Gmail label weirdness, and one VIP mailbox that takes three days longer than the plan said it would.

That’s the problem. The bigger problem is that most guides stay too high-level to be useful when you’re doing the actual cutover. If you’re moving a small team, cleaning up old hosting, or trying to stop overpaying for business email, start with the basics in business email for small business, then come back here for the operator checklist.

This guide gives you a working email migration checklist you can use before, during, and after cutover. It’s built for founders, IT admins, agencies, and MSPs moving to IMAP-based hosting like TrekMail, which supports multi-domain email, pooled storage, and built-in server-side IMAP migration.

What an email migration checklist actually covers

An email migration checklist is a cutover control list for mailboxes, DNS, identity, and client access. It exists to prevent bounced mail, missing folders, broken mobile apps, and silent data gaps that only show up after users start working again.

A good email migration checklist is not just “export, import, switch MX.” It needs to cover every object that can receive mail, every dependency that can block delivery, and every user-side action that turns a finished migration into a support fire.

1. Inventory everything that can receive mail

Your first email migration checklist item is inventory. If your source list only includes licensed human users, it’s incomplete. Shared mailboxes, aliases, catch-all routes, forwarding rules, scanners, finance inboxes, and old distribution lists can all keep receiving live mail after cutover.

This is where migrations get ugly. Someone exports “active users,” creates destination mailboxes, flips DNS, and assumes the job is done. Then leads sent to sales@ bounce, invoices sent to ap@ disappear, and the office printer starts throwing SMTP errors.

Use this inventory list before you touch data:

1. Licensed user mailboxes
2. Shared mailboxes and role accounts like info@, billing@, and support@
3. Aliases mapped to users or shared inboxes
4. Distribution lists and group addresses
5. Forwarding rules, catch-all behavior, and routing exceptions
6. Devices and apps that send mail through the old provider
7. Legacy Exchange objects, including X.500 or LegacyExchangeDN references

If you’re deciding whether an address should stay an alias or become a real mailbox, this matters more than people think. Use domain email alias vs mailbox before the move, not after mail starts bouncing.

Operator rule: if an address ever received money, leads, tickets, or login resets, treat it as production until you prove otherwise.

TrekMail’s model helps here because you’re not paying a per-user tax for every utility inbox. Paid plans start at $3.50/month, storage is pooled, and you can migrate into real IMAP mailboxes instead of faking critical inboxes with forwarding hacks.

2. Check what IMAP migration will and won’t move

An IMAP-based email migration checklist should assume mail data moves, but not everything else. Messages and folders usually come across. Calendars, contacts, rules, signatures, permissions, and some proprietary metadata usually do not.

This is where expectations break. IMAP moves email. It does not recreate your whole collaboration stack. If the source system is Google Workspace or Exchange, users may assume calendars, shared permissions, categories, and autocomplete history will survive. They usually won’t.

Before the project starts, write down what is in scope:

TrekMail’s import tool is for IMAP email import. That’s exactly what it should be used for. Verify the workflow in IMAP migration overview and starting an import in the dashboard before you promise users a “full environment migration.”

3. Pre-stage large mailboxes or your schedule is fake

A realistic email migration checklist has to account for throttling. Your local internet speed is not the real limit. The source provider, destination provider, and IMAP session limits decide how fast the migration can actually move.

This is the physics part. You can have a fast office connection and still watch a 50 GB mailbox crawl because the source system starts slowing requests, rate limiting connections, or suspending heavy IMAP activity. Google has published Gmail bandwidth and API quota limits, and Microsoft environments do their own throttling too.

So don’t plan a weekend “big bang” move for every mailbox. Split the migration into phases:

1. Pre-stage older mail two to three weeks early.
2. Leave recent mail on the source while users keep working.
3. Run a delta sync during the final cutover window.
4. Validate counts before changing MX.

This one step turns a risky migration into a manageable one. It also cuts down support noise because users see most of their history already present when they log in on day one.

If you’re moving from Gmail, remember the label problem. One message with multiple labels can look like multiple folder copies to a dumb IMAP workflow. That inflates mailbox size fast and creates duplicates. A practical email migration checklist should explicitly review Gmail label mapping and exclude junk structures like giant archive buckets when appropriate.

If you prefer tool-first workflows, compare your options with imapsync. If you want built-in migration inside the hosting panel, TrekMail’s server-side import avoids pushing the whole job through one admin laptop.

4. Lower DNS TTL before cutover, not during cutover

A cutover email migration checklist must include DNS timing. Lowering TTL after you switch MX does almost nothing. You need to reduce TTL at least 24 to 48 hours before the change so outside resolvers stop caching the old answer for a full day.

This is the classic split-brain failure. Half the internet sees the new MX. The other half keeps delivering to the old server. The migration looks “done” in your panel while users quietly lose inbound mail on the legacy host.

Use this timing:

Required TrekMail DNS records are documented in required DNS records. If you’re merging providers during the cutover window, your SPF record might temporarily need both senders. SPF itself is defined in RFC 7208, and DMARC behavior is defined in RFC 7489.

example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:_spf.google.com include:spf.trekmail.net -all"

That temporary SPF merge is one of the most useful items in any email migration checklist. Remove the old include later, not five minutes after MX flips.

5. Validate by item count, not mailbox size

A proper email migration checklist validates message count first. Mailbox size is noisy because providers count storage differently, attachments use encoding overhead, and Gmail labels can multiply what looks like the same message across folders.

This is where admins panic for no reason. The source says 10.2 GB. The destination says 9.8 GB. That does not automatically mean data loss. MIME encoding, storage engines, and duplicate suppression can all change reported size.

Your validation order should look like this:

1. Check total item count.
2. Check key folders like Inbox, Sent, Drafts, and Archive.
3. Spot-check date ranges and attachment-heavy threads.
4. Only then compare reported size as a rough signal.

If item count matches and spot checks pass, the migration is usually fine. If item count is off, stop and investigate before you declare success.

Also test real mail flow. Send from outside the domain, from inside the domain, and from the most annoying device in the company. Outlook, iPhone Mail, and old scanners find problems that dashboards miss.

6. Plan for client re-auth and profile rebuilds

An email migration checklist is incomplete if it ends at server status. Users still need to sign in again on phones, desktops, tablets, and old mail apps. In many cases, the fastest fix is not repair. It’s delete and re-add.

This is the support tsunami phase. The mailbox is fine. DNS is fine. But Outlook is still trying the last known config, or a phone is holding an old token from Google or Microsoft and refuses to talk to the new IMAP host.

Write the day-one instruction like this: delete the old account, add the new one, and use the exact IMAP and SMTP settings. TrekMail publishes those settings in IMAP and SMTP settings for all clients. Standard values are:

IMAP host: imap.trekmail.net
IMAP port: 993
SMTP host: smtp.trekmail.net
SMTP port: 465
Username: full email address
Password: mailbox password

One more thing: TrekMail is IMAP only. No POP3. That’s the right call in 2026. Shared state matters more than ancient download-and-delete behavior.

If you manage lots of domains or client tenants, this support step gets harder fast. That’s where operational structure matters more than the migration tool itself. For that side of the work, multi domain email hosting is the bigger planning problem.

7. Decide whether all old mail needs to move

The smartest email migration checklist sometimes says “don’t migrate everything.” If users barely touch a decade of old mail, exporting an archive and starting fresh can cut risk, shorten cutover, and reduce the blast radius dramatically.

This is the part people skip because it feels politically hard. But hauling 15 years of receipts, newsletters, and dead project threads through a live migration is expensive in time and failure risk. If the archive is rarely used, move it out of the critical path.

Old Way vs New Way is simple here:

Old Way: keep paying per-user pricing forever because one mailbox has 40 GB of history nobody opens.

New Way: archive what isn’t operational, migrate what users actually need, and use pooled storage so one heavy mailbox doesn’t force a license upgrade for the whole team.

That’s one reason TrekMail makes sense for operators cleaning up mailbox sprawl. You can start free, paid plans start at $3.50/month, and there’s a 14-day free trial on paid plans with a credit card required. The Nano plan doesn’t need a card and stays free.

Email migration checklist: final runbook

This final email migration checklist is the short version you can paste into a change ticket. It covers the minimum controls that prevent the most common failure modes in a real-world IMAP cutover.

1. Inventory every mailbox, alias, shared inbox, group, route, and sending app.
2. Confirm what IMAP will move and what needs a separate export.
3. Pre-stage older mail before cutover.
4. Lower MX TTL 24 to 48 hours early.
5. Prepare temporary SPF overlap if both old and new systems will send during transition.
6. Run final delta sync before switching MX.
7. Validate by item count, folder checks, and live send/receive tests.
8. Rebuild client profiles where needed. Don’t waste hours “repairing” broken cached configs.
9. Archive dead history instead of migrating junk by default.
10. Keep rollback access to the old system until validation is finished.

That’s the whole point of an email migration checklist. Not elegance. Not theory. Fewer surprises.

If you want an easier destination for IMAP-based moves, compare plans at TrekMail pricing. You get custom domains, IMAP mailboxes, catch-all support, BYO SMTP or managed SMTP, mailbox forwarding, and a built-in migration tool without per-user pricing pressure.