How to move a website to a new host without downtime

Moving hosts sounds like copying files. The reason it goes wrong is timing: for a period after you change DNS, some visitors reach the old server and some reach the new one, and if you've already switched the database off, that period is an outage.

Done in the right order, nobody notices. The whole trick is that DNS is the last step, not the first, and that you verify the new host before anyone is pointed at it.

Here's the sequence I use.

Step 1: Lower the DNS TTL, then wait

Do this several days before the migration. It costs nothing and it is what turns a 24-hour changeover into a five-minute one.

TTL is how long the rest of the internet is allowed to cache your DNS records. The default is often 24 or 48 hours, which means after you cut over, some visitors keep going to the old server for a full day.

In your DNS provider, set the TTL on your A and CNAME records to 300 seconds. Then wait for the old TTL to expire before migrating — if it was set to 24 hours, wait 24 hours.

# Check the current TTL on a record (the number before "IN A")
dig +noall +answer example.com A

Step 2: Copy everything to the new host

Files and database, without touching the live site.

For files, use whatever the hosts give you — SFTP, rsync, or a control panel backup. rsync is worth learning if you have shell access, because you can run it twice and the second run only copies what changed:

# Mirror the site to the new server, preserving permissions
rsync -avz --delete \
  -e ssh /var/www/html/ user@new-host:/var/www/html/

For the database, export from the old host and import on the new one:

# Export, transfer, import
mysqldump -u olduser -p --single-transaction olddb > backup.sql
scp backup.sql user@new-host:~
ssh user@new-host "mysql -u newuser -p newdb < backup.sql"

--single-transaction matters on a live site — without it, the dump can lock tables and take the old site down while you're trying to avoid downtime.

Then update the application's database credentials on the new host. On WordPress that's wp-config.php; on most other stacks it's an .env file.

Step 3: Test the new host before DNS knows about it

This is the step people skip, and it's the one that catches the broken PHP version, the missing extension, and the file permissions that didn't survive the copy.

You can point your own computer at the new server without changing anything for anyone else, by editing your hosts file. Add a line with the new server's IP and your domain:

# macOS / Linux: sudo nano /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts (open as Administrator)
203.0.113.45  example.com www.example.com

Now your browser resolves the domain to the new server while the rest of the world still gets the old one. Click through the site properly:

• The homepage and three or four inner pages
• A form submission — this catches missing mail configuration
• Login to the admin area
• Anything that writes files, like an image upload
• Checkout, if it's a shop

Fix whatever breaks. Nobody is affected yet. When you're done, remove the hosts file line so you're seeing the real site again.

Step 4: Freeze changes, sync the delta, cut over

Now the short window that actually matters. On a normal business site this takes fifteen minutes.

1. Stop writes to the old site. Tell staff not to publish, and if it's a shop, put it in maintenance mode. Orders placed during the cutover on the old database will be lost when you re-import.
2. Re-run the file sync. The rsync above, again — it'll only copy what changed since step 2.
3. Re-export and re-import the database. Same commands. This is what captures the posts, orders and form entries created since the first copy.
4. Change the DNS records to the new server's IP. Because the TTL is 300 seconds, the world catches up in about five minutes.
5. Take the old site out of maintenance mode — or better, leave the old server running untouched for a week as a rollback.

Watch the change propagate:

# Query a public resolver directly rather than your cached local one
dig @1.1.1.1 +short example.com A

The email trap nobody expects

The most common migration disaster I get called about isn't the website at all. It's email stopping.

If your email is on the same domain, your MX records — and often SPF, DKIM and DMARC TXT records — live in the same DNS zone. Two ways this goes wrong:

• You move the whole DNS zone to the new host, and the new zone doesn't include the old MX records. Mail starts bouncing immediately.
• Your email was on the old host's mail server, and you cancel that hosting account a week later. Mail stops with no warning.

Before touching DNS, export the existing zone file, or at minimum screenshot every record. After cutover, check the mail records survived:

dig +short example.com MX
dig +short example.com TXT

Then send a test email in and out.

After the cutover

Half an hour of checking now saves a week of confused reports later.

Leave the old hosting account active for at least a week. It costs one more month at worst, and it means a genuine rollback is possible instead of theoretical.

What to do first

Lower your TTL today, even if the migration is a fortnight away. It's a thirty-second change that has to happen well in advance, and it's the only step in this list you can't do at the last minute.

Then work through steps 2 to 4 in one sitting. The reason migrations go badly is almost never technical difficulty — it's doing the steps in the wrong order, under time pressure, on a Friday afternoon.

If you'd rather not do it yourself, zero-downtime migrations are part of what I do — including the DNS and email side that usually causes the trouble.