Migrating Mailboxes Between Servers: imapsync With Zero Lost Messages
Zero-loss email migration relies on a four-step plan: inventory, first sync, incremental delta, then an MX switch with low TTL. Learn the practical imapsync commands and how to verify by message count and size.
Migrating mailboxes between two servers with zero lost messages is entirely possible if you follow a four-step plan instead of random copying. Step one is inventory: get a list of every account with its size and message count from the source server, your reference number for verification later. Step two is a full first sync with the imapsync tool while you are still receiving on the old server, moving the bulk of the data with no service interruption. Step three is an incremental delta: run imapsync again right before the switch so it transfers only the new messages that arrived during the first sync, and this pass is fast because the majority is already moved. Step four is switching the MX record after you have already lowered its TTL to 300 seconds, so mail reception moves to the new server within minutes rather than hours. The whole key is lowering TTL a day or two before the migration, and verifying by matching message counts and sizes between source and destination before closing the old account. This way no message is lost, and the user feels no meaningful interruption.
Why imapsync Is the Right Tool
imapsync is a command-line tool that moves messages between two IMAP servers with full structure preservation: folders, read state, flags, and original dates. Its most important trait is that it is incremental by nature, meaning if you run it a second time it does not re-transfer what was already moved, only the new, and this is the basis of the incremental delta plan that achieves near-zero downtime. It runs from any intermediate machine that can reach both servers over IMAP and needs no root access on either, just the login credentials of each account or an admin account that reaches all mailboxes.
The alternative to imapsync is manual export and import via files, which is slow, error-prone, and sometimes loses read state and folder structure. For an enterprise migration of dozens of accounts, imapsync is the practical standard.
Step 1: Inventory the Mailboxes
Before moving anything, know what you are moving by the numbers. Prepare a table of every account with its size and message count as your verification reference. Duration estimation depends on total size and transfer speed, and the rough rule is that imapsync moves between 1 and 3 gigabytes per hour depending on message count, size, network speed, and source provider limits. Many small messages are slower than few large ones of the same total size, because each message requires its own IMAP command exchange.
| Total mailbox size | Estimated first-sync duration | Note |
|---|---|---|
| Up to 10 GB | 4 to 10 hours | Can finish in one night |
| 10 to 50 GB | 1 to 2 days | Spread accounts across parallel batches |
| Over 50 GB | 2 days to several days | Start early and watch source provider limits |
Step 2: Lower TTL First
Many people skip this step, which needlessly lengthens the downtime. A day or two before the switch, go to the domain's DNS management and lower the MX record TTL to 300 seconds (five minutes). TTL is how long DNS servers worldwide keep the old record in their cache, so if it is 86400 seconds (a full day), some senders may keep delivering your mail to the old server for a day after the switch. By lowering it to five minutes in advance, the switch propagates almost instantly at execution time.
Step 3: First Sync Then Incremental Delta
Run imapsync for the full first sync while the old server is still receiving. The basic command per account looks like this:
- imapsync specifying host1, user1, password1 for the source and host2, user2, password2 for the destination.
- Add --ssl1 and --ssl2 to force encrypted connections on both ends.
- Add --automap to automatically match special folder names between source and destination.
- Add --dry for a first trial run that shows what would move without actually moving it, to confirm credentials and folders are correct.
After the first sync completes, do not switch MX yet. Run the exact same command again right before the switch, so imapsync performs the incremental delta and transfers only the new messages that arrived during the first sync's hours. This pass is very fast because most data already exists at the destination, and here is where zero loss is achieved: every message that arrived during the transfer is captured in this round.
Parallelizing Accounts to Speed Up
Do not move accounts one by one if you have dozens. Run several imapsync processes in parallel (three to five together is typical) to greatly cut the duration, while watching that you do not exceed the source provider limits. Our cloud server with enough cores handles this parallelism easily, and about 8ms latency from Riyadh shortens the time of every command exchange with any account on the new server.
Step 4: The Switch and Verification
After the incremental delta, switch the MX record to point to the new server. Because TTL is five minutes, the change propagates quickly and new mail starts reaching the destination. Leave the old server running a few extra days as a safety net, and run one final imapsync round a day after the switch to catch any message delayed on the old server due to a sender holding an old record.
Verification is what gives you confidence before closing the old account. For each account, match three numbers between source and destination:
- Total message count in each main folder (Inbox, Sent, Archive).
- Total size of the mailbox, with a small tolerance for differing size calculation between the two servers.
- Presence of the latest message by date in each folder, confirming the incremental delta did its job.
imapsync itself prints a summary at the end of each run with transferred and remaining message counts, use it as a first indicator then manually confirm on a sample of important accounts.
Common Errors and Their Fixes
The most common issue is source provider limits: some mail providers cap concurrent connections or request rate, causing disconnection errors during parallelization. The fix is reducing parallel processes and adding a small delay between requests. A second issue is folders with special names or non-standard characters, solved by --automap and --folderrec when needed. A third is a mid-transfer disconnection, simply solved by re-running the command because imapsync is incremental and resumes where it stopped without duplication. Also confirm that destination accounts were created in advance on the new server with enough quota before starting.
The DNS Records Forgotten After MX
Switching the MX record moves mail reception, but moving sending correctly needs updating three other records that are often forgotten, so your messages reach the inbox for some and get rejected by others. The first is SPF, which specifies the servers allowed to send on behalf of your domain, so update it to include the new server or some parties will flag your messages as spoofed. The second is DKIM, which digitally signs your messages to prove their origin, and it has a private key per server, so generate a DKIM key on the new server and add its record to DNS before switching sending. The third is DMARC, which tells receiving servers how to handle a message that fails SPF or DKIM, and confirm its policy aligns with the new setup.
The practical rule is to prepare SPF and DKIM on the new server before the switch, then update them in DNS in parallel with the MX switch. A day after the switch, send a test message to an external account and inspect the message headers to confirm SPF and DKIM pass, which ensures your corporate mail reaches the inbox rather than the junk folder. Skip this step and your sending effectively breaks despite a successful mailbox migration.
A Concise Execution Plan
Start with mailbox inventory and reference numbers, and lower the MX TTL to 300 seconds two days ahead. Prepare destination accounts on your Saudi cloud server, run a --dry pass to confirm, then the full first sync while mail is still on the old server. Right before the switch run the incremental delta, switch MX, then run a final round a day later. Match message counts and sizes before closing the old server. If you are migrating heavy corporate mail, hosting it on a Saudi server from the Cloud Server page or on managed Cloud Hosting keeps your mail in the inbox rather than the unknown, and plan details are on the pricing page. The bottom line: a four-step plan, verification by the numbers, and zero lost messages.
