How to Move a Site Without Losing Your Email Accounts

To move hosting and keep email accounts, you have to separate the two jobs. The website is a set of files and a database that you copy to the new server, but the mailboxes are a separate system with their own storage and DNS records, and the site can be moved in an afternoon while the mail moves on a slower, more careful schedule. If you treat email as an afterthought and just repoint DNS on the day of the switch, you will lose messages, break aliases, and possibly drop mail into a black hole for a day or two.

The core problem is that DNS changes propagate, and during that window different senders will reach different mail servers depending on cached records. Any plan that assumes a single cutover moment is wrong. The plan that works is: copy the mail first, keep both mail systems live and reachable, then move the MX record, then watch the old server for stragglers, then retire it.

How to move hosting and keep email accounts: the order of operations

Do the website last. The mail migration determines your timeline because it depends on DNS propagation and on copying stored messages, and the site cutover is fast by comparison. A workable sequence is: inventory every mailbox, alias, forwarder, and catch-all rule on the old host; copy the mail store to the new host; verify the copy; lower the TTL on your mail-related records well in advance; switch MX; run both servers for a grace period; then move the web files.

The inventory step is where most migrations fail. Aliases and forwarders are configuration, not data, and they do not travel with an IMAP copy. Log into the old control panel and write down every address that is not a real mailbox: role addresses, distribution lists, forwarders pointing at personal accounts, and any catch-all. If you skip this, mail to sales@ will start bouncing the moment the old server stops answering.

Copying the mailboxes with IMAP

If your old host offers IMAP (most do), you can copy the entire store to the new server without touching the old one. The standard tool is imapsync, which logs into both servers and replays messages folder by folder. It preserves flags like read and unread, and it can be run repeatedly to pick up new mail that arrived during the copy.

imapsync \
  --host1 old.example.net --user1 [email protected] --ssl1 \
  --host2 new.example.net --user2 [email protected] --ssl2 \
  --delete2 --dry --justfolders

Run it first with --dry and --justfolders to list what it sees on both sides without writing anything. When the folder list looks right, drop those two flags and let it copy. Then run it again a few hours later, before the MX switch, so the gap between the copy and the cutover is small. After the switch, run it once more in the reverse direction if any mail landed on the old server after the last sync. For a single mailbox you can also use imapsync interactively, or fall back to a mail client that can drag folders between two accounts, but the command line tool is faster and repeatable.

If the old host does not offer IMAP, ask what export format it provides. Some give you a mailbox archive, some give you nothing and you have to pull mail through a client. Establish this before you commit to a new host, because a host without IMAP access makes migration painful.

Moving the MX record without dropping mail

Your MX records tell the world where to deliver mail. Before you change them, lower the TTL on those records to something short, such as a few minutes, and wait at least as long as the old TTL so caches expire. Then change the MX to point at the new server. Old senders with cached records will keep delivering to the old server for a while, which is exactly why you keep the old mail store alive and keep syncing it.

dig +short MX example.com
10 mail1.oldhost.example.
20 mail2.oldhost.example.

Check what the world sees with dig from a machine outside your network, not just from your laptop. After the change, the same query should return the new host's mail server. Keep the old server's mail service running for the full grace period, and keep your imapsync loop going so messages that arrive at the old server still end up in the new mailbox.

Two DNS details matter here. First, do not delete the old MX records until the grace period is over; if you do, cached senders get a lookup failure and may bounce. Second, set up SPF, DKIM, and DMARC on the new host before you switch, or your outgoing mail will start landing in spam. The SPF record is a TXT record listing the servers allowed to send for your domain, and it must name the new mail server, not the old one.

What to check when the dust settles

After the MX has been live for a while, send test messages from an outside account to each address: a real mailbox, an alias, a forwarder, and the catch-all if you have one. Confirm each one arrives in the right place. Check that the new mailbox has the old folders and that message counts roughly match. Then look at the old server's mail queue; if anything is still sitting there, it has not been delivered and you need to flush or forward it.

Only after mail is confirmed working should you move the website. Copy the files and database, test against the new server using a hosts file entry or a temporary subdomain, then switch the A and AAAA records. The web move does not affect mail as long as the MX records stay pointed at the new mail server.

Next, write down the inventory you built during this migration and keep it somewhere outside both hosts. Aliases, forwarders, and DNS records are the things people forget, and the next migration will be easier if you already have the list. If you are unsure about any step, run the copy tools in dry mode first and read the output before you change a single record.