Best Mailbox Migration Tools to Move Email Providers (2026)

This is a ranking of the best mailbox migration tools to move email to a new provider — for the person doing five mailboxes for a small team, or five hundred for a tenant cutover. It is not the how-to for a single mailbox; if that is your job, our step-by-step migration guide is the one to read instead.

The category matters more than the brand. There are three shapes of tool, they preserve different things, and picking the wrong shape is what makes a migration bleed a weekend rather than take one afternoon.

What actually moves — and what doesn't#

The mail body and its attachments move. That part is boring and almost never breaks, because the message itself is a single MIME blob that any IMAP-aware tool can APPEND into the new server. The parts that break are the metadata around the message and everything that lives outside the mail store.

Here is what usually survives a mailbox transfer and what usually doesn't. "Usually" is doing real work in that sentence — the details depend on the tool and on both providers involved.

The three shapes of mailbox migration tool#

Before you pick a product, pick a shape. The differences below decide the whole project — packaging shape, blast radius, and how much of the work is yours versus theirs.

The axis these categories are actually competing on is not features — it is who owns the retry loop when a mailbox fails halfway through. A script hands it to you and gives you a log; a managed service hands it to a dashboard; a native importer hands it to a batch report that may or may not tell you which item failed.

**imapsync has built harder on delta re-runs and IMAP-flag fidelity than any managed dashboard we have looked at.** If you are moving fewer than fifty mailboxes and the source is standard IMAP, it is the tool most infra engineers will reach for. The managed services earn their keep at the scale where a per-mailbox dashboard and a partner support line save more time than a script.

Pre-migration checklist#

Do this in the week before the cutover, not the morning of. Every item catches a class of failure you would otherwise discover at 4 p.m. on migration day.

• Inventory every mailbox with its size, item count and largest single message. Microsoft's IMAP importer caps at 500,000 items and 35 MB per message — anything above needs a different path.
• Confirm IMAP is actually enabled on both sides. Gmail requires it turned on per-user; Microsoft 365 has been quietly deprecating basic-auth IMAP for years, so plan on OAuth or an app password.
• Note the folder delimiter each server uses (`/`, `.` or `\`). Mismatch here is the single most common source of "my folders are gone" tickets.
• Snapshot the current filter/rule set as a JSON or XML export. This layer never migrates with the mail; you re-import it separately on the destination.
• Export calendars (ICS) and contacts (vCard/CSV) if they live with the mailbox — CalDAV/CardDAV are separate migrations from IMAP.
• Book a maintenance window that assumes the migration will take longer than the tool estimates. A 25 GB mailbox on a rate-limited API commonly takes 8–14 hours, not the two the calculator promises.
• Send yourself a test message on the source and confirm it appears on the destination end-to-end before you tell anyone the move is done.

What breaks, and why#

These are the failure modes you will hit in practice, sorted by how often we see them cause a re-run rather than a warning.

A working sequence for 5-to-500 mailboxes#

The pattern below is what an infrastructure team runs when the number is large enough to matter and small enough that a partner isn't worth the overhead. Adapt the tool names; keep the order.

1. 1

   Pilot one mailbox end-to-end

   Pick a mailbox with a rich folder tree, at least one 30 MB attachment, and a mix of read and unread threads. Migrate it, then diff item counts per folder and open five random messages. This is where you catch delimiter, date and label bugs before they hit 499 more mailboxes.

2. 2

   Freeze the source for the pilot user

   For the duration of the pilot, either forward new mail or accept that anything arriving mid-migration will need a delta pass. Skip this and your item counts will never match.

3. 3

   Run the initial bulk pass

   Kick off the full-mailbox migration for the pilot cohort (10 mailboxes is a good size). Cap concurrency; watch the source's throttling responses in the log. A per-mailbox log — not a summary — is what turns a 3 a.m. failure into a resumable job.

4. 4

   Cut MX or DNS to the new provider

   Once the initial pass is complete for the cohort, move MX for those users. New mail lands on the destination from that moment; the source is now a receding backlog.

5. 5

   Delta re-run against the source

   This is why imapsync-style tools matter: a delta pass copies only what arrived after the initial run and does not duplicate what is already there. Managed services usually run this on a schedule; scripts you run once, or twice, until the source is quiet.

6. 6

   Re-import filters, signatures and out-of-office by hand

   None of these travel with the mail. Set aside real time — often an hour per active user — to translate rules into the destination's syntax and paste signatures back in.

7. 7

   Verify with a manifest, not a spot check

   Export message counts per folder from both sides and diff them. A tool's own success log is not verification; a manifest that matches to the message is.

Rollback plan#

A real migration has a rollback plan, because sometimes the destination misbehaves and you need the old mailbox back for another week. The plan is simple if you set it up in advance and impossible if you don't.

• Leave the source mailbox intact and read-only for at least 30 days after cutover. Do not delete accounts to save licence fees on day two.
• Keep the DNS TTL on your MX record short (300–900 seconds) for the week either side of the cutover. Long TTLs are what turn a 15-minute reversal into a 24-hour outage.
• Take an MBOX or EWS-level export of every mailbox on the source before you touch it. This is your parachute; a fresh export after the migration completes proves the source is quiet.
• Test rollback on the pilot user by pointing their client back at the old server for an hour. If that works, the rollback works for everyone.

Doing it without downtime#

The closest thing to a downtime-free mailbox migration is a two-phase move: bulk copy while the source is still live, cut MX, then a delta pass for anything that landed during the cut. Users see their mail on the new provider within minutes; the tail of a few undelivered threads gets copied in the delta.

True zero-downtime is only possible when the source and destination are dual-delivered for a window — some managed services offer this against Microsoft 365 and Google Workspace, and it is the reason they charge per mailbox. Dual delivery is expensive to implement yourself and rarely worth it under a few hundred users.

For any tool: the practical measure of "downtime" is not the mailbox being unavailable, it is a user seeing messages arrive in the wrong place. Freeze the source, cut MX, run the delta, unfreeze the destination — in that order — and the visible outage is the DNS propagation window, not the migration.

Where AI Emaily fits in this project (and where it doesn't)#

AI Emaily is not a mailbox migration tool. We do not move a mailbox from Zoho to Google Workspace, and if that is your project, use imapsync or a managed service from the table above rather than looking for a way to make us do it. We build AI Emaily and we would rather say so plainly than sell you the wrong thing.

What we do is the job that starts the day after the migration finishes: connect to the new Gmail, Outlook, iCloud, Fastmail, Proton or IMAP mailbox over standard OAuth, triage what is arriving, draft replies in your Personal Context voice, and never host the mail. Because we read the mailbox rather than own it, you can point us at the destination on cutover day and disconnect if you change your mind — the mail stays where your new provider put it. Start a 7-day trial at /pricing when the migration is done.