Moving a website without downtime (or losing your email)

Moving hosts is one of those jobs that is either completely uneventful or a long, miserable day. The difference is almost entirely about sequence, and about one setting most people have never heard of.

First: are you sure?

Worth asking, because a fair number of migrations solve nothing.

If you are moving because the site is slow, measure before you move. Slow sites are far more often caused by heavy images, plugin bloat and unoptimised pages than by insufficient hardware. Move a slow site to a faster server and you get a slightly faster slow site, plus a migration you did not need.

Good reasons to move: the host is genuinely unreliable, support is poor, the platform is unmaintained (see what modern hosting means), the price has drifted well above market, or you have outgrown the tier.

The setting that changes everything: TTL

Every DNS record has a time-to-live — how long the rest of the internet caches the answer before asking again. Typically a day.

So if you switch hosts with a day-long TTL, some visitors keep landing on the old server for up to a day afterwards. If the old site is still running, they see stale content and any orders they place go to a database you are about to abandon. If it has been switched off, they see nothing.

The fix is simple and it is the whole trick:

1. At least 48 hours before, lower the TTL on the records you will change to 300 seconds.
2. Wait for the old TTL to expire, so caches worldwide pick up the short one.
3. Do the migration. Changes now take effect in about five minutes everywhere.
4. Put the TTL back to something sensible a day or two later.

That one step turns the riskiest part of a move into a non-event. There is more on how this works in DNS explained.

The order of operations

1. Lower the TTL. As above, 48 hours ahead.
2. Take a full backup of the old site — files and database — and download it somewhere that is not either host.
3. Set the new site up completely and test it on a temporary address before changing anything public. Every page, the forms, the checkout.
4. Copy the DNS records exactly if you are also changing DNS provider. Every single one, especially MX.
5. Freeze content changes. Anything published after the backup and before the switch is lost. Tell whoever edits the site.
6. Switch the DNS.
7. Watch for an hour. Load the site, submit a form, place a test order, send yourself an email.
8. Keep the old host for a fortnight. Cancelling immediately to save one month is how people lose the ability to roll back.

The mistake that takes email down

This is the one that causes the most damage, and it catches people who did everything else right.

If you change nameservers, you move all your DNS — not just the website. The new provider starts with a blank zone. If your MX records were at the old provider and you did not copy them across, your email stops the moment the switch takes effect. Not bounces you can see. Silence.

Two ways to avoid it. Either copy every record to the new provider before switching nameservers, or leave DNS where it is and change only the A or CNAME record pointing at the website. The second is usually simpler and is what we would normally do.

Things people forget

• The SSL certificate. Set it up on the new host before switching, or visitors get a security warning at the worst possible moment.
• Redirects. If URLs change, every old one needs a 301 to its new home. Skip this and you will watch your search traffic fall for a month.
• Cron jobs and scheduled tasks. Backups, feeds, reports — they do not come with the files.
• Form destinations. Test that enquiries actually arrive. Silently broken contact forms are the most expensive migration bug, because nothing looks wrong.
• Search Console. If the domain changes as well as the host, use the Change of Address tool and resubmit the sitemap.
• Anything hardcoded. Old absolute URLs in the database, integrations pointing at the old server, an app calling an API by IP address.

When to do it

Your quietest hours, with a clear day afterwards. Not on a Friday — not because Friday is unlucky, but because the problems that surface on Saturday are problems nobody is around to fix. For most UK small businesses that means a Tuesday or Wednesday morning.

The rollback plan

Have one before you start, in writing. With a short TTL and the old host still running, rolling back is one DNS change and about five minutes. Without either, it is a rebuild.

Most migrations go fine. The ones that do not are almost always missing exactly these two safety nets.

We migrate sites as part of a build and as a standalone job, and we will tell you honestly if the move will not fix what you are trying to fix — book a free call. See also types of hosting compared.