When a site moves to a new host, mail is the painful part: files can be copied overnight and nobody notices, but messages arrive around the clock and every pause means a lost customer email. The right order removes the problem entirely: mail is migrated BEFORE the domain is switched, while both servers still work, and a second run after the switch collects the tail.
What to collect first
Migration runs per mailbox, so start with a list: addresses, volumes, credentials. Passwords do not travel from the old host — mailboxes on the new one are created from scratch with passwords of their own.
Every mailbox on the domain and its size — from the old host’s mail section.
Free space on the new plan: the total volume has to fit with room to spare.
Mailboxes created on the new host in advance, with passwords you know.
The current TTL on the MX records: it decides how long the switch will take.
Where the panels show IMAP settings
The panel tells you the server name and port — there is nothing to guess. Paths for the three most common ones:
cPanel: Email → Set Up Mail Client (the "Connect Devices" button in the email account list).
Plesk: Websites & Domains → the domain → Mail Accounts → Mail Client Setup. IMAP is 143 by default and 993 with SSL; the username is the full email address.
DirectAdmin: server mail.yourdomain, IMAP 993 over SSL, username is the full email address.
Other panels: look for a section named something like "mail client configuration" — nearly all of them have one.
The order that loses nothing
The key point: a migration never modifies the source and needs no downtime, so it happens ahead of time, not on the night of the switch.
A day or two before the move, lower the TTL on the MX records so the switch propagates faster.
Migrate the mail to the new host while the domain still works the old way. People keep using the old mailboxes.
Switch the MX records to the new provider.
A day later, run the migration again: it collects whatever reached the old server while DNS was changing. Already transferred messages are skipped, so no duplicates.
Keep the old hosting alive for another week: mail can still arrive there through cached records.
What IMAP does not carry over
The protocol deals with messages and folders. Everything else is set up on the new host by hand — better known in advance than on moving day.
Mailbox passwords, auto-responders, filtering and forwarding rules.
Catch-all addresses and mail aliases.
Contacts and calendars — not mail, not carried by IMAP.
Spam filter settings and everything it has learned.
Today one mailbox per job: you enter the source and the destination and start it. A domain with ten mailboxes means ten runs — not fast, but predictable. Bulk migration from a list is planned.
What if the mailbox on the new host already has mail in it?
Not a problem: identical messages are skipped rather than duplicated. That is exactly why re-running after the MX switch is safe.
Will users notice the move?
Not if you migrate ahead of time. The source is never modified and the old mailboxes keep working. The only visible moment is when you hand out new passwords and settings for their mail clients.
Do I need anything from the old host?
Usually just the mailbox passwords. If IMAP is disabled on the plan or blocked by a firewall, that is the one thing worth asking support about.
Find out how big your mailbox is. It costs nothing.
Connect two servers, look at the size and decide. Or take the client and keep everything on your side.