Moving Hosts Without Losing Email

Why migrations go wrong in a specific way

The website part is usually straightforward. Files copy, the database moves, the pages render.

What breaks is email, and it breaks for a structural reason: mail and web are directed by different records attached to the same domain.

Change where the domain points without carrying the mail records across, and mail is now directed at a server that has no mailboxes. Messages bounce or vanish, and nothing tells you.

The website looks perfect throughout, which is why the problem is usually found days later by somebody wondering why it has been quiet.

Before you touch anything

1. Write down every DNS record currently set, not just the ones you think matter.
2. Note where mail is handled, and whether it is moving too.
3. List every address in use, including ones only used by suppliers.
4. Check what else uses the domain, such as verification records for other services.
5. Take a full backup of the current site.
6. Confirm you can access the domain where the records are managed.

The first is the single most useful step. A photograph of the existing records takes a minute and is the reference you will want if anything goes wrong.

The fourth catches things people forget: records proving domain ownership to other services, which quietly stop working when removed.

Set up before you switch

The sequence that avoids downtime entirely.

Build the site fully on the new host while the old one is still live and serving visitors. Copy the files, restore the database, and configure everything.

Then test the new site before any visitor is sent to it. Most hosts provide a temporary address, or you can point your own computer at the new server without affecting anybody else.

Only when it is confirmed working do you change where the domain points. At that moment visitors move across to a site that has already been tested.

The alternative, switching first and fixing afterwards, is how migrations produce a day of errors.

The timing setting to change first

A small technical step with a large effect.

DNS records carry a value telling other computers how long to remember the answer. Typically that is hours, sometimes a day.

Lower it to a few minutes, a day or two before you migrate. Then when you make the change, it takes effect quickly rather than trickling out over a day.

Afterwards, once everything is confirmed, put it back up.

Without this, some visitors reach the old server and some the new for many hours, which is fine for a static site and a problem for anything taking form submissions or orders.

Keeping mail working

The heart of it.

If mail is staying where it is, the mail records must be recreated exactly on the new setup. Not approximately. Exactly, including the ones concerned with sending reputation.

If mail is moving too, do it as a separate exercise on a different day. Two migrations at once means that when something breaks you have twice as many places to look.

Either way, send a test message from outside to each address after the change, and reply to it. Delivery in both directions is what confirms it works.

The related argument for keeping mail somewhere separate permanently is in where your email should live.

A worked example

A wholesale supplier moving hosts to reduce cost.

The site moved on a Thursday and worked immediately. The mail records had been copied across, which the person doing it confirmed by checking that email still arrived.

What was not copied was a record used for sending authentication. Incoming mail was unaffected, so everything appeared fine.

Outgoing mail, however, began failing authentication checks at recipient servers. Their quotes started landing in junk folders, inconsistently, depending on the recipient's provider.

It took three weeks and several lost orders before somebody connected the two events, because nothing bounced and nothing was reported.

The record was recreated in ten minutes. The three weeks were caused by testing only incoming mail, which is the half people think of.

The fortnight afterwards

Do not cancel the old account on the day you switch.

Keep it running for two weeks. It costs one more month's fee and it means anything still reaching the old server, from a cached record or an unusual network, still finds a working site.

It also means that if something turns out to be broken, you have somewhere to go back to.

Use the fortnight to check the things that fail quietly: forms arriving, mail in both directions, the contact page, and anything scheduled that runs weekly rather than daily.

Who should do it

An honest assessment, since this is a job people attempt themselves.

Copying files and a database is within reach of a confident person with an afternoon. The part that goes wrong is DNS, and DNS is unforgiving in a specific way: mistakes are invisible from your own machine and obvious to everybody else.

If you have never edited a mail record, the migration is not the moment to learn. The cost of paying somebody for a few hours is small against a fortnight of quotes landing in junk folders.

The middle path, if the budget is tight, is doing the file and database work yourself and paying somebody for the hour of DNS changes and testing.

Whoever does it, insist the old account stays live for a fortnight. That single condition covers most of what can go wrong.

The checks nobody runs

Beyond confirming the homepage loads.

Submit the contact form from an outside address. Check every page that was in the sitemap still resolves. Confirm the certificate is present and valid on the new server. Check any redirects from previous addresses still work.

And look at your search visibility over the following month, because a migration that silently dropped redirects shows up as a slow decline rather than an error.

None of that takes long. All of it is easier to do in the fortnight when somebody is still paying attention than in the month when everybody has moved on.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.