Moving email without losing messages

Site files can be copied twice, and if the second copy is wrong you copy them a third time. Mail does not work that way. A message that reaches a mailbox nobody is watching, or that sits on a server you have already cancelled, is not recoverable by anyone, at any price. Treat the mail half of a move as a one-attempt job and plan it before you plan anything else, because the first decision in it changes every step that follows.

Decide first: mail stays with the host, or mail leaves

This is not a preference question, it is a scoping question. The answer determines whether mail and website cut over on the same day, what kind of copy you are doing, and who you contact when something is missing.

Decide this while the old setup is still fully running. Changing your mind halfway means running two migrations, and the second one starts from a mailbox that is already incomplete.

The gap after the copy finishes

Any mailbox copy is a snapshot of a moment. Once it completes, mail keeps arriving at the old server, because sending systems and resolvers hold cached routing for as long as the previous value permitted, and because deferred queues retry for days rather than hours. A cached lifetime of 14400 is four hours before anything changes at all, and a message that was already queued elsewhere on Friday can land on the old server on Monday.

The fix is boring and it works: lower the routing lifetime several days ahead, run the first full copy, switch the routing, then leave both sides reachable and run a second pass that picks up only what arrived after the first. Do not schedule the second pass for the same afternoon. Give it at least a working day, and repeat it once more before you stop.

Local-only mail is the risk nobody reports

Server-side migration tools copy what is on the server. They cannot see anything that only exists inside someone's mail application: accounts collecting mail and removing it from the server as they go, archive folders stored on one laptop, or an export file sitting in a documents folder. Years of correspondence can be invisible to the entire migration, and the person most likely to be set up this way is the one whose mail matters most, because their account is the oldest.

Ask every user two questions before the cutover date is fixed:

• If your laptop died tonight, would your mail still exist somewhere else?
• Do you have folders that only appear in your mail program and not in webmail?

Anything that fails those questions has to be uploaded into a normal server folder, or exported to a file and stored off both servers, before the move starts. Take one offline export per mailbox anyway. It is the only copy that survives a mistake on either side.

Do not delete on cutover day

Keep the old mailboxes reachable and logged into for a defined period after the switch, not until you feel done. Thirty days is a floor. Some genuinely important senders only write quarterly: registrars, accountants, banks, certificate notices, annual renewals. Write the closing date down, confirm message counts and folder sizes match on both sides, and only then close it. Plan the window with your provider in advance through contact, and sequence it alongside the rest of the work in moving in.