How to Migrate Business Email to a New Provider Without Losing Mail

The short answer: why mail gets lost and how to prevent it

Mail is lost during a migration for three reasons: an address was forgotten, the archive was not copied, or during the cutover some mail went to the old server after it had been shut down. A solid plan covers all three:

1. Inventory — what exactly is moving.
2. Prepare the new provider — mailboxes, aliases, DKIM.
3. Pre-copy the old mail.
4. Switch MX with a low TTL.
5. Final sync and a period when both servers run.
6. Clean up SPF and shut down the old mail.

Step 1. Inventory

Build a table of everything mail-related:

• staff mailboxes and their size;
• aliases and groups: info@, sales@, hr@ — who receives them;
• forwarding rules and auto-replies;
• shared mailboxes and delegated access;
• services that send mail as your domain: website, CRM, accounting, newsletters, scanners and printers;
• current DNS records: MX, SPF, DKIM, DMARC, autodiscover.

Forgotten aliases and services are the most common source of "missing" mail.

Step 2. Prepare the new provider

• Verify the domain with the new provider, but do not change MX yet.
• Create every mailbox, alias and group from your table.
• Generate the new provider's DKIM key and publish it in DNS. Providers usually use different selectors, so old and new keys can coexist.
• Add the new provider to SPF without removing the old one: v=spf1 include:<old> include:<new> ~all.

Step 3. Lower the TTL in advance

TTL sets how long DNS resolvers around the world cache a record. If your MX TTL is a day, some senders will keep delivering to the old server for a day after the switch.

Lower the MX TTL to a few minutes ahead of time — at least as far in advance as the current TTL. Then caches refresh quickly when you switch.

Step 4. Copy the old mail

There are two main approaches:

• Provider import tools. Google Workspace, Microsoft 365 and Yandex 360 all offer built-in IMAP migration. This is the easiest route for small teams.
• imapsync, a universal tool that copies folders and messages between two IMAP servers and, when re-run, transfers only what is new:

imapsync \
  --host1 imap.old-provider.com --user1 user@company.uz --passfile1 old.pass --ssl1 \
  --host2 imap.new-provider.com --user2 user@company.uz --passfile2 new.pass --ssl2

Keep passwords in files rather than on the command line, and delete them after the migration. Copy large mailboxes early — the first pass can take a long time.

Note that IMAP moves only messages. Contacts, calendars and filter rules must be migrated separately, by export or with the new provider's tools.

Step 5. Switch MX

• Pick a quiet time: an evening or a weekend.
• Replace the MX records with the new provider's and delete the old ones.
• Confirm the DNS answer has changed: nslookup -type=mx company.uz.
• Send test messages from external addresses to key mailboxes and aliases.

Step 6. Mail that arrives during the cutover

While caches refresh, some messages still reach the old server. So:

• do not shut down the old mailboxes for several days after the MX change;
• run a second sync (imapsync or a repeat import) to pick up the new messages;
• only then cancel the old subscription.

Step 7. Staff and final cleanup

Send staff a short guide in advance: the migration date, how to sign in to the new mail, the new IMAP/SMTP settings, whether an app password is needed and what to do about mail on their phones.

After the move:

• remove the old provider from SPF and delete its DKIM record;
• restore the TTL to its normal value;
• update SMTP settings on the website, CRM and other services;
• check DMARC reports for legitimate senders that fail authentication.