Migrating hosts without downtime

Migrations go wrong in predictable ways. Almost all of the damage comes from two mistakes: changing DNS before the new server is verified, and losing data written during the switch. Both are avoidable with sequencing alone.

Here's the order that works.

1. Copy everything to the new host first

Move files and database to the new server while the old one keeps serving traffic. Nothing about this step is visible to visitors, so take your time and do it properly.

Copy the files, export and import the database, then match the environment: PHP version, extensions, cron jobs, and any environment variables or API keys. The most common cause of "it works on the old host" is a PHP extension nobody remembered was installed.

2. Test on the new server before DNS knows anything

This is the step people skip, and it's the one that prevents outages.

Add an entry to your local hosts file pointing the domain at the new server's IP. Your machine now sees the new site under the real domain name, while the rest of the world still gets the old one.

203.0.113.10  example.com www.example.com

Now click through the site as a visitor would. Then click through it as an admin. Then — and this matters more than the rest — complete a real checkout, submit a real form, and send a real test email. Those are the things that break silently.

3. Lower your TTL, and wait

DNS records carry a time-to-live telling resolvers how long to cache them. If yours is 24 hours, a change takes up to a day to reach everyone.

Drop the TTL to 300 seconds at least a day before the migration. This does nothing on its own — but it means that when you do make the change, the world picks it up in minutes instead of hours. Skipping this is why "DNS propagation" gets blamed for long outages.

4. Freeze writes for the cutover

Between your final database copy and the DNS change, any order placed or comment posted lands on the old server and is lost when traffic moves.

For a brochure site, ignore this. For anything transactional:

• Put the old site in maintenance mode, or
• Schedule the cutover for genuinely quiet hours, and
• Take a final incremental database sync immediately before flipping DNS.

The window should be minutes, not hours.

5. Change DNS, keep the old server running

Update the A record (and AAAA, if you have one) to the new IP.

Then leave the old server running for at least 48 hours. Resolvers that cached the old record will keep sending visitors there, and ignoring stale caches is not something you can force. A working old server means those visitors see a working site rather than an error.

Don't cancel the old hosting the same day. It costs a few dollars to keep it another week, and it's the cheapest insurance in this entire process.

6. Verify from outside your own machine

Your hosts file entry is still lying to you — remove it first, or you'll be testing the wrong thing.

Then check propagation from multiple geographic locations, confirm the SSL certificate is valid on the new server, and send mail from the site to an external address to confirm deliverability. Check that SPF, DKIM and DMARC records still match wherever mail now originates; mail is the thing most likely to break quietly and stay broken for weeks.

The checklist

1. Copy files and database to the new host
2. Match PHP version, extensions and cron jobs
3. Test via hosts file — including checkout and email
4. Lower DNS TTL to 300s, wait 24 hours
5. Final database sync, freeze writes
6. Change the A record
7. Keep the old server up 48 hours
8. Verify SSL, mail and DNS from outside

Done in that order, the visible downtime is zero. Done in a different order, it's however long it takes you to notice.