Mail migrations fail in predictable ways, and almost none of them involve the bulk copy. The data moves fine. What goes wrong is the hour around the DNS change, the mailboxes nobody listed, the calendar invites that lose their organiser, and the mail that arrives while you are mid-cutover. This is the sequence that avoids each of those.
01Inventory before you touch anything
The single biggest cause of a bad migration is an incomplete list. User mailboxes are easy - people notice when their own mail is missing. What gets forgotten are shared mailboxes, distribution lists, aliases, forwarders, catch-all rules, and the service accounts that applications use to send transactional mail.
That last category is the one that bites hardest. An invoicing system authenticating against the old mail server will keep failing silently after cutover, and nobody discovers it until a customer asks where their invoice went.
- Every mailbox, including shared and resource mailboxes
- Aliases, distribution lists and forwarding rules
- Service and application accounts that send mail
- Calendar resources - rooms, equipment, shared calendars
- Third-party tools authenticating via SMTP or OAuth
02Lower your DNS TTL a week ahead
MX record changes propagate at the speed of your TTL, and the default is often several hours. If you change MX with a 14400-second TTL still in place, some senders will keep delivering to the old server for four hours after cutover.
Drop the TTL on your MX and any mail-related records to 300 seconds at least 48 hours before the cutover - ideally a week. This costs nothing, and it converts a multi-hour split-delivery window into a few minutes. Raise it again once the migration has settled.
03Run the bulk copy before the cutover, not after
The correct order is: copy everything while mail is still flowing to the old system, then change MX, then run a delta sync for whatever arrived during the copy. Teams that change MX first end up with mail split across two systems and no clean way to reconcile it.
Google Workspace Migrate and the data migration service both handle IMAP sources, Microsoft 365 and Exchange. The bulk pass on a large mailbox set takes days rather than hours, which is exactly why it belongs before the cutover window rather than inside it.
04What the tooling does not carry across
Message bodies and attachments migrate reliably. The things that do not are the ones people notice immediately, because they are the ones tied to identity and workflow rather than to content.
| Item | Migrates cleanly | Needs manual work |
|---|---|---|
| Mail, folders, attachments | Yes | - |
| Contacts and calendars | Mostly | Recurring event edge cases |
| Calendar organiser on invites | No | Re-issue or accept reassignment |
| Mail rules and filters | No | Rebuild per user |
| Signatures | No | Redeploy centrally |
| Shared mailbox permissions | No | Recreate as delegation or group |
05Set SPF, DKIM and DMARC before you send
A migrated domain that starts sending from Google without correct authentication records lands in spam, and the reputational damage takes weeks to undo. SPF must include Google's sending infrastructure, DKIM must be generated in the admin console and published, and DMARC should start at p=none so you can read the reports before you enforce.
Do not skip straight to p=reject. Run p=none for long enough to see which legitimate senders are failing - there is almost always one forgotten application - then move to quarantine and finally to reject once the reports are clean.
06Plan the rollback before you need it
A rollback path for a mail migration means one thing: the old system stays running and reachable until you are certain. Do not decommission it on cutover day, do not cancel the licence, and do not let the hosting lapse. Keep it for at least two weeks after the last user is confirmed working.
The reason is that mail problems surface slowly. A broken forwarding rule or a service account that cannot authenticate might not be noticed until someone goes looking for a message that never arrived, and by then you want the old system still there to check against.
07The first week after cutover
Expect a short tail of individual issues rather than a single large failure: a user whose filters did not come across, a shared mailbox that is now a group with the wrong permissions, an application still pointed at the old SMTP host. Triage these centrally rather than letting each person solve their own, or you will end up with a dozen inconsistent workarounds.
Watch the DMARC reports closely in this window. They are the fastest way to discover a legitimate sender you forgot about, because the sender itself usually has no idea it is failing.
Topics
Priya Iyer
Staff Engineer · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.