Moving a website is a copy. Moving email is a copy of something that keeps changing while you copy it, belonging to people who will notice immediately if a message goes missing.
It is the part of a migration that generates the most support contact, and almost all of that is avoidable with sequencing and one warning message.
Decide what is actually being moved
Ask one question first: is the mail stored on the server, or on people's computers?
IMAP keeps mail on the server. Moving hosts means moving all of it, and the volume can be substantial.
POP downloads mail to a device and usually leaves little behind. There may be almost nothing on the server to move, and if "leave a copy on server" was enabled, there may be a decade of it.
Check the actual mailbox sizes before planning anything. A 40 GB mailbox and a 40 MB one are different projects.
Create the mailboxes first
On the new server, create every address that exists on the old one, before any mail moves and before DNS changes.
Match them exactly, including addresses nobody uses. An address that exists on the old server and not the new one starts bouncing the moment MX records change, and the sender is told the address does not exist, which is worse than a delay.
Recreate forwarders and autoresponders too. They are configuration rather than mail, so nothing copies them for you.
Copy mail with IMAP-to-IMAP sync
The reliable method connects to both servers as a mail client and copies messages across, preserving folders and read status.
Tools such as imapsync do this, and most control panels offer a transfer feature that does the same thing. It can be run repeatedly: a second run copies only what is new.
That repeatability is the whole reason to use it. Run it once well before the cutover to move the bulk, then again immediately after, to catch what arrived in between.
The gap, and how to close it
Between the first copy and the MX change, mail keeps arriving on the old server. Between the MX change and full propagation, mail arrives on both.
So the sequence that loses nothing is: copy the bulk, change MX, wait for propagation, then run the sync again to collect what landed on the old server during the changeover.
Skipping the final sync is how a day's mail ends up stranded on a server the client no longer has access to.
Lower the TTL on the MX records
Days before, not on the day. The old TTL has to expire before a new one takes effect, so lowering it at the moment of the change accomplishes nothing.
With a TTL of 300 seconds, the split period is minutes rather than hours. That is the difference between one final sync and several. Understanding DNS propagation explains the timing.
Keep the old server running
For at least a week after the change, and preferably two.
Sending servers that cached the old MX record keep delivering there until it expires. Some retry for days. And a mailbox you did not know existed will surface in that window.
Terminating the old account on cutover day is the single most damaging thing you can do in a mail migration, because the mail that arrives afterwards is not delayed; it is gone.
Passwords do not come across
Mailbox passwords are stored hashed, so they cannot be copied. Every user gets a new password and reconfigures their mail client.
This is the largest source of support contact in any mail migration, and it is entirely predictable, which means it is manageable.
Send each person their settings the day before: server name, ports, encryption, username as the full address, and their new password. Include the settings for the device they actually use, configuring email on iPhone and in Outlook cover the two that generate the calls.
Warn people about what they will see
After reconfiguring, a mail client re-downloads folders and may show messages as unread or reorder them by the date they were copied.
Nothing is lost, and it looks alarming. One sentence in the warning message, "your mail may appear unread for a while, nothing has been deleted": prevents an afternoon of worried calls.
Rebuild the authentication records
SPF, DKIM and DMARC are DNS records tied to the sending server, and they do not transfer.
An SPF record still naming the old server means mail sent from your new one fails authentication. It does not bounce immediately; it starts landing in spam folders, gradually, which is why this is discovered late.
Update SPF to the new server, generate DKIM keys there and publish them, and check DMARC is still consistent. For all three, see understanding SPF, DKIM and DMARC.
Check delivery in both directions
After the change, send a message from a mailbox on the new server to an external address, and one from outside back in.
Then look at the headers of the received message and confirm authentication passed. A mail migration that appears to work while quietly failing SPF looks fine for a fortnight and then does not. Email routing and track delivery sets out reading the delivery report.
Set quotas while you are here
A migration is the natural moment to fix mailboxes that grew without limit, because you are looking at the sizes anyway.
An unlimited mailbox that a migration reveals to hold 30 GB is a problem you have just moved rather than solved. Managing mailbox quotas goes into what to set and what actually fills them.