How to move a website to new hosting without downtime

Moving a site to new hosting is routine. It goes wrong in predictable ways, and almost all of them come from changing the DNS before the new server is genuinely ready.

The principle is simple: the switch should be the last thing you do, and by then it should be boring.

Lower your TTL first — days before, not on the day

Every DNS record carries a TTL: how long resolvers cache it. If yours is 86400 seconds, a change can take a full day to reach everyone, and if something is wrong you are stuck with it for another day while you roll back.

Drop the TTL on your A and CNAME records to 300 seconds at least 24–48 hours before the move. Every resolver then holds the old value briefly, so when you finally switch, the change propagates in minutes and a rollback is equally fast.

This single step is the difference between a five-minute mistake and a day-long outage, and it costs nothing.

Build the new site completely before touching DNS

Copy files and database to the new host and get it fully working there while the live site continues serving from the old one.

Test it by pointing your own machine at the new server with a hosts file entry. Your browser resolves the real domain to the new IP while the rest of the world stays on the old host — so you can click through the real site, log in, submit a form and check checkout, all before anyone else is affected.

Things worth checking at this stage:

• Every page loads, not just the homepage
• Forms actually submit and deliver
• Logins work and sessions persist
• Images and uploads resolve — broken paths are the most common migration bug
• Hard-coded absolute URLs pointing at the old host or a staging domain
• Scheduled tasks and cron jobs run
• PHP version and extensions match what the site expects

Email is where migrations actually break

This is the one that catches people, and it has nothing to do with the website.

If your email runs on the same domain, your MX records may be managed by the old host. Move the domain or change nameservers carelessly and mail stops — and unlike a website outage, you often will not notice, because nothing appears broken. Messages sent during that window may bounce and never arrive.

Before you change anything, record every DNS record: A, CNAME, MX, TXT (SPF, DKIM, DMARC), and any verification records for services like Search Console. Recreate them on the new provider before switching nameservers, not after.

Losing an SPF or DKIM record does not stop mail outright — it quietly sends it to spam, which takes far longer to diagnose.

Sort SSL before the switch, not after

A certificate cannot usually be issued for a domain until it points at the server requesting it, which creates a short window where the site is live on the new host without HTTPS. Visitors see a browser warning, which is worse than an outage because it looks like a compromise.

Minimise it: have the new host ready to issue a certificate the moment DNS resolves, switch during a quiet period, and confirm HTTPS works before announcing anything. Then check that HTTP still redirects to HTTPS and that mixed-content warnings have not appeared.

The order that works

1. Lower DNS TTL to 300 seconds. Wait for the old TTL to expire.
2. Record every existing DNS record, including MX and TXT.
3. Copy files and database to the new host.
4. Recreate email and verification records on the new provider.
5. Test thoroughly using a hosts file entry.
6. Switch DNS during a quiet period.
7. Confirm SSL, then confirm mail delivery in both directions.
8. Keep the old hosting running for at least a week.
9. Restore the TTL to a normal value once everything is stable.

Do not cancel the old host immediately

Keep it running for a week or two. Stragglers will still resolve to it briefly, and if something was missed you have somewhere to check. Cancelling on the same day turns a small oversight into unrecoverable data loss.

Take a full backup of files and database before you start, and keep it somewhere that is not either host.

What to watch afterwards

For the first week, keep an eye on Search Console for crawl errors and server response failures — a migration that breaks a redirect rule can quietly remove pages from the index. Check that your sitemap still resolves, that HTTPS is canonical, and that no staging URLs escaped into the live site.

Send a test email to and from a domain address, and check it does not land in spam. If SPF, DKIM or DMARC did not survive the move, that is where it shows.

How we handle it

We treat migrations as a sequence with a rollback at every stage, and we do the DNS audit before touching anything — because the record that breaks a business is almost never the one for the website.

Our domain and hosting service covers registration and transfers, hosting setup on any provider, DNS and SSL, business email, and migrations without downtime — with everything registered in your name rather than ours. If the site itself also needs rebuilding, our web development service handles that in the same engagement.

Planning a move? Tell us what you are running and where and we will map out the sequence.