Moving a website to a new host with no downtime

What "no downtime" actually asks for

A move has two parts: the transfer of the data and the switch of the doors (DNS). Downtime happens when the transfer and the switch overlap badly. The way to stay up is to prepare the new host to serve the domain while the old host still serves it, then flip the DNS in a short window.

Step 1: choose the new host and prep the landing zone

Compare hosts on real numbers (uptime, response latency for your region, PHP and database versions, backup, email and SSL handling), not just price. Then create the site on the new host: same platform, same PHP version or a tested upgrade, same database server. Note the new server's IP; every step below depends on it.

Step 2: move files and database

The transfer has two parts, and database first is a trap. The file set and the DB must come together in the right order:

1. Create the new database, then import the dump.
2. Upload the file tree (via a tar transfer or your panel's importer).
3. Point the site config at the new database and check the config file path and credentials (the WordPress restore order article's step four generalizes here).
4. Test on a temporary URL or over the IP with a hosts-file entry.

A traps list for the move:

• Hardcoded URLs: any absolute https://old-domain in content, DB, config or email signatures breaks on the new host. The URL migration planning article covers the search-replace step.
• Absent extensions: a certificate, a PHP extension, or a mail-setting the new host lacks shows up only when the code needs it.
• File permissions: a shallow copy that works on a folder owning a different user fails on the web server's user.

Step 3: flip the DNS

The day before, set the TTL low for the A record. On cutover day:

1. Point the A (and AAAA if used) records at the new host IP.
2. Keep the TTL question separate from the cutover: the TTL that matters is the one on the current A record, so lowering it the day before makes the final flip fast.
3. Wait for propagation; the site is live for different users at slightly different times, which is normal.

Step 4: verify like a skeptic

• Load the site in a private window and from a phone on mobile data (bypasses your resolver's cache; the DNS propagation article covers the timing puzzle).
• Confirm the SSL certificate is live for the new host before anyone else meets it; a certificate mismatch is the most common "site down after host move".
• Confirm email, cron, backups and external services write to the new host by their logs.

Step 5: retire the old host

Leave the old host up for a week minimum as a rollback. Cancel billing only after the numbers drop to zero and the Search Console and email flows have all moved. The host migration checklist is the version of this article without the copy; use the two together when the stakes are high.