How to Migrate a Company's Email to a New Host (Cutover Plan)

Here is how to migrate a company's email to a new provider without losing mail: copy the mailboxes first, move the MX records second, and re-sync the gap in between. Every serious migration failure comes from doing those in the wrong order, or from treating the MX change as the migration rather than as one ten-minute step inside it.

This is the domain-level version — a runbook for an admin moving a whole team. It assumes you control DNS for the domain and have admin access at both hosts. Reserve two to three weeks, most of which is waiting rather than working.

What actually moves, and what doesn't#

A migration tool moves messages. It does not move most of the things that make a mailbox feel like the user's mailbox, and that mismatch is where the complaints come from on day two.

IMAP-based migration — which is what Google's and Microsoft's own tools use underneath — copies messages, folder structure, and read/unread state. Anything that is not an RFC 5322 message in a folder is out of scope.

• Moves reliably: messages, folders, attachments, read and unread flags, and in most tools the sent and archive folders.
• Moves only with a separate tool or export: calendars, contacts, shared calendars, and room or resource bookings.
• Does not move at all: filters and rules, signatures, vacation responders, delegation grants, mailbox permissions, app passwords, and per-user settings.
• Has to be rebuilt by hand: distribution lists, aliases, catch-all routing, and any shared mailbox membership.

The pre-migration checklist#

Do all of this before you touch a single DNS record. The checklist below is the whole project; the cutover itself is the shortest part of it.

• Inventory every address on the domain — user mailboxes, aliases, distribution lists, catch-all, and the ones nobody remembers like billing@, noreply@ and the scanner in the copy room.
• Inventory every system that sends as your domain: CRM, helpdesk, invoicing, monitoring alerts, marketing platform, application SMTP relays, and multi-function printers.
• Record current DNS exactly as it stands: MX, SPF, DKIM selectors, DMARC, autodiscover, and any SRV records. Screenshot it. You will want the original when something looks wrong at 2am.
• Lower the MX record TTL to 300 seconds, at least one full old-TTL period before cutover day.
• Size the data: total mailbox count and gigabytes. IMAP sync throughput, not your connection, is the limit, and a 50 GB mailbox can take days.
• Agree a quiet window with the business — typically Friday evening or a Saturday morning in your busiest timezone.
• Tell people. Users need to know the date and that they will re-enter credentials; external partners generally do not, because the address does not change.

The cutover plan, step by step#

This is the order that keeps mail flowing. Steps 1 to 5 are reversible at zero cost; the risk starts at step 6.

1. 1

   1. Provision users at the new host

   Create every mailbox, group, alias and shared mailbox with the same local part as the old host. Do not point DNS anywhere yet — the new host will happily hold verified mailboxes that receive nothing.

2. 2

   2. Verify the domain and publish DKIM

   Complete the new host's domain verification (usually a TXT record), generate DKIM keys and publish the selectors. Add the new host to your SPF record alongside the old one. Publishing both is correct during a migration, not a mistake.

3. 3

   3. Run the full mailbox sync

   Start the bulk IMAP copy with admin credentials or OAuth, whichever the new host supports. This runs for hours or days. Mail is still being delivered to the old host throughout, which is exactly what you want.

4. 4

   4. Pilot with three or four mailboxes

   Pick an admin, a heavy user, and someone with a deep folder tree. Have them log in at the new host and check folder structure, search, attachments, and their mobile client. Fix what they find before the other mailboxes matter.

5. 5

   5. Rebuild what the sync did not move

   Rules, signatures, vacation responders, delegation, mailbox permissions, and calendar sharing. Reconfigure every application that sends through SMTP with the new host's relay, but do not switch them over yet.

6. 6

   6. Cut MX in the quiet window

   Replace the MX records with the new host's. With a 300-second TTL, most resolvers follow within five to fifteen minutes; a long tail of badly behaved ones can take an hour or two. Leave the old mailboxes live and accepting mail.

7. 7

   7. Turn on dual delivery for the tail

   Configure the old host to forward everything it still receives to the new host. This catches the mail that arrives from senders whose resolver is still on the old MX answer, and it is the single step that keeps outsiders from noticing the migration at all.

8. 8

   8. Run the delta sync

   Re-run the migration tool in incremental mode. It copies only what landed in the old mailboxes after the full sync started — usually a few hundred messages per user. Run it once immediately after cutover and again 24 hours later.

9. 9

   9. Monitor bounces and authentication for 72 hours

   Watch the new host's inbound logs for 550 5.1.1 unknown-recipient rejections, which mean an address exists on the old host and was never recreated. Watch DMARC aggregate reports for any sending system still failing SPF or DKIM.

10. 10

    10. Switch application senders, then decommission

    Move each application's SMTP relay one at a time and confirm delivery. Only once nothing has used the old host for 30 days do you remove its SPF include, take a final export, and cancel the service.

What breaks when you change email providers#

None of the items below are exotic. Each one has taken down a real migration, and each one is cheap to handle if it is on the list before cutover day.

Why the parallel-run window is the whole trick#

For a period after the MX change, some senders deliver to the old host and some to the new one. That period is not a failure state — it is the design. Both hosts accept mail, the old one forwards what it gets, and the delta sync reconciles the two copies afterwards.

The mistake is closing that window early. An admin who disables the old mailboxes the moment DNS updates is choosing to bounce every message from a resolver that has not refreshed yet.

The rollback plan#

Write this down before cutover day and give it to whoever is holding the pager. A rollback is fast only if nobody has to think.

Because you never stopped the old host, rollback is a single action: republish the original MX records. With a 300-second TTL, inbound mail returns to the old host within minutes, and the old mailboxes still hold every message they ever received.

• Trigger to roll back: sustained inbound rejections at the new host, or authentication failures affecting a whole department rather than one user.
• Not a trigger: individual users who cannot log in, or mail that is merely slow. Those are support tickets, not incidents.
• The one-way door: mail that arrived only at the new host after cutover is not in the old mailboxes. Export it before you roll back, or accept the gap.
• Do not delete anything at the old host — mailboxes, aliases, or DNS records — until the 30-day decommission step.

How do I migrate 20 mailboxes without downtime?#

Twenty mailboxes is comfortably inside the range where one admin can run the whole thing over a weekend, provided the preparation happened during the preceding week. The plan does not change with scale; only the sync duration and the pilot group do.

A realistic timeline for 20 mailboxes: Monday, inventory and TTL reduction. Tuesday to Thursday, provision users and run the full sync. Friday, pilot and rebuild settings. Friday evening, cut MX and enable dual delivery. Saturday, delta sync and bounce monitoring. The following month, decommission.

Downtime, properly defined, means senders receiving a bounce. Users re-entering a password on their phone is disruption, not downtime. Schedule it, communicate it, and do not let it drive the technical plan.

Where a mail client fits after the move#

Once the mail is at the new host, the client your team reads it in is a separate decision — and it is the one that decides whether the migration feels like an upgrade or just a change of scenery. AI Emaily is one option there. We build it, so treat this as the interested paragraph it is.

To be clear about what we are not: AI Emaily is not a mail host and does not perform migrations. It connects over Gmail, Outlook and standard IMAP to wherever the mail ended up. What it adds is the layer above the mailbox — triage, drafting from a Personal Context brain and per-client profiles you set yourself, and Copilot mode where nothing sends without your approval, with undo and an audit trail behind every action. If a migration has already given you a week of reading every message twice, that is the part worth shortening. There is a 7-day free trial on Pro and Autopilot.