How to Migrate Email Between Providers with imapsync

What imapsync does (and what it does not)

imapsync is a battle-tested command-line tool that copies messages from one IMAP mailbox (host1) to another (host2). It connects to both servers as a normal IMAP client, walks every folder, and transfers messages that are missing on the destination. Crucially, it is idempotent: it compares messages by their headers (by default Message-Id and Received lines) so running it twice will not create duplicates and will not re-copy what is already there. That property is what makes a near-zero-downtime cutover possible — you sync, you flip DNS, then you run one final pass to catch the last few messages.

This guide is provider-agnostic. The same procedure moves mail from Gmail, Microsoft 365, cPanel, a self-hosted Dovecot box, or any IMAP server into Skyline Cloud business email — kept in-Kingdom for PDPL, NCA, and SDAIA alignment.

Every flag below was checked against the imapsync man page. If a flag is unfamiliar, run imapsync --help or read the man page (man imapsync) before relying on it. Do not copy flags blindly.

Before you start

You need:

• IMAP access on both ends. Source and destination must allow IMAP (port 993 with SSL is standard). On Microsoft 365 and Gmail you typically need an app password or OAuth, not the normal login password.
• Credentials per mailbox. imapsync migrates one mailbox at a time; you script the loop yourself for many accounts.
• A migration host. Any Linux machine with outbound 993 access. Running it close to one endpoint helps throughput, but it is not required.
• A destination mailbox to receive the mail. Create the target inboxes first. If you are moving to Skyline Cloud, sign up and provision your mailboxes before migrating.

Install imapsync

On Debian or Ubuntu:

sudo apt update
sudo apt install imapsync
imapsync --version

On RHEL, Rocky, or AlmaLinux, install via EPEL or the Perl dependencies from the project's README. Confirm it runs before going further — a broken Perl dependency is the most common install issue.

Step 1 — Test the login only

Never start with a real transfer. First confirm both sets of credentials work using --justlogin, which logs in to both hosts and exits without touching a single message:

imapsync \
  --host1 imap.oldprovider.com --user1 ali@example.com --password1 'OLD_PASS' --ssl1 \
  --host2 mail.alskyline.com   --user2 ali@example.com --password2 'NEW_PASS' --ssl2 \
  --justlogin

--ssl1 and --ssl2 request SSL on port 993 (the well-known IMAPS port, so --port1/--port2 are usually unnecessary). If your server offers STARTTLS on 143 instead, use --tls1/--tls2. If you see Success login, both ends are reachable.

Step 2 — Dry run

--dry makes imapsync do everything except write — it prints exactly what it would copy. This is your safety net:

imapsync \
  --host1 imap.oldprovider.com --user1 ali@example.com --password1 'OLD_PASS' --ssl1 \
  --host2 mail.alskyline.com   --user2 ali@example.com --password2 'NEW_PASS' --ssl2 \
  --automap --dry

--automap guesses the mapping for well-known folders (Sent, Junk, Drafts, Archive, Flagged) so a "Sent Items" on one side lands in "Sent" on the other. Read the output: it lists folders found and how many messages each holds.

Step 3 — Run the real migration

Drop --dry to transfer for real:

imapsync \
  --host1 imap.oldprovider.com --user1 ali@example.com --password1 'OLD_PASS' --ssl1 \
  --host2 mail.alskyline.com   --user2 ali@example.com --password2 'NEW_PASS' --ssl2 \
  --automap \
  --logfile /var/log/imapsync/ali.log

By default imapsync deletes nothing on either side — your source stays intact, which is what you want during a migration. Watch the log for the per-folder transfer counts and the final summary.

Useful extra flags

Provider shortcuts

For Gmail, --gmail1 or --gmail2 sets the correct host and Gmail-specific options. For Microsoft 365 / Exchange Online, --office1 or --office2 does the same for outlook.office365.com. Confirm what each shortcut sets — they bundle several flags, and the FAQ files on the imapsync site document them.

Step 4 — Cutover with near-zero downtime

The migration is online; the only switchover moment is DNS. To minimize lost mail:

1. Lower your MX TTL a day ahead so the change propagates fast.
2. Run the full sync while old mail still flows to the source.
3. Switch MX (and SPF/DKIM/DMARC) to point at the new provider. With Skyline Cloud, managed DNS makes this a few clicks.
4. Run imapsync one final time. Because it is idempotent, this pass only copies the handful of messages that arrived after your first sync — no duplicates.

Keep both mailboxes live for a few days. Some clients cache old IMAP settings, and MX propagation is not instant.

Verifying the result

Spot-check folder counts in the destination webmail, confirm Sent and Drafts arrived intact, and re-run with --justfolders --dry to compare folder structure without touching messages. Only after a user signs off should you consider decommissioning the source.

Why move to in-Kingdom email

If the goal is compliance and local control, the destination matters as much as the method. Skyline Cloud keeps your mail on in-Kingdom infrastructure aligned with PDPL, NCA, and SDAIA expectations, with Arabic-speaking support and transparent pricing. For the wider picture of moving systems into Saudi cloud, see our cloud migration hub.

Ready to migrate your mail to compliant, in-Kingdom hosting? Create your Skyline Cloud account and provision your mailboxes, then follow the steps above.