Of all migrations, mail is the most feared, and rightly: a badly rebuilt website can be rebuilt, a ten-year archive lost does not come back. It is also the operation with the most settled procedure, provided one premise is accepted: mailboxes are not moved, they are copied.
The principle: copy, do not transfer
There is no operation that "moves" a mailbox from one provider to another. What happens is that you connect to both at once and copy message by message, with the folder structure, the attachments and the read states.
Two useful consequences follow.
There is no moment of risk. While the copy runs, the original is untouched. If something goes wrong you start again, and nothing has been lost.
The copy can happen while everything is working. You do not have to stop the mail to copy it. You copy with the mailboxes live, and that is what makes a migration without disruption possible.
The protocol that allows this is IMAP, which keeps messages on the server rather than on the computer, and it is why this procedure works between providers that know nothing about each other.
The window problem
There is one complication, and it is the whole game.
While you copy, the mailbox keeps receiving. The copy starts Monday and finishes Tuesday; in the meantime new messages have arrived, which the copy does not contain. If you then change the MX records and switch the old server off, those messages stay behind.
Hence the two-pass procedure, which is what separates a migration done properly:
- First full synchronisation, with everything still running at the old provider. It can take hours or days depending on volume, and disturbs nobody.
- Change the MX records, so new mail starts arriving at the new server.
- Second synchronisation, immediately afterwards, copying only what arrived in between. It is quick, because the bulk is already across.
- Old server left on for a few more days, because not everybody updates DNS at the same instant: some senders will keep delivering to the old address until their TTL expires.
- A final third pass before switching off, to collect that remainder.
Skip step 3 and you lose exactly the mail from the day of the switch — which is the mail people remember, because it is recent.
What comes across and what does not
It is worth being explicit, because wrong expectations do more damage here than technical errors.
Copied: messages with their attachments, the folder structure, read and unread states, original dates, flagged messages.
Not copied by itself: rules and filters, which live in the provider's configuration and have to be rebuilt by hand; signatures; contacts and calendars, which use different protocols and are migrated separately; aliases and distribution lists, which are domain configuration rather than mailbox content.
That second list is what gets missed in quotes. A migration that copies the messages and leaves the company without its sorting rules is technically successful and practically irritating for weeks.
The details that sink a migration
Passwords. You need credentials for every mailbox, and in a company often nobody has them. It is solved with the provider's administrative access, where that exists, or by resetting passwords before starting — better known in advance than halfway through.
Provider limits. Some cap simultaneous connections or bandwidth: too aggressive a copy gets throttled or blocked. You find out on the first trial, which is why a trial always runs on a single mailbox first.
Enormous mailboxes. An archive of tens of gigabytes takes time and sometimes has to be split by folder. That time is estimated beforehand, not discovered on the evening of the switch.
Folder names. Different providers treat system folders differently — Sent, Trash, Archive — as well as accented characters. Without correct mapping you end up with duplicated folders and messages in the wrong place.
Forgotten mailboxes. info@, accounts@, the address of the employee who left but on which orders still arrive. The mailbox inventory is taken by looking at the panel, not by asking people.
How to verify it went well
Not "looks fine": you check, and it is three things.
Message counts, folder by folder, before and after. A different number always has an explanation, and it gets found before anything is switched off.
A real sample. Open an old message with an attachment and confirm the attachment is there and opens.
The full round trip. Send an email to the company from outside and one from the company outwards, and read the headers to be sure it is going through the new server and not still the old one.
Only after those three checks, and a few days of ordinary traffic, does the old environment get switched off. Switching it off is the last operation of a migration, never the first — that holds for mail as much as for the rest of the move.