Email is the one migration where failure is immediately visible to people outside the organisation. A bounced message to a customer is a worse outcome than an hour of internal downtime, and it is entirely avoidable with a bit of sequencing.
Lower TTL before anything else
DNS records are cached for their time-to-live. If MX records carry a 24-hour TTL, some senders will keep delivering to the old server for a day after you change them.
Drop the TTL to a few minutes at least 48 hours ahead — long enough for the old long TTL to expire everywhere. Do nothing else that day. This single step converts a day-long tail into a few minutes.
Sync mailboxes before cutover, then again after
Run a full sync while mail is still flowing to the old server. It takes as long as it takes — large archives can run for days — and there is no reason for that to happen during the cutover window.
After the MX change, run a delta sync to collect anything that arrived at the old server between the last sync and the cutover. Skipping this is how a few hours of mail quietly disappears.
Expect the archive to be larger than anyone claims. Check actual mailbox sizes rather than relying on an estimate, because it determines how long the first sync runs.
Authentication: get all three right
This is the part that causes delivery problems in the weeks after a migration, long after everyone has declared the project finished.
- SPF must list the new sending infrastructure. If applications, a CRM or a bulk sender also send as your domain, they need to be in there too. Only one SPF record per domain — a second one invalidates both.
- DKIM keys are generated by the new provider and published in DNS. Mail signed with a key that does not resolve fails authentication.
- DMARC tells receivers what to do when the other two fail. Start in monitoring mode, read the reports, and only move to a stricter policy once you can see that legitimate mail is passing.
Publishing a strict DMARC policy on migration day, before knowing which systems send as your domain, is the most common self-inflicted email outage there is.
What people forget to migrate
- Calendars and contacts. Frequently treated as an afterthought and frequently the loudest complaint.
- Shared and departmental mailboxes — info@, sales@, support@ — and who has access to each.
- Distribution lists and aliases, which rarely have documentation.
- Forwarding rules set up years ago by people who have left.
- Application senders. Every system that sends mail as your domain: the website contact form, the ERP, invoicing, monitoring alerts. Each needs new credentials or relay permission, and each will silently stop otherwise.
That last one is the most commonly missed. Make the list before cutover by checking the old server's logs for what actually authenticated against it, rather than asking people what they think sends mail.
Cutover day, in order
- Final delta sync
- Change MX records
- Send a test from outside to a mailbox on the new system; confirm headers show the new path
- Send from the new system to an external address and check it is not classified as spam
- Verify each application sender individually
- Delta sync again a few hours later to catch late deliveries to the old server
Keep the old mailboxes for a month
Not accepting mail — just readable. Somebody will need an attachment that did not sync, and paying for another month is far cheaper than the alternative.
About the author. Kislay Chandan has worked with schools since 2014. Rather than gathering requirements from the outside, he worked inside a school to see what actually goes wrong day to day, and built what he found into the software. He still works with Shemrock Glitters in Patna — most changes to the product start with something that came up there.
Gallery
