Test a Website Before DNS Migration

Migrating a website to a new server is always stressful. What if something doesn't work? What if the site is inaccessible for hours? The solution: test your new server BEFORE changing DNS, using the hosts file. The same trick lets you preview a site before any DNS change — a new host, a new IP, or a CDN switch — without touching public DNS or risking downtime.

How to test a website before a DNS migration

To test a website before a DNS migration, map its domain to the new server's IP in your hosts file so only your machine sees the new server while public DNS stays unchanged:

1. Find the new server's IP address. 2. Open the hosts file as administrator. 3. Add NEW_IP example.com and NEW_IP www.example.com. 4. Flush DNS, then browse the site and test every critical path. 5. Remove the entries once the real DNS change has propagated.

Why test before migration?

Risks of direct migration

• Downtime: If the new server has a problem, your site is down
• SSL Certificate: Let's Encrypt can fail if misconfigured
• Server configuration: PHP version, missing modules, .htaccess...
• Database: Connections, performance, corrupted data
• Paths and links: Hardcoded URLs, absolute paths

The hosts file advantage

By modifying your hosts file, you point the domain to the new server only on your machine. The rest of the world continues accessing the old server.

Result: you can test for hours without impacting your users.

Step 1: Get the new server's IP

Connect to your new server/host and note the IP address.

At common hosts

SiteGround / Bluehost

• cPanel > Server Information > IP Address

Cloudways / DigitalOcean

• Dashboard > Server > IP Address

AWS / GCP

• Instance > Public IP

Netlify

• Deploy settings > Domain settings

Step 2: Modify the hosts file

On Mac

sudo nano /etc/hosts

Add at the end:

# Temporary migration - DELETE after migration
203.0.113.50    www.mysite.com
203.0.113.50    mysite.com

Replace 203.0.113.50 with your new server's IP.

On Windows

1. Open Notepad as administrator 2. File > Open > C:\Windows\System32\drivers\etc\hosts 3. Add the same lines

Flush DNS cache

Essential after modification:

# Mac
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

# Windows
ipconfig /flushdns

Step 3: Tests to perform

Basic test

1. Open your browser in private/incognito mode 2. Go to https://www.mysite.com 3. The site should display from the new server

Verify you're on the right server

Create a temporary test file on the new server:

echo "NEW SERVER" > /var/www/html/test-migration.txt

Then access https://www.mysite.com/test-migration.txt

Don't forget to delete this file afterwards!

Complete test checklist

Pages and navigation

• [ ] Homepage
• [ ] Internal pages (at least 5)
• [ ] Contact forms
• [ ] Login/signup pages

Features

• [ ] Internal search
• [ ] Cart / e-commerce
• [ ] Member area
• [ ] API / endpoints

Media

• [ ] Images display
• [ ] Videos play
• [ ] PDFs downloadable
• [ ] Uploads work

Performance

• [ ] Acceptable load time
• [ ] No 500/503 errors
• [ ] Cache works

Step 3.5: Confirm server identity

Before testing deeply, make sure you are really seeing the new server. Browser cache and CDN cache can trick you.

Use a temporary marker file

On the new server:

echo "new-server-$(date)" > /var/www/html/migration-check.txt

Then open:

https://www.mysite.com/migration-check.txt

Delete the file after testing.

Check response headers

curl -I https://www.mysite.com
curl -I --resolve www.mysite.com:443:203.0.113.50 https://www.mysite.com

--resolve is useful because it forces curl to use the new IP without editing your hosts file. The hosts file is easier for browser testing, while curl --resolve is excellent for repeatable command-line checks.

Compare old and new servers

If possible, test both IPs:

curl -I --resolve www.mysite.com:443:OLD_IP https://www.mysite.com
curl -I --resolve www.mysite.com:443:NEW_IP https://www.mysite.com

Look for differences in status code, cache headers, redirects and server headers.

Step 4: Verify SSL certificate

This is crucial. A misconfigured certificate = site inaccessible via HTTPS.

Visual verification

• Green padlock in address bar
• No security warning

Certificate verification

Click the padlock > Certificate > Verify:

• Correct domain
• Validity date
• Issuer (Let's Encrypt, Sectigo, etc.)

Common SSL problems

"NET::ERR_CERT_COMMON_NAME_INVALID" The certificate isn't issued for this domain. Regenerate it.

"Certificate expired" The certificate wasn't renewed on the new server.

Test certificate with OpenSSL

openssl s_client -connect www.mysite.com:443 -servername www.mysite.com </dev/null

Check:

• The certificate common name or SAN includes the domain.
• The chain is complete.
• The expiration date is valid.
• The server presents the correct certificate for both root and www domains.

If the certificate is wrong only while using the hosts file, the new server may not be configured for SNI on that hostname.

Step 5: Proceed with DNS migration

Once all tests pass:

1. Connect to your registrar (GoDaddy, Namecheap, Cloudflare...) 2. Modify the A records to point to the new IP 3. Wait for propagation (minutes to 48h depending on TTL)

Check propagation

Use whatsmydns.net to see global status.

SEO checks before switching DNS

Migrations are not only infrastructure changes. They can affect rankings if the new server changes URLs, status codes or metadata.

Before changing DNS, verify:

• Important pages return 200, not 301 loops or 404.
• Canonical URLs still point to the correct domain.
• Robots meta tags still allow indexing.
• robots.txt is not blocking production paths.
• XML sitemap is accessible.
• Redirects preserve old URLs.
• Structured data still renders.
• Open Graph images load.
• Page titles and descriptions did not disappear.

Use a small sample first:

• Homepage.
• Top 5 organic landing pages.
• Top 5 revenue or lead pages.
• Blog pages with backlinks.
• Contact and checkout flows.

DNS TTL strategy

Lower TTL before migration, not during the emergency.

Recommended flow:

1. 48 hours before migration: lower A record TTL to 300 seconds. 2. Migration day: update the A record. 3. After stability: raise TTL back to a normal value.

If you cannot lower TTL in advance, propagation may take longer. Keep the old server online until traffic clearly reaches the new server everywhere.

Rollback plan

Prepare rollback before you need it.

• Keep the old server unchanged.
• Keep database backups.
• Save the old DNS values.
• Document exactly which records changed.
• Keep hosts entries ready for testing old and new servers.

Rollback is simple if DNS was the only change: point the A record back to the old IP. It is harder if content changed on both servers during the migration window.

Step 6: Post-migration cleanup

Remove hosts entries

Once propagation is complete:

sudo nano /etc/hosts

Delete the lines added for migration.

Flush DNS cache one last time

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Verify everything works

Test from another device (phone on cellular) to confirm the new server is responding.

Special cases

Migration with CMS change

If migrating WordPress to another CMS, also test:

• 301 redirects from old URLs
• Updated XML sitemap
• Internal links functional

E-commerce migration

Additional critical points:

• Payment gateways
• Webhooks (Stripe, PayPal)
• Transactional emails
• Stock and pending orders

Sites with CDN (Cloudflare)

If using Cloudflare: 1. Cloudflare proxy uses its own IPs 2. Test in "DNS only" mode (grey cloud) 3. Re-enable proxy after validation

WordPress migrations

Also check:

• Permalinks.
• Upload paths.
• Object cache.
• Search/replace of old URLs.
• Admin login.
• Cron jobs.

API migrations

Also check:

• CORS headers.
• Auth callbacks.
• Webhook endpoints.
• Rate limits.
• Health check URL.

Email migrations

The hosts file does not test email routing. Email follows MX, SPF, DKIM and DMARC DNS records. Treat mail migration as a separate checklist.

Automate with Locahl

To easily manage these temporary hosts modifications:

• Create a "Migrations" group
• Enable/disable with one click
• Modification history
• No risk of syntax errors

Complete migration checklist

Before migration

• [ ] Full backup of current site
• [ ] Note new server IP
• [ ] SSL configured on new server
• [ ] Current DNS with reduced TTL (300s)

During tests

• [ ] Hosts file modified
• [ ] DNS cache flushed
• [ ] All tests passed
• [ ] SSL certificate validated

After DNS migration

• [ ] Propagation verified
• [ ] Site accessible everywhere
• [ ] Hosts entries removed
• [ ] Old server kept 7 days (backup)

Conclusion

Testing before migrating is the key to stress-free migration. The hosts file gives you a perfect test environment, invisible to your users. Take time to verify everything before changing official DNS.