The website migration checklist: moving hosts without downtime or data loss

Moving hosts sounds like the kind of thing that goes wrong — a site down for a weekend, a lost database, emails that stop arriving. Done properly it's almost invisible to visitors. The risk isn't the migration itself, it's skipping steps. Here's the checklist we run through on every migration, standard tier or not, so you know what "done properly" should actually look like.

Before the move

1. Full backup of everything — files, database, email accounts — taken and verified (not just triggered) before touching anything.
2. Inventory what depends on the old server. Cron jobs, API keys tied to an IP address, custom PHP or server versions, SSL certificates — anything that's easy to forget because it "just works" quietly in the background.
3. Lower your DNS TTL a day or two ahead of the move. A long TTL (time-to-live) means DNS changes take longer to propagate everywhere — dropping it to 300 seconds beforehand means the eventual cutover is fast once you're ready.

During the move

4. Copy to the new server without touching DNS yet. Get the site fully working on a temporary URL or the new server's IP/hosts-file override first.
5. Test on the new server before cutover — every page, the contact form, checkout if you have one, and email sending. Not just "does the homepage load."
6. Match PHP/database versions to what the site was actually built against, not just whatever's newest. A version jump is a separate project from a migration — don't let it happen by accident.
7. Re-issue SSL on the new server before cutover so HTTPS is ready the instant DNS points there.

After the cutover

8. Update DNS and monitor propagation — most visitors switch over within minutes with a low TTL, though it can take up to 48 hours to fully settle everywhere.
9. Keep the old host live and unchanged for at least a week as a fallback, don't cancel it the same day.
10. Re-check everything a second time once DNS has fully propagated: forms, email deliverability, sitemap and any redirects, and that search engines aren't seeing a different (staging) version of the site.

The step people skip most often is the second test — after cutover, not just before it. That's where DNS or email issues actually surface.

What "free migration" should include

When a host advertises free migration, ask specifically whether it covers email accounts, not just files and database — email is the part most often left out, and the part that causes the most disruption if it breaks. On our own hosting plans, standard migrations cover files, database and mailboxes as one free job; anything with multiple databases or unusual custom configuration is a flat £49 rather than a surprise on the invoice.

A reasonable timeline

For a typical small business site, expect the technical migration itself to take a few hours, plus up to 48 hours of DNS settling in the background — during which the old and new servers both serve the site correctly, so there's no visible downtime either way.