Migrating mail with imapsync without losing messages

imapsync's strength is that it can be run repeatedly: every rerun fetches only new messages. That turns a one-off transfer into a safe process with no single downtime window for mail, unlike manually dragging messages in a mail client.

Create mailboxes on the new server with the same logins but new passwords.
Run the first imapsync pass — it transfers the bulk of messages while MX still points at the old server.
Run imapsync again right before the MX switch — it copies over messages that arrived during the first pass.
Switch the MX record to the new server.
Run imapsync one final time a day after the switch — it picks up messages that landed on the old server because some providers' DNS cache had not updated yet.

Installing imapsync

# Ubuntu/Debian
apt install imapsync -y

# Check the version
imapsync --version

Basic mailbox transfer

imapsync   --host1 mail.oldserver.com --user1 user@oldserver.com --password1 "old_pass"   --host2 mail.newserver.com --user2 user@newserver.com --password2 "new_pass"   --ssl1 --ssl2   --exclude "Trash"   --nofoldersizes

💡 imapsync can be run several times — a repeated sync transfers only new messages. Ideal for a zero-downtime migration.

Batch transfer of several mailboxes

#!/bin/bash
# accounts.txt: user1@old.com:pass1:user1@new.com:pass2
while IFS=: read -r user1 pass1 user2 pass2; do
    imapsync       --host1 mail.old.com --user1 "$user1" --password1 "$pass1"       --host2 mail.new.com --user2 "$user2" --password2 "$pass2"       --ssl1 --ssl2 --nofoldersizes &
done < accounts.txt
wait

The & at the end of the command runs the mailbox transfer in the background, and wait waits for all background jobs to finish — this way dozens of mailboxes transfer in parallel instead of one at a time.

Comparing run modes

Mode	Speed	When to use
One mailbox, sequential	low	1-5 mailboxes, a test run
Batch run with & and wait	high, limited by the network	dozens or hundreds of mailboxes
With the --maxbytesaftersync flag	medium, precise control	a limited link, needs a metered transfer

Useful flags for a real transfer

Flag	What it does
--dry	Shows what would be transferred without actually writing any messages
--delete2duplicates	Removes duplicates on the destination before a repeated run
--useuid	Keeps the original message UIDs instead of generating new ones
--log	Writes a detailed transfer log to a file for troubleshooting

Before the first real run in production, it is worth doing one pass with the --dry flag — it shows how many messages and folders would be copied, without a single real write on the new server. This lets you estimate the full transfer time from the message count in the output.

Checking before the MX switch

Add the new mailbox to a mail client as a separate account, pointing directly at the new server's address, bypassing the domain's MX record:

# Manual connection to the new server for testing
Server: mail.newserver.com
Port: 993 (IMAP/SSL)
Login: user@oldserver.com

Compare the message count and folder structure with the original mailbox — they should match after every imapsync run.

Common errors

Error	Fix
SSL certificate error	Add --nossl1 or --tls1
AUTHENTICATE failed	Check the password, enable IMAP in the settings
Connection timeout	Add --timeout 60
Folder not found	Use --f1f2 to map folders

Rollback in case of problems

Do not delete mailboxes on the old server for at least a week after the MX switch.
If the new server behaves unstably, restore the old MX record.
After rolling back, run imapsync in the reverse direction to pick up messages that arrived on the new server.

When imapsync does not fit

For a move to Microsoft 365 or Google Workspace, it is better to use those platforms' built-in migration tools — they account for the specific provider's quotas and API limits, which a plain IMAP client cannot see. imapsync works well between ordinary IMAP servers, but it does not replace native migration into corporate mail platforms.

Checking the result

Compare the message count in "Inbox" and "Sent" between the old and new mailbox.
Check that attachments open and were not corrupted during the transfer.
Send a test message to the new mailbox from outside and confirm it does not land in spam.

⚠️ Do not switch MX records before the transfer finishes. Run imapsync one final time after the MX change to sync the last messages. The general MX-switch procedure with no downtime is in migrating email to a new hosting, and a safe DNS zone change itself is in DNS migration without downtime.