Migrations do not usually fail on the mailboxes. They fail on everything attached to the mailboxes that nobody wrote down. Work through this before you pick a cutover date, not during the week of.
Mailboxes and identities
- Every user mailbox, with its size, because oversized mailboxes stall syncs quietly
- Shared mailboxes, which are the single most commonly forgotten item
- Distribution groups and who is in them
- Aliases on every account, including ones set up years ago for a campaign nobody remembers
- Forwarding rules, both user-set and admin-set, which frequently point at personal addresses
- Resource mailboxes for meeting rooms and equipment
- Any mailbox that exists only to receive from a system, such as a scanner or an application
DNS, and it is always DNS
| Record | Why it matters | When to change it |
|---|---|---|
| MX | Routes incoming mail | At cutover |
| TTL on MX | Controls how fast the change propagates | Lower it several days before |
| SPF | Says who may send as your domain | Before cutover |
| DKIM | Signs outbound mail | Before cutover |
| DMARC | Tells receivers what to do on failure | Before cutover, in monitor mode first |
| Autodiscover | Points clients at the right server | At cutover |
TTL is the free win
Lower the MX TTL several days ahead. If it is left at a long value, propagation takes hours and mail splits across two platforms while you watch.
Applications that send mail
This is the category that surprises people most, because these systems are invisible until they stop. Anything sending mail through your domain needs its settings updated, and each one is a separate small job.
- Multifunction printers and scan-to-email
- Your website contact forms and any CRM or marketing platform
- Accounting and invoicing software sending statements to clients
- Booking systems, ticketing tools and anything sending automated notifications
- Monitoring and alerting systems, which you only notice when an alert never arrives
Clients and devices
- Desktop mail clients on every machine, including any still on old versions
- Mobile profiles on phones and tablets, personal and company-owned
- Signatures, which are often held locally and lost in a profile rebuild
- Cached credentials and saved passwords that will keep retrying the old server
- Any mail rules users have built themselves, which do not always migrate
Before you pick a date
- 1Confirm nothing critical is happening that week, such as month-end or an audit
- 2Agree who is available on cutover night and the morning after
- 3Write the rollback plan and get it agreed
- 4Send staff the note explaining what changes and who to contact
- 5Verify the pre-sync has actually completed rather than assuming it has
IT Support
Want this run properly?
We work through this checklist as the audit phase of every migration, so the things that get forgotten are found before the cutover date is set.
Frequently asked questions
What gets forgotten most often?
Shared mailboxes and aliases, followed closely by applications that send mail through your domain. Printers, contact forms, accounting software and monitoring systems all keep pointing at the old platform and fail silently until someone notices an email that never arrived.
Why lower the MX TTL beforehand?
TTL controls how long DNS resolvers cache your mail routing. If it is left at a long value, some senders keep delivering to the old platform for hours after the cutover. Lowering it several days ahead means the switch propagates in minutes.
Do we need DMARC before migrating?
You need SPF and DKIM configured before cutover, without question. DMARC is strongly recommended and should start in monitor mode so you can see what is failing before you enforce anything. Enforcing DMARC on migration day is a good way to block your own mail.
What about our office printer?
Scan-to-email needs its SMTP settings updated to the new platform, and it is one of the most commonly missed items because nobody thinks of the printer as a mail client. It fails silently, and someone discovers it a week later when a scan never arrives.
How far ahead should we start?
Begin the inventory as soon as the decision is made. The audit typically takes a few days and often surfaces items requiring their own decisions, such as forwarding rules pointing at personal addresses. Pre-sync then runs in the background for as long as the data volume needs.
What will staff actually notice on cutover day?
Very little, if the order is right. Historic mail syncs across in the days before while the old system stays live, the MX TTL is lowered so the switch propagates in minutes, and a final sync plus the MX change happen in the evening. Next morning people sign in once to a reconfigured profile and their mail is there. Keep the old mailboxes live and receiving for an agreed period so stragglers are caught and rollback stays possible, watch for mailbox size limits that quietly stall a sync, and reconfigure phones, which otherwise keep pointing at the old server. Send staff a short note beforehand: most complaints come from not knowing what to expect.
