Websites migrate in hours; email migrates in days — and a lost customer email costs more than a day of downtime. Here is the mail-side migration nobody plans until messages vanish.
Why mail splits during migration MX records (which point your mail) propagate like all DNS — some senders reach your old server while others hit the new one for hours to days. Mail arriving at the OLD server during that window goes to the OLD mailbox. Miss that fact, lose those messages.
The safe pattern (before touching anything) 1. Inventory: every mailbox on the domain (info@, sales@, personal accounts) — where does each live NOW? 2. Decide the destination: hosting mailboxes, forwarding to Gmail, or a workspace — BEFORE the website moves 3. If mail stays where it is (external provider): touch NOTHING — MX untouched means mail never blips. This is the easiest path; take it when available 4. If mail moves: lower MX TTL a day ahead, create NEW mailboxes on the new host first, then switch MX
The split-inbox week (the recovery discipline) - Keep the OLD mailbox alive and checked for 5–7 days after the switch - Forward anything that lands there manually; reply from the new address - Day 7: the old mailbox's arrival rate hits zero — then, and only then, close it
The testing protocol (before announcing anything) Send from a NON-domain address (Gmail) to info@ → arrives where expected? Reply → does it arrive (not in spam)? SPF/DKIM updated for the new sender? A business email that lands in spam is downtime with extra steps.
The disaster scenario to avoid (the horror story) Nameservers switched, old hosting canceled in the same week, mail for the domain bouncing into the void for days while customers' quotes vanish. The checklist's line 18 exists because this happened enough times to earn it.
Website migration gets the glory; email migration keeps the revenue. Plan both, test both, and let the split-inbox week run its course — the messages you save are the ones that pay for the new host.