Migrating mail off cPanel without losing any

Every mail migration has the same failure mode: mail that arrives at the old server between the copy finishing and the MX record changing. It is a small window and it contains real messages, and the way people usually notice is a customer saying “I sent that on Tuesday”.

The order that avoids it

1. Add the domain at the new server first, and publish everything except the MX. SPF, DKIM, DMARC — all of it can be published and verified while the old server is still live and taking mail. Nothing about this step is visible to anyone.
2. Run the full copy, with the old server still receiving. This is the long part. On a big account it is hours; it does not matter, because nothing has moved yet.
3. Change the MX. New mail now arrives at the new server.
4. Run the delta. Everything that arrived at the old server during steps 2 and 3 comes across now. This step is the entire point of the order, and skipping it is how the Tuesday message is lost.
5. Leave the old account in place for a couple of weeks. It costs nothing and it is the only undo you have.

Steps 2 and 4 are the same operation run twice, which is why a migration tool that cannot resume or re-run is not much of a tool.

What comes across, and what does not

This is the part people discover afterwards, so it belongs here rather than in a footnote.

• Mail, folders and flags — read, flagged, answered — are copied over IMAP. cPanel’s API cannot read a single message; what it does is tell the migration who exists.
• Forwarders, autoresponders and filters are read from cPanel and imported. A forwarder on an address that is also a mailbox becomes a forwarder that keeps a copy; one on an address that is not becomes an alias.
• Filters that cannot be expressed exactly are skipped, each listed with its reason: regex matches, SpamAssassin spam-score rules, a mix of “and” and “or”. Those are recreated by hand. A filter over 20 conditions or 10 actions is the exception — it is imported cut to fit, with a note.
• Autoresponder placeholders such as %subject% come across literally, because Sieve does not expand them. Edit them after importing.
• Passwords. Nobody can copy a password hash between systems that hash differently. Every user gets a new password, and planning how you communicate that is part of the migration rather than an afterthought. The API token cannot open a mailbox either, so the copy needs a Dovecot master user on the old host — cPanel does not ship one — or each mailbox’s current password.

The thing worth checking before you start

Quota on the destination. Carrying a mailbox’s quota across copies the number, not the accounting, and two servers do not count bytes identically. A mailbox sitting near 100% of its quota on the source fills the new one before the last messages land, and fails on quota. Raise the destination quota and re-run — the re-run copies only what is missing. In testing, a 250 MB mailbox failed on its final 106 KB message.

The safety property that matters

The connectors hold credentials that could damage the old account — cPanel’s API would let them change passwords and delete forwarders — and deliberately never use a write verb. Each has a test asserting only reads are sent. That is what makes a failed migration cannot have damaged your old mail a property of the code rather than a promise in a brochure, and it is the sentence to look for in anybody’s migration tooling, including ours.

The full cPanel migration page has the credentials you need and the rest of the limits. Plesk is the same shape.