How to Move Hosting Without Downtime

Migrations get a reputation for being dangerous, and the danger is real but it is not spread evenly across the process. Almost all of it sits in one moment: the window between the old host stopping and the new host working.

That window does not have to exist. If you sequence the work correctly, the switch is a DNS change measured in seconds, and every hard part happens while the old site is still serving traffic.

The rule behind the whole process

Nothing destructive happens until both environments are fully working at the same time.

You will be running two copies of the same site for a few hours, on two different hosts. That is not waste — that is the mechanism. The old copy stays live and correct while the new copy is assembled and tested. When the new one is verified, you point traffic at it.

Everything below is a consequence of that one idea.

Step 1 — Lower the TTL, a day in advance

This is the only step that must happen early, and skipping it is what turns a five-minute switch into an eight-hour one.

A DNS record’s TTL tells resolvers and caches how long to remember the answer. If your A record has a TTL of 3600 seconds, then when you change it, some visitors keep being sent to the old host for up to an hour. There is no way to recall that instruction once it is out.

So change the TTL — not the record, just the TTL — to its lowest setting at least 24 hours before you plan to migrate. On Cloudflare this is 1 minute; elsewhere, whatever the minimum is.

After the migration is complete and verified, raise it back. While you are waiting, do nothing else in DNS.

Step 2 — Build the new environment completely

Set up the new host, deploy the site, and get it responding on a temporary address — the host’s own URL, or your machine with a hosts-file entry pointing the domain at the new IP.

Then test it properly, at that temporary address:

• Pages load, and the ones that matter most load fastest
• Forms submit and notifications arrive
• HTTPS is valid, with no mixed-content warnings
• Redirects behave, including the ones you forgot you had
• Any integration that talks to the outside world still works: payment, email sending, analytics, the CDN

Do not test this through the real domain yet. That is the whole point of staging it.

Step 3 — Move the data, twice

Static sites have no data problem. The build output is the site; copy it and you are done. The two copies are byte-identical and there is nothing to reconcile.

Sites with a database need two passes. Copy the database and files once, early, to get everything in place and tested. Then, shortly before you switch, copy again — only what has changed since the first pass — so the new copy is current. For most sites the gap between the second copy and the DNS switch is a few minutes of comments or orders, which you can either accept or handle by briefly putting the old site into read-only mode.

Do not try to make this a single perfect copy. Two passes with a short gap is simpler and safer than one clever one.

Step 4 — Do not touch the MX records

The most common self-inflicted outage in a migration has nothing to do with the website.

Email is delivered according to MX records. If your email is not hosted on the same machine as your website — and for most people it is not, since the site is on a host and the mail is on Zoho, Google or a forwarding service — then migrating the website is not an email migration and the MX records should not change at all.

People get into trouble by copying an entire DNS zone from a template, or by “cleaning up” records during the move, and silently dropping or repointing MX in the process. If email matters to you, screenshot the MX records before you start, and compare them after.

The same goes for verification records: Search Console, DKIM, SPF, DMARC, and any third-party verification TXT records. None of them should be touched by a hosting move.

Step 5 — Switch, then verify in this order

Change the A or CNAME record to the new host. Then check, in this order, because each step can mask the one below it:

1. Resolution. Does the domain now point at the new address? Check from a network you have not used recently, or a mobile connection, so you are not reading a stale cache.
2. TLS. Does the certificate on the new host cover the domain? A certificate issued before you owned that hostname is a common failure and produces a browser warning rather than an error page.
3. Home page. Does it return 200 and look right?
4. Deeper pages. Spot-check a few, including one that redirects.
5. Anything stateful. Log in, submit a form, place a test order — whichever applies.
6. Email. Send and receive one message. This is the check people skip, because they assume mail is unrelated. It is unrelated — which is exactly why it is worth confirming nothing changed.

If something is wrong, you can roll the DNS record back to the old host. That is why the TTL was lowered first: the rollback is as fast as the switch, and the old host is still running because you have not decommissioned it yet.

Step 6 — After the switch

• Raise the TTL back to normal once you are satisfied.
• Resubmit your sitemap if the URLs are unchanged; nothing should need reindexing, but confirming it is cheap.
• Watch the error log for 404s for a week. Migrations surface assets and pages that existed only on the old host.
• Keep the old host running for a few days, ideally a week. Its entire cost is a few days of hosting, and it is your rollback.
• Cancel the old account last, after the billing period you have already paid for ends.

When not to do it yourself

Almost all of the complexity above comes from databases and email. If your site is static, or if the move is between providers of the same managed platform, this is a genuinely small job.

If you are moving a busy store with customers, sessions, integrations and revenue attached, the calculation changes. Managed hosts will often do the migration for you as part of onboarding, and accepting that is not laziness — they know their own platform’s failure modes better than you do.

The other case for not doing it yourself: if you cannot describe what would go wrong and how you would detect it, you are not ready to run the migration unsupervised. Read the steps again rather than proceeding hopefully.