Planning a zero-downtime mailbox migration

"Zero downtime" is worth defining before promising it. It means no user-visible interruption to sending or receiving, and no message lost or bounced in transition. It does not mean no work, no change in behaviour and no evening spent watching a queue drain. Anyone offering the second thing is selling something else.

Discovery is most of the project

The single strongest predictor of a bad cutover is an incomplete inventory. Mailbox counts are easy; what causes trouble is everything attached to them. Enumerate, explicitly, before designing anything:

• Shared mailboxes, delegates and send-as permissions. These reliably break, because the permission model rarely maps one-to-one.
• Resource and room mailboxes, and any booking automation attached to them.
• Distribution groups, including nested ones and the three whose owner left in 2021.
• Server-side rules and forwards, particularly external forwards — a migration problem and often a security finding.
• Public folders, if they exist. Always worse than reported.
• Anything that relays through the mail server. The scanner on the second floor, the ERP sending order confirmations, the backup software emailing a nightly report, the door-entry system. This list is never complete on the first pass.
• Mailbox sizes and item counts, not just totals. One 180 GB mailbox with 900,000 items behaves nothing like ninety 2 GB mailboxes.
• Client mix. Which clients, at which versions, and whether any are hard-coded to a server name.

Pre-seeding, and why the delta pass matters

Content moves before the cutover, not during it. A bulk synchronisation pass copies historical mail into the target while users keep working in the source. Depending on volume and throttling this takes days to weeks.

Then delta passes run repeatedly, each copying only what has changed. By the night of the cutover the final delta should be minutes of work rather than hours. If your plan involves a large synchronisation happening during the change window, you do not have a zero-downtime migration; you have a long outage with optimism attached.

Expect throttling. Every platform rate-limits migration traffic and the published limits are frequently not the effective ones, so measure achieved throughput during the first week and re-plan against the measured number rather than the vendor's.

DNS mechanics

Lower the TTL on the MX records at least 48 hours before cutover — down to 300 seconds — so that the change propagates in minutes rather than being cached for a day by a resolver somewhere you cannot reach. Raise it again a week afterwards.

The critical property during the switch is that both systems must accept mail. Some senders will resolve the old MX for hours afterwards, so the old platform stays live and relays onward until that traffic stops. Turning off the source as you change the MX is the classic way to lose a day of inbound mail.

Do not change SPF, DKIM or DMARC in the same window as the MX. Publish the new platform's sending sources in advance, so both old and new are authorised during coexistence, and remove the old entries only after decommissioning. A migration that also breaks authentication produces a deliverability incident on top of a migration incident, and the two will be difficult to tell apart.

Autodiscover deserves its own line in the runbook: a stale record will keep pointing a fleet of desktops at a platform they no longer have mailboxes on.

Coexistence

Unless the organisation is small enough to move in one night, some period will exist where mailboxes live on both platforms. During that window, internal mail must route correctly between them and calendar free/busy must resolve across the boundary.

Free/busy is the item most often descoped in planning and most often escalated afterwards, because the first thing a manager does on the Monday after a partial migration is try to book a meeting with somebody who has not moved yet. Test it explicitly, in both directions, before the first user batch. Batch users by working group rather than alphabetically, so that people who meet daily move together.

The night itself

A good cutover runbook is boring, with a named owner per step, an expected duration, a verification and a decision point. Ours reads: final delta pass, verify item counts, change MX, verify inbound to a test address at the new platform, verify outbound, confirm the old platform is relaying onward, then stop. Write down the previous configuration values before changing them — at two in the morning nobody remembers what the MX priority was.

The week after

Clients need reconfiguration and, on some desktop clients, a local cache rebuild that will saturate the office connection if a hundred people do it at once. Stagger it. Then work the sending sources from the register — the scanner, the ERP, the backup reporter — one at a time, verifying each after it moves. This is the phase that overruns, because each is a small unowned system belonging to a department that does not know it sends mail.

Decommissioning

Keep the source platform running, receiving and relaying, for at least four weeks. It costs little and it is the only real backout you have. Before switching it off: confirm no mail has arrived for a fortnight, confirm the archive captured continuously across the cutover, and take a final export.

A migration is not finished when the mailboxes move. It is finished when the old system is off and nobody has noticed for a month.