Every website migration has the same terrifying moment: you flip the DNS record, and for the next few hours you have no idea whether the new server is actually serving your site correctly — or quietly 500-ing for half the planet while it propagates.
The fix is simple: test the new server before you change DNS. Here's how to do that properly, plus the checks I run on every migration so nothing breaks silently.
The old way: editing your hosts file
The classic trick is to point your machine at the new server by adding a line to your local hosts file:
203.0.113.10 example.com
This works, but it's painful: you edit a system file with admin rights on every device, your phone and your client's laptop can't easily see it, and you will forget to remove the line and then debug "why is the site broken on my machine only."
The faster way: a temporary preview URL
Instead of editing the hosts file, you can generate a temporary URL that resolves to the new server's IP for your chosen domain — no local changes, works on any device.
I built a free tool for exactly this: hosts.click ("The Website Previewer"). You give it the new server's IP and the domain, and it hands you a temporary preview URL. Open it anywhere — desktop, phone, share it with the client — and click through the whole site exactly as it will look once DNS points to the new host. No hosts file, no DNS change, no waiting for propagation.
Diff the old and new server before you cut over
The most dangerous migration bugs are the silent ones — a redirect that changed, a header that got dropped, a page that's subtly different. Eyeballing every page won't catch them.
Run a server diff: hit the same paths on the old IP and the new IP and compare status codes, redirect chains, response headers, response time, and a hash of the page body. If the body hash differs on a page you didn't touch, find it now, not after the cutover.
Free tool: server diff — old IP vs. new IP, side by side.
Don't lose email
They change the domain's A record and their email stops working, because they assumed "changing hosts" meant changing everything. It doesn't. Your website (A/AAAA record) and your email (MX records) are independent. If you're only moving the website, leave the MX records alone. Verify your mail DNS — MX, plus SPF, DKIM, and DMARC — with an email DNS checker so you don't quietly drop into spam folders.
Lower your TTL first
DNS propagation isn't magic; it's caching. Every DNS record has a TTL (time to live). If your A record has a 24-hour TTL, your cutover can take 24 hours to fully roll out. At least a day before you migrate, drop the TTL on the records you'll change to 300 seconds. Then when you flip the record, the switch propagates in minutes instead of hours.
Watch the cutover propagate
Once you change the record, you want to see it roll out across the world rather than guessing. Query the domain against many public resolvers and watch them converge on the new IP.
Free tool: DNS propagation checker — compares your record across 45 public resolvers worldwide on a map.
Re-check the boring stuff on the new host
New server, new defaults. Confirm the new host matches the old one on what doesn't show visually:
-
Caching & compression — sensible
Cache-Controland gzip/Brotli? Check the cache checker. - HTTPS & the cert chain — valid, covers the hostname, complete intermediates? Run an SSL checker.
-
Security headers — HSTS, CSP,
X-Content-Type-Options. -
Redirects — did your
http → httpsandwwwcanonicalization survive the move?
The short version
Test before you switch, switch fast, verify after:
- Preview the site on the new server before touching DNS.
- Diff old vs. new to catch silent changes.
- Leave MX alone unless you're moving email too.
- Lower TTL 24h ahead.
- Flip DNS, watch it propagate.
- Re-check cache, SSL, security headers, redirects.
All the tools for each step are free (no signup) at hostsclick.com/tools. For a version tailored to your specific hosts, the migration checklist generator builds one for you.
Migrate boldly. Just test first.
Top comments (0)