IMAP migration is the part of an email move where things break fast. Mail disappears. Sent folders split. Users get half their history on the new host and half on the old one. If you treat IMAP migration like a simple copy job, you create duplicates, miss live mail during cutover, and burn hours proving you did not lose the CEO's inbox.
This guide explains how IMAP migration actually works, what it copies, what it drops, where projects fail, and how to run a clean staged cutover. It is written for operators moving one domain or one thousand. If you need the mechanics of the underlying tool, read our imapsync operator guide after this. If you are rethinking your whole hosting model at the same time, this multi domain email hosting guide covers the control side.
What Is IMAP Migration?
IMAP migration is the process of connecting to a source mailbox over IMAP, reading messages and folders, and writing them into a destination mailbox. It moves email content, not your whole collaboration stack. That distinction matters because most migration surprises come from assuming IMAP knows more than it does.
At a protocol level, IMAP migration is mailbox-to-mailbox replication using an email access standard defined in RFC 3501. A migration tool logs in to the old server, reads message bodies, headers, folders, and flags, then logs in to the new server and appends that data into the destination mailbox. That sounds clean. In practice, every host implements edge cases differently, folder names vary, and live users keep changing the source mailbox while the job is running.
That is why a safe IMAP migration is never one pass. It is a staged sync with a cutover window, DNS prep, and verification. The protocol was built for mail access, not for perfect database replication. Good operators work with that reality instead of pretending it does not exist.
If your move also includes creating a new mail system from scratch, this business email guide is the broader setup playbook. If you are moving to TrekMail, the live product docs for IMAP migration overview and migrating from Gmail cover the dashboard workflow.
What IMAP Migration Copies and What It Does Not
IMAP migration copies mailbox content and some mailbox state. It does not copy everything users think of as “email.” Messages, folders, and common flags usually move. Contacts, calendars, client signatures, and server-side filtering rules usually do not.
That gap is the first thing to explain before you touch production. Users hear “mail migration” and assume their entire working environment is moving with it. It is not. IMAP migration is email only. If the source system stores contacts in CardDAV, calendars in CalDAV, or rules in a proprietary admin layer, those are outside the IMAP lane.
| Object | Usually Transfers? | Reality in Production |
|---|---|---|
| Email messages | Yes | Bodies, headers, and attachments usually move. Corrupt MIME can still fail on import. |
| Folder structure | Yes | Hierarchy usually moves, but delimiter and special-use folder names may need mapping. |
| Read or unread state | Usually | The Seen flag normally survives, which is critical for user trust. |
| Answered or flagged status | Usually | Standard IMAP flags often migrate correctly, but do not assume every client-specific flag will. |
| Contacts | No | IMAP migration does not know about address books. |
| Calendars | No | Calendar data needs a separate export or migration path. |
| Rules and filters | No | Server-side automation usually has to be rebuilt manually. |
| Signatures | No | These live in Outlook, webmail, mobile apps, or user profiles, not in IMAP. |
This is also why “successful IMAP migration” has to be defined correctly. Success is not just “the job finished.” Success means users can log in on Monday, see historical mail where they expect it, send new mail, and not discover a missing Sent history three hours later.
When you are moving from older cPanel-style hosting, missing system folder mapping is a regular problem. TrekMail’s cPanel migration guide is worth checking before cutover because those environments often name core folders in ways modern destinations do not.
How IMAP Migration Works Under the Hood
IMAP migration works by reading mail from one server and appending it to another while tracking message state between passes. The hard part is not copying data. The hard part is preserving enough identity and timing so later syncs only copy what changed instead of replaying the whole mailbox.
A migration tool acts as a dual-headed client. On the source side, it lists folders, enumerates messages, and fetches content. On the destination side, it creates missing folders and appends messages into them. During that process it tries to preserve flags such as Seen, Answered, and Flagged. Better tools also maintain a local record of what has already been copied so repeated runs do not duplicate the mailbox.
The state problem starts with UIDs and folder identity. Each IMAP folder exposes message UIDs, and the mailbox exposes a UIDVALIDITY value used to tell clients whether the UID set still belongs to the same logical folder. If that value changes during an active IMAP migration, the tool may decide the folder is effectively new and re-copy content it already imported. That is how one routine server repair becomes a storage explosion.
Real-world example: the source host gets reindexed on Saturday during the pre-stage sync. UIDVALIDITY changes. Your next delta run sees thousands of items as “new” and imports them again. Now the destination mailbox is twice the size and the user thinks you duplicated their whole archive because, in effect, you did.
There are other protocol quirks. Gmail exposes labels through IMAP in ways that can make one message appear in multiple places. Some hosts use dot-delimited folder trees, others use slash-delimited trees. Some servers reject malformed messages the source tolerated for years. IMAP migration is simple only when you talk about it from fifty thousand feet.
One more point that gets missed: IMAP migration is additive by design in many tools. That protects you from accidental destructive sync, but it also means deletions on the source may not remove items from the destination. Plan around that. Do not discover it in front of the client.
The Safe IMAP Migration Process
A safe IMAP migration uses three passes: an initial sync, one or more delta syncs, and a final delta after the MX cutover. This staged model keeps users working on the old system while most data moves quietly in the background.
The best operators do not wait for one giant migration weekend. They pre-stage early, reduce risk before cutover, and leave the smallest possible data gap for the final sync. That is how you keep Monday boring.
1. Prep the destination before you copy a byte
Create the destination mailboxes, validate storage headroom, and confirm the receiving platform is ready for real users. On TrekMail, that means the domain is active, DNS is clean, and the target mailbox exists before you start importing. If you are still setting up the new environment, use the docs for required DNS records first, then the migration workflow.
Set expectations with users early. Tell them what IMAP migration includes, what it does not, and what the blackout rules are. If they plan to delete twenty gigabytes of junk mail, they need to do it before the initial sync, not halfway through.
2. Run the initial IMAP migration pass
This is the heavy lift. The goal is to move most of the data while users stay on the old host. For small mailboxes, that may be a full pass. For larger estates, you may choose a date filter or simply accept that the first pass will run for a long time.
The initial IMAP migration is where you discover connection limits, bad credentials, broken folders, and giant legacy mailboxes. Good. That is exactly when you want to discover them. Not during final cutover.
3. Run delta syncs while users are still live
Delta runs catch what arrived after the first pass. This is where an IMAP migration stops being a copy project and becomes a synchronization project. The tool compares source and destination state and imports only what appears to be missing.
Do more than one delta if the migration window is long. A mailbox that changes every minute should not wait until cutover day for its second look.
4. Lower DNS TTL before cutover
Drop TTL roughly 24 hours before the move so MX changes propagate fast. Five minutes, or 300 seconds, is the standard move. If you skip this, your final IMAP migration pass has to clean up a much larger split-delivery mess.
If you mess up DNS records, mail will land in the wrong place. There is no soft failure here. Double-check it.
5. Switch MX and run the final IMAP migration pass
Once the new MX is live, some traffic will still trickle into the old host during propagation. That is normal. Wait for mail flow to shift, then run one last IMAP migration delta against the old source. This final sweep catches the stragglers that landed in the wrong place during DNS convergence.
| Phase | What you do | User impact | Main risk if skipped |
|---|---|---|---|
| Initial sync | Move the bulk of historical mail | None | Huge cutover window |
| Delta sync | Catch new items since the first pass | None | Large data gap at cutover |
| TTL reduction | Lower DNS TTL before MX switch | None | Long split-routing window |
| MX cutover | Point new mail at the destination | Brief login or routing coordination | Mail keeps landing on the old host |
| Final delta | Import straggler messages after cutover | None to low | Missing recent mail |
If you are moving to TrekMail specifically, this is also the right time to think about your longer-term operating model. The old way is per-user billing, scattered domains, and margins that get worse every time the client adds another mailbox. The TrekMail way is plan-based pricing, pooled storage, multi-domain control, and an IMAP migration path built into the platform. Starter begins at $3.50 per month, paid plans offer a 14-day free trial with a credit card, and the Nano plan stays free with no trial required. Pricing is on TrekMail pricing.
The Failure Modes That Wreck IMAP Migration
The most common IMAP migration failures are folder mapping mistakes, Gmail duplication traps, server throttling, malformed messages, and false confidence from green status screens. Most of them are predictable. That is the maddening part. They are not rare edge cases. They are the job.
The Sent folder trap
Source systems often store sent mail in folders like Sent Messages, Sent Mail, or just Sent. Destinations may expect Sent Items or a special-use folder flag. If you do not map that correctly, the user opens the new account and sees an empty Sent folder. Panic follows.
The test is simple. After migration, send one new message from the destination. If that fresh message is in a different folder than the imported sent history, your IMAP migration is not done.
Gmail label duplication
Gmail is the classic IMAP migration trap because Gmail is not really a folder-first system. The same message can appear under Inbox, a custom label, and All Mail. Through IMAP, that can look like multiple copies available for download. If you migrate everything blindly, storage doubles and users get confused.
Gmail also has account-level IMAP settings that can affect what is exposed, including a folder size cap in some environments, according to Google’s IMAP settings documentation. Use the Gmail-specific path, not a generic checkbox binge. Google’s IMAP docs also note that Gmail IMAP sessions are limited to about 24 hours, which matters on long-running jobs.
Throttling and connection ceilings
Bandwidth is not the same thing as throughput. Your fiber line can be fine while the source or destination starts saying no. Microsoft documents several throttling layers for migrations in Exchange Online, including migration-service throttling and resource-health throttling. That means your IMAP migration can slow down or stall even when your own network looks clean.
Do not fight throttling with blind concurrency. That just gets you blocked faster. Use a tool that backs off and reruns cleanly. If the server wants you to slow down, slow down.
Hierarchy delimiter mismatch
One host uses dots. Another uses slashes. If your tool does not translate delimiters and special folders properly, the destination tree arrives malformed. Users may find one giant flat mess or duplicated top-level folders. It is ugly, but more important, it breaks years of mail organization.
Malformed source messages
Old servers often store junk they should not. Broken headers. Invalid MIME. Weird charset handling from 2009. A modern destination may reject those messages even when the old host displayed them without complaint. That does not mean the whole IMAP migration failed. It means you need exception handling and a count-based review.
How to Verify an IMAP Migration
You verify an IMAP migration by checking message counts, sampling important folders, testing Sent behavior, and rerunning targeted deltas where gaps exist. Storage size is a bad metric. Progress bars are worse. Count items and inspect the folders users actually care about.
This is the part junior teams skip because they are tired and the tool says Complete. Do not do that. “Completed” often means “the process ended.” It does not mean “the result is correct.”
- Compare item counts on source and destination for Inbox, Sent, Drafts, Archive, and a few large custom folders.
- Accept small variance only when you can explain it, such as corrupt messages or known exclusions.
- Log in as the user and confirm historical sent mail and newly sent mail land in the same Sent folder.
- Search for a few known messages by subject and sender across multiple years.
- Run a targeted rerun on the missing folder instead of nuking the mailbox and starting over.
Item count is the gold metric because it stays stable across encoding overhead and storage back-end differences. A ten-megabyte attachment can occupy different disk size on different systems. One message is still one message.
Sampling matters too. If the CEO only lives in Inbox and Sent, do not waste all your validation time on a dusty Projects/2017 folder while forgetting the folders that will trigger a support ticket in the first five minutes.
A good rerun strategy saves projects. If one folder is off, rerun that folder. Do not delete the whole destination unless you are absolutely sure the migration logic itself is wrong. Most of the time, the fix is narrower than the fear.
Tool Selection and Operator Tradeoffs
The best IMAP migration tool depends on whether you value low cost, high control, or easy reporting. There is no perfect tool. There is only the right tradeoff for the job in front of you.
| Option | Best for | Strength | Weak spot |
|---|---|---|---|
| imapsync | Sysadmins, MSPs, custom jobs | Maximum control and scriptability | You can hurt yourself fast with bad flags |
| SaaS migration platforms | Corporate projects, reporting-heavy teams | GUI, batch visibility, delegation features | Per-user cost eats margin |
| TrekMail built-in migration | Moves into TrekMail | Server-side workflow inside the platform, paid-plan feature, lower operator overhead | Purpose-built for TrekMail destinations, not generic everywhere-to-everywhere orchestration |
For a technical team, imapsync remains the reference point because it exposes the guts of the job instead of hiding them. That is why we published the supporting guide on imapsync. For agencies and MSPs, though, control is not the only variable. Margin matters. So does setup time. So does having the migration path close to the mailbox platform instead of stitched together from three vendors and a spreadsheet.
That is where the old way versus new way split gets obvious. The old way is paying per user for the destination and again per user for the migration tool. The new way is using plan-based email hosting where the migration path is part of the onboarding motion and storage is pooled instead of wasted in rigid per-seat buckets.
Where TrekMail Fits in an IMAP Migration
TrekMail fits when you want multi-domain email hosting without per-user pricing, with server-side IMAP migration, pooled storage, and a cleaner operating model for agencies, teams, and founders. It is still IMAP. It is just less expensive and less chaotic to run.
TrekMail is built for flat-rate multi-domain email hosting. You get custom domains, IMAP mailboxes, catch-all support, mailbox forwarding, BYO SMTP or included SMTP depending on plan, and an API on higher tiers. The migration tool is built into the platform for paid plans, which removes a lot of onboarding friction when moving from Gmail, cPanel, or another IMAP host. TrekMail is IMAP only, not POP3, which is the correct call for shared server-side mailbox state.
Pricing is straightforward: Free at $0, Starter at $3.50 per month, Pro at $10 per month, Agency at $23.25 per month, and Enterprise as custom pricing. Paid plans have a 14-day free trial that requires a credit card. The Nano plan needs no card and no trial. If you pay yearly, pricing is 20% lower.
The bigger advantage is operational. Pooled storage means you stop buying oversized per-user allocations just because one or two mailboxes are heavy. Multi-domain control means agencies and MSPs stop managing client estates through a pile of disconnected admin consoles. And because the migration path lives next to the destination platform, there is less glue code, less credential handoff, and less room for human error.
If you are moving because Google Workspace or Microsoft 365 pricing no longer makes sense for mailbox-only users, that is a valid reason. A lot of organizations are paying suite pricing for people who just need dependable business email. TrekMail fixes that without turning the mailbox layer into a toy.
IMAP Migration FAQ
Most IMAP migration questions boil down to scope, downtime, duplicates, and what happens during cutover. The short version is this: IMAP migration can be safe and low-drama if you stage it, verify it, and do not assume the tool is smarter than the protocol.
Does IMAP migration cause downtime?
Not if you run it correctly. The whole point of staged IMAP migration is to move most data while users stay on the old host, then use a final delta after MX cutover to capture stragglers.
Can IMAP migration move contacts and calendars?
No. IMAP migration is email only. Anything else needs a separate export, sync path, or manual rebuild.
Why do IMAP migration jobs create duplicates?
Usually because the source changed state, Gmail exposed the same message more than once, or the rerun logic did not have proper duplicate skipping. Duplicates are not random. They usually point to a state-tracking problem.
How long does IMAP migration take?
It depends on mailbox size, source server limits, throttling, and concurrency settings. Large mailboxes can take days. That is normal. Plan around it instead of betting the whole move on one weekend.
What is the safest cutover pattern?
Initial sync, delta sync, lower TTL, change MX, final delta, verification. That is the boring path. Boring wins.
Conclusion
IMAP migration is not magic. It is a stateful transfer between two mail systems that do not always agree on folders, flags, limits, or timing. Respect that, and IMAP migration becomes manageable. Ignore it, and you spend the next week explaining duplicates and missing Sent history.
The playbook is simple even if the work is not: pre-stage early, run delta syncs, lower TTL before cutover, map special folders, and verify with counts instead of vibes. If you want a lower-cost destination with pooled storage, flat-rate multi-domain hosting, and a built-in migration path, TrekMail is worth a serious look.
