Business Email Migration: Inventory, MX Cutover, and Cutover Window Design

Business Email Migration: Inventory, MX Cutover, and Cutover Window Design

The technical work in a mailbox migration is small: change a few DNS records, provision a batch of accounts, move a batch of data. What makes it stressful is the one irreversible action inside that list, the MX change. Before it, the old system is the only truth. After it, the new system is the only truth, and there is no parallel safety net in between.

What makes it worse is the shape of failure. A migration rarely breaks as nobody receives any mail. It breaks as some address receives nothing: a role address, a subdomain, an application address that exists only to receive replies from a third-party system. Nobody checks those daily, failure produces no error, and the problem surfaces at month-end reconciliation or when a customer complains, two weeks later.

The core of a migration is therefore not tool selection but two things: inventorying every address and asset before touching anything, and designing a rollback path into the moment of the change. The first determines the incident rate; the second determines how long an incident lasts.

The sections below follow the seven-step order, then work through the inventory checklist, the two paths for data migration, cutover window design, the verification checklist, common incidents, and the cutover day timeline. For the authentication records themselves, see SPF, DKIM, and DMARC configuration; for comparison dimensions when choosing a service, see business email service selection.

1. The Risk Is Not Technical, It Is the Irreversible Step

1.1 The MX Change Is the Irreversible Step

The MX record decides which server receives mail, and inside DNS it is the only authority on that question. Once changed, new mail from the outside world goes only to the new provider. The old system does not receive a copy, and that is not a configuration detail but the protocol model: a sending MTA picks one target according to MX priority.

Every preparatory task in a migration exists to make sure that at the moment of the MX change, the new system can already receive everything: accounts exist, addresses exist, aliases and groups exist, authentication records are in place, filtering policy is set, and clients can connect.

1.2 The Seven-Step Order

Get the order wrong and you get incidents such as an MX cutover that happens before the aliases exist. The correct order is:

1. Inventory: list every address, alias, group, subdomain, and non-mail asset.
2. Provision: create accounts, aliases, groups, shared mailboxes, and resource calendars in the new system. For how plan granularity maps to account types, see the enterprise email plan comparison.
3. Export archives: pull historical mail out of the old system as a fallback backup.
4. Pre-cutover validation: verify sending, receiving, and authentication without changing MX, using a test domain or a direct connection to the new server.
5. Change MX: execute in a low-traffic window with rollback ready.
6. Observation: the old system receives but does not send, with catch-all forwarding, while delivery and sign-in are watched on the new system.
7. Decommission: stop the old service and clean up DNS and credentials once nothing is missing.

Skip any step and it shows up that night as one address that receives nothing.

2. The Inventory Checklist

2.1 Inventory Down to the Non-Human Addresses

Human mailboxes are the easy part, because someone is using them. What gets missed are the addresses that are not people.

• Aliases: zhangsan@ and zhang.san@ reaching the same person, where alias mechanics differ across systems and one missing entry means one person loses mail.
• Groups and department addresses: all@, sales@, tech@, usually distribution lists whose membership has to be rebuilt.
• Role addresses: hr@, support@, billing@, info@, legal@. These are printed on contracts, websites, and invoices, and missing one means every inbound message bounces.
• Application addresses: monitoring alerts, printer and scanner SMTP senders, third-party reply addresses, reconciliation notices. These hide best because nobody reads them while the business depends on them.
• Mailing lists: list addresses and admin addresses for self-hosted list managers, plus subscriber data.
• Shared mailboxes and delegation: support@ handled by three people, with permissions and delegation to rebuild.
• Rooms and resources: meeting room mailboxes and equipment calendars, often dismissed as unimportant while booking workflows depend on them.
• Departed employees: decide whether to keep forwarding or deactivate entirely, and make that decision before the migration.

The output should be one table: address, type, owner, purpose, and disposition (provision, alias, group, forward, deactivate). That table is the only basis for checking the result after cutover.

2.2 Subdomains Are the Easiest to Miss

This is missed almost every time. The primary domain MX is updated while mail., notice., and news. still point at the old provider. After the cutover those subdomains quietly stop working. No error, nobody receives, and they are often exactly the names used for system notifications and outbound transactional mail.

The correct approach is to list every subdomain MX and SPF record during inventory and decide per subdomain whether it still needs to receive. If it only sends, delete its MX or point it at a blackhole and publish a TXT record explaining its purpose, so it cannot be treated as a deliverable domain and flooded with spam. If it does receive, it has to be cut over at the same time.

Check subdomain SPF and DKIM in the same pass. After migration the new provider sending IPs must be added to every SPF record, which is the other classic omission covered in the verification checklist below.

2.3 Assets That Do Not Travel With Mail

Migration tools move mail. An enterprise mailbox also holds a great deal that is not mail, and those items need their own migration list:

• Calendars, shared calendars, and the history of meeting invitations.
• Contacts, the global address list, and personal address books.
• Signatures, including their image assets.
• Mail rules and filters, especially server-side rules, as covered in section six.
• Auto-replies and out-of-office settings.
• Shared folders with permissions, and public folders.
• Aliases and forwarding relationships.
• Domain verification records: SPF, DKIM, DMARC, and the various verification CNAME and TXT entries.
• Client settings: IMAP and SMTP hostnames, ports, encryption, and app-specific passwords.

Put them on the list with an owner each. It costs far less than discovering after cutover that the rules are gone and the signatures too.

3. Two Paths for Data Migration

3.1 Server-Side IMAP Sync

IMAP sync has the new system connect to the old one over IMAP and pull mailbox contents across. Its advantage is structural fidelity: folder hierarchy, read and unread state, flags, and timestamps all survive, so users experience a move rather than a pile of mail dumped into the inbox.

Its boundary has to be stated clearly. IMAP sync preserves what is inside the mailbox and nothing about permissions or rules. Shared mailbox delegation, server-side filters, out-of-office settings, and shared calendar permissions do not come across. The old system also has to remain readable during the process, so this step has to be scheduled before the MX change.

Two practical notes on tooling: it must support incremental sync and resume, because a full re-run is expensive in time, and a final incremental pass should run just before the cutover to shrink the delta to almost nothing.

3.2 PST and MBOX Export

Export and import suits two situations: an old system without IMAP support, or a requirement for an offline compliance archive. Its advantages are completeness and control, since the exported file is itself a backup. Its weakness is structural degradation: folders may be flattened, flags lost, and duplicates increased.

In practice the two paths are often combined: IMAP sync for day-to-day usability and an exported PST or MBOX as an archive copy. Set the archive retention period against compliance requirements, encrypt the archive at rest, and restrict access, because it holds the entire correspondence history.

4. Cutover Window Design

4.1 Drop the TTL in Advance

The DNS TTL determines how long the world keeps using the old value after a change. If the MX TTL is 86400 seconds, then after the change it can take a full day for everyone to see the new record, and during that time some senders still deliver to the old system.

The standard action is to lower the MX TTL to 300 seconds at least one old-TTL period before the cutover, so caches expire naturally. After the cutover, observe for a while and then restore a normal value such as 3600 seconds. This step is often skipped precisely because it belongs a week before, not on the day.

Mind the minimum TTL floors that recursive resolvers apply. Some raise very low values to their own minimum, so 300 seconds is a working practice rather than a guarantee.

4.2 The Old System Receives but Does Not Send

After the MX change new mail arrives at the new system, but the old system may still hold unread messages being pulled by clients, and any mail addressed to an address that was not migrated still lands there. At this stage the old system should receive but not send: MX no longer points at it, IP-level delivery may still work if the provider allows it, and everything arriving is forwarded by catch-all to the matching address on the new system.

Catch-all forwarding is the insurance policy for this phase. As long as the old system still receives, any missed address gets a second chance at delivery. The cost is that forwarding rewrites the envelope and breaks SPF alignment on the forwarded copy, so log those messages as forwarded and reconcile within a week to see who is still writing to old addresses.

4.3 There Is No Bidirectional Receiving

A domain can have only one MX target receiving at any moment. Parallel operation in the sense of both sides receiving half the mail is not implementable, because the protocol does not work that way.

That matters because many migration plans draw a diagram that implies dual active receiving. The only real parallelism is one system as a front receiver forwarding everything onward, or the inverse where the new system receives and forwards specific addresses back. The first is the recommended migration form; the second is only for a department on a delayed schedule, and it needs an explicit exit date.

5. Verification Checklist

5.1 Sending, Receiving, and Authentication

On the first day after cutover, verify in this order and have someone sign off on each line:

• Internal to internal: two accounts on the same domain exchange mail, confirming delivery into the inbox.
• External to internal: send from an external mailbox to hr@, support@, and an ordinary account, confirming arrival on all three.
• Internal to external: send out from the new system and confirm the sender and reply-to addresses look right at the recipient.
• Authentication: send to an address that reports authentication results and confirm spf=pass, dkim=pass, and dmarc=pass.
• Attachments and size limits: send an attachment near the limit and confirm policy behaves as expected.
• Mobile and desktop clients: confirm the IMAP and SMTP hostnames and ports work against the new system.

5.2 SPF, DKIM Collisions, and Blocklists

SPF is the single most commonly forgotten item. The new provider sending IPs must be included in the SPF record, or a large share of outbound mail lands in spam on SPF failure. Confirm three things at once: the domain publishes exactly one v=spf1 record, the new provider is included or listed as ip4, and the terminating all mechanism matches the current stage, with ~all common during migration.

The DKIM trap is selector collision. If old and new providers happen to use the same selector name while the old record is still published, verification fails. Publish the new selector public key, switch sending, confirm success, and only then delete the old record. The reverse order does not work.

During migration DMARC is for monitoring rather than blocking. Watch rua aggregate reports for two weeks on either side of the change and look for sending sources that unexpectedly pass or unexpectedly fail. Blocklist checks should cover the new provider sending IPs and domains, since some shared pools are already listed somewhere and that has to be known before volume ramps.

5.3 Client and Mobile Reconfiguration

A large part of the user experience lives in the client. After cutover, what has to be updated includes IMAP, POP3, and SMTP hostnames, ports, and encryption; whether OAuth2 or app-specific passwords are used; mobile mail profiles on iOS and Android; and the local cache policy on desktop clients, meaning how long mail and attachments are kept.

The lowest-friction approach is a setup wizard page plus a copyable parameter table, with an advance notice asking users not to change passwords inside the window, to avoid lockouts. Where OAuth2 is used, confirm that the identity provider token scopes are compatible with the mail system. For how to fill in hostnames, ports, and encryption, see the SMTP configuration guide.

6. Three Common Incidents

6.1 Forgetting SPF

This is the most frequent failure of all. It presents as internal mail working fine while outbound mail lands wholesale in spam, because the new provider IPs are absent from SPF. It is common because the person changing MX and the person managing DNS are usually different people, and SPF is not prominent on the migration checklist.

Prevention is simple: put a DNS record review into the cutover checklist and tick off MX, SPF, DKIM, DMARC, autodiscover, and the various verification CNAME and TXT entries line by line.

6.2 Lost Aliases Starving Business Mail

Aliases are the classic silent failure. info@ and sales@ are aliases, they were not created on the new system, inbound mail bounces outright, and internally nobody knows those addresses should exist. It surfaces at contract renewal or on a customer complaint, by which point a batch of correspondence is gone.

Prevention is to list every alias in the inventory table and run an address liveness check after cutover: a script sends one probe message to each address and confirms it reaches the expected mailbox. When a probe bounces, the bounce code is the best diagnostic available, and the classification conventions are covered in email bounce reason analysis.

6.3 Rules and Forwarding Left Behind

Server-side filters, automatic forwarding, and vacation replies do not travel over IMAP. Missing them produces two kinds of trouble. One is everything that used to be sorted automatically now flooding the inbox. The other is worse: a rule forwarding a departed employee mailbox to their successor stops working and customer mail goes unanswered.

Prevention is to export every account rules and forwarding configuration during inventory, rebuild each one on the new system, and review every rule that forwards to an external address on its own. Such rules may be historical leftovers or a security risk, as covered in the backdoor review in email security gateways and phishing defense.

7. Cutover Day Timeline

7.1 T Minus 7 to T Plus 7

7.2 Rollback Criteria

Rollback is not failure, it is part of the design. Define three criteria in advance and roll back if any one is met: the new system shows broad delivery failure, measured for example by an unacceptable share of bounces at recipients or long queue times; the authentication chain cannot be fixed inside the window, such as an SPF or DKIM collision with no short-term resolution; or key role addresses cannot receive external mail.

The rollback actions themselves need rehearsal too: restore the previous MX values, which take effect quickly because the TTL was lowered; restore receive permission on the old system; and bring mail received during the window on the new system back through forwarding or export. A rollback that has never been rehearsed tends to be slower than the incident itself.

The conclusion compresses to one sentence: success depends on two things that are not in the tooling, whether the inventory is exhaustive down to subdomains and non-human addresses, and whether the window is designed to be reversible; the technical actions number seven, and skipping any one of them turns into one person who receives nothing that night. For splitting sending domains after the migration, see transactional and marketing email separation; for automating inbound receiving, see inbound email processing automation.

Source: 16IDC original. Protocol specifications, platform behavior, and compliance criteria follow the relevant IETF RFCs, regulatory requirements, and provider documentation.