Moving hosts feels risky because people imagine it as one big switch. Done right, it’s the opposite: two complete copies of your site running at once, and a DNS change that quietly points people from one to the other — with the old one still there the whole time as your safety net. This works for any CMS. Before starting you should be able to take a backup that restores and know how DNS records and TTLs work, because those two skills are the entire trick.

Take the full backup and stand it up on the new host

Full backup of the old site: files and database, per the backup lesson. Then restore it onto the new host — upload the files, create a database, import the dump, and point the site’s config (wp-config.php, settings.php, or your CMS’s equivalent) at the new database credentials. The restore drill you’ve already practiced is exactly this, just landing on different soil.

Test the new copy with the hosts-file trick

The new server has your site but not your domain — DNS still points at the old host. The hosts file on your own computer lets you override that, locally, just for you. Edit /etc/hosts (on Windows, C:\Windows\System32\drivers\etc\hosts) and add the new server’s IP:

203.0.113.45  example.com www.example.com

Now your browser visits the new server while the rest of the world still sees the old one. Click everything that matters: front page, login, forms, search, checkout if you have one. Fix what’s broken now, while nobody’s watching. Remove the line when you’re done testing.

Lower the DNS TTL a day ahead

TTL is how long the internet is allowed to remember your DNS answer. If your A record’s TTL is 24 hours, some visitors keep hitting the old server for a full day after you switch. So at least a day before cutover, lower the TTL on the records you’ll change to 300 seconds. This one small edit is what turns “propagation takes forever” into “propagation takes five minutes.”

Freeze changes on the old site

From here to cutover, the old site is read-only by decree: no content edits, no plugin updates, no new user signups you can avoid. Anything that changes on the old server after your backup is something you have to migrate twice or lose. Put the CMS in maintenance mode if the site takes orders or comments; for a mostly-static site, an email to the editors does it.

Re-sync anything that changed, then flip DNS

Take a fresh database dump from the old host and import it on the new one, and re-copy any files uploaded since the first pass (rsync makes this fast, since it only moves what changed):

rsync -avz olduser@old-host:/var/www/example/ /var/www/example/

Then the actual cutover: change the A record (or records) to the new server’s IP. That’s it — that’s the whole moment.

Watch both servers’ logs during propagation

With a 300-second TTL, traffic drains from old to new over minutes. Tail the access log on both servers and watch it happen:

tail -f /var/log/apache2/access.log

(Or nginx’s equivalent.) You want the new server’s log filling up with normal-looking requests and 200s, and the old one going quiet. Errors on the new server, right now, while the old one still works, are the cheapest errors you’ll ever fix.

Keep the old host alive for a week

Don’t cancel the old account on cutover day. Some resolvers ignore TTLs; some problems take three days to introduce themselves. A week of overlap costs a few dollars and buys you a working rollback: point DNS back and you’re on the old server again in minutes. After a quiet week — logs normal, forms arriving, no “site looks weird” emails — take one last backup of the old host for the archive, then let it go. Verification here is simply time: seven days of the new server behaving is the proof.