How to Keep Your Site Live While Switching Hosts Without Downtime

The way to move a website to a new host without downtime is to switch the DNS record only after the new server is fully serving the site, and to keep the old server running until the DNS change has propagated. You do this by staging the entire site on the new host, testing it against the live database and files, and then lowering the TTL on your DNS records before you flip the A record or CNAME. The key is that you never delete or stop the old server until you are certain the new one is handling traffic.

Stage the full site on the new host before you move website to new host without downtime

Start by creating a complete copy of your site on the new server. That means the document root, the database, any cron jobs, and any background workers. For a typical PHP or Node application, you will rsync the files from the old host to the new one. Use rsync with archive mode and exclude caches or logs that should not be copied. A command that works for most setups looks like this:

rsync -avz --delete --exclude 'var/cache' --exclude 'logs' user@old-host:/var/www/site/ /var/www/site/

Then dump the database from the old host and import it into the new one. For MySQL or MariaDB, you would run mysqldump on the old server and pipe it directly into mysql on the new server. That avoids writing a huge file to disk. The command is:

mysqldump -u old_user -p old_db | ssh user@new-host "mysql -u new_user -p new_db"

After the import, you must update the configuration on the new server so it points to the new database credentials and the new file paths. Check files like .env, wp-config.php, or config/database.php. Also update any hardcoded URLs in the database if your site stores absolute URLs. For WordPress, that means running a search and replace on the wp_options table. For other frameworks, look for a settings table or a config file that holds the base URL.

Test the new server before you touch DNS

You cannot test the new server by visiting your domain, because DNS still points to the old host. Instead, edit your local /etc/hosts file to force your own machine to resolve the domain to the new server's IP address. Add a line like this:

203.0.113.10   www.example.com example.com

Then browse to https://www.example.com from that machine. You will see the new server, while everyone else still sees the old one. Test every page that matters: the homepage, a product page, a login flow, and any API endpoints. Also test forms that write to the database, because that is where most staging mistakes show up. If you have a staging site on the new host, you can also point a subdomain like staging.example.com to the new IP and test that way, but the hosts file method is faster and does not require an extra DNS record.

While you are testing, watch the new server's logs. Run tail -f /var/log/nginx/access.log or the equivalent for Apache or your application server. You should see requests coming in from your test machine. If you see 500 errors, check the application log and the PHP or Node error log. Fix those issues now, because once you flip DNS, you will not have time to debug.

Lower the TTL and flip the DNS record

DNS records have a TTL, which tells resolvers how long to cache the record. If your TTL is set to 86400 seconds (24 hours), then after you change the A record, some visitors will still go to the old server for up to a day. To make the switch fast, lower the TTL at least 24 hours before you plan to flip. Go to your DNS provider and change the TTL for the A record and the CNAME record (if you use www) to 300 seconds (5 minutes). Wait for that change to propagate, which takes at most the old TTL duration. Then you can flip the record.

When you flip, change the A record for the apex domain and the www subdomain to the new server's IP. If you use a CNAME for www, point it to the new host's hostname. Do not change anything else. Keep the old server running and keep the old DNS records in your provider's zone file, even if they are not active. That way, if you need to roll back, you can flip the A record back in minutes.

Verify the switch and keep the old server as a fallback

After you change the DNS record, wait a few minutes and then check from multiple locations. Use a public DNS checker or a tool like dig to confirm that the record now returns the new IP. Run dig example.com A and dig www.example.com A from your terminal. The output should show the new IP address. Then visit the site from a browser that you have not used for that domain, or use a private browsing window, to make sure you are not seeing a cached page.

Keep the old server running for at least 48 hours after the flip. During that time, some visitors with aggressive DNS caching will still hit the old server. If the old server is still serving the site, those visitors see no downtime. If you shut it down immediately, they get a connection error. Also, if you find a critical bug on the new server, you can roll back by changing the A record back to the old IP. The old server still has the old database and files, so the site will work, though it will be missing any changes made since the flip.

Handle the database split brain problem

The one thing that can cause real downtime is if your site writes to the database while both servers are live. After you flip DNS, some users go to the new server and some go to the old one. If both write to the same database, you get conflicts. The safest approach is to make the old server read-only after the flip. For MySQL, you can set read_only = ON in the config or run SET GLOBAL read_only = ON. For a file-based site, you can change the filesystem permissions to read-only. That way, any straggler traffic to the old server can still read pages, but it cannot write new data that would be lost when you shut the old server down.

If your site is heavily write-oriented, you might instead keep both servers writing to the same database, but that requires a shared database host or a replication setup, which is more complex than most moves need. For a typical site, making the old server read-only is the right call. After 48 hours, you can shut down the old server or repurpose it.

What to do next

Once the new server is stable and the old one is retired, update your monitoring and your deployment scripts. Change any hardcoded IP addresses in your CI/CD pipeline, your cron jobs, and your backup scripts. Also update your DNS records to remove any stale entries and set a sensible TTL for normal operation, usually 3600 seconds. Then run a full backup of the new server, because you now have a clean baseline. Finally, test your rollback plan by documenting exactly what you did, so that if you ever need to move again, you can do it in under an hour instead of a weekend.