I just finished a cutover for a client from one host to another and wanted to share the timing that actually worked. The core idea is staged MX with overlapping TTL windows. I feel you if you've been burned by DNS propagation before.
Phase 1: Lower TTL on old MX records 48 hours before (I used 300s).
Phase 2: Stage new mailboxes and sync via IMAP.
Phase 3: Add new MX at higher priority but identical weight, let it run parallel for 6 hours.
Phase 4: Flip priority, monitor queues.
Phase 5: Remove old MX after 24 hours clean.
I tested this during my own migration last week. Worked for 12 clients. One client lost three emails during the parallel window, I think due to a Thunderbird bug with duplicate UID detection. Updating guide with honest caveat.
Oh man the thunderbird thing (I knew it) so I did basically this same migration back in march for a friend who runs a small auto shop (he does not understand computers at all which is fine we all start somewhere) and the thunderbird clients were absolutely the worst part because thunderbird caches everything locally in these weird profile folders and if you have multiple accounts configured it gets confused about which server it is talking to especially if the MX priority flip happens while it is mid-sync (which it always is because thunderbird is always syncing something) and we had this one machine that kept trying to send through the old server for like six hours after the flip because of some hidden server preference that does not even show in the UI (you have to dig in config editor which most users will never do) and I spent an entire saturday on the phone with this guy walking him
One client lost three emails during the parallel window
I have performed similar migrations; the Thunderbird UID validity issue is well-documented but poorly understood by most administrators; the client caches UIDVALIDITY per folder and treats a changed value as a full re-sync trigger; this can cause apparent message loss when messages exist on both servers with different UIDs; your parallel window helps but does not eliminate the race condition entirely; I recommend adding a Thunderbird-specific warning to your guide; the IMAP protocol itself is sound; the clients are the weak link; -- Marcus
U fink u can ever do zero downtime email lol fats chance bro email is fundamentally broken protocol anyway u gonna lose someting somewhere dns is not consistent fthis whole idea is cursed just tell em 15 min maintenance window and be done wif it
Post a reply
You need an account to reply.
Log in or
register to join the conversation.
