Test the new host before you change public DNS. Monitor both the old and new hosts during cutover, then keep watching redirects and uptime for several days. A DNS move means updating the domain's DNS records to point visitors to a new server IP address. That change spreads unevenly, so some visitors reach the new host while others still reach the old one.
Table of Contents
- Preview the new server before you switch
- Why does timing matter so much?
- Why keep the old host running?
- What should you check during cutover?
- What should you watch after traffic moves?
Preview the new server before you switch
Build and click through the site on the new server while the public still uses the old host. According to Turnkey Internet, you can do this by adding the domain and new-server IP to your computer's hosts file, so only that browser visits the new server in its hosts-file preview guide. Check key templates, forms, checkout, logins, and file downloads.
Fix broken paths, database errors, and missing media before changing public DNS. That preview affects only that one machine. Upstream resolvers keep serving the old address, and you must remove the hosts entry after cutover or that computer will keep showing the wrong server.
Why does timing matter so much?
DNS is a heavily cached and distributed system with no central store. According to ServerPilot Documentation, different resolvers and regions switch from the old IP to the new IP at different times. TTL controls how long resolvers cache an answer.
According to Cloudflare, proxied records use a fixed 300-second Auto TTL, while DNS-only records can use values from 60 seconds to one day in its TTL reference. Lower TTLs ahead of the move so old answers expire faster. Leave enough lead time for the lower value itself to spread before you switch.
Why keep the old host running?
Keep the old account live for some time after the switch. According to AIT, sites should keep the old hosting account live about 48-72 hours after the DNS switch so visitors with cached old answers still get a working site in its migration guide. Do not shut down files, databases, or TLS on the old server during that window.
A visitor sent to a dead old server sees downtime even when the new server works. Negative caching can extend confusion. According to Cloudflare troubleshooting guidance, a query made before the new record exists may cache an empty or NXDOMAIN response until the zone's SOA MINIMUM period expires.
What should you check during cutover?
Monitor both origins at once: the public hostname plus each server's IP or temporary URL. According to Microsoft Learn, teams should verify URL availability from multiple geographic locations before and after migration and shift traffic incrementally where possible in its migration guidance.
Use checks that show which server answered, such as response headers or a version marker. Test from several regions because one location may see the new IP while another still sees the old IP.
- Confirm the public hostname responds on both old and new origins.
- Confirm each origin directly by IP or temporary URL.
- Repeat key checks from multiple geographic locations.
- Compare status codes, page content, and response time by location.
What should you watch after traffic moves?
Keep old-URL redirects live and monitor uptime, response time, SSL validity, and search-crawl behavior over several days. According to Google Search Central guidance and Microsoft Learn, that post-move watch catches redirect gaps, certificate errors, and crawl problems before the old host is removed. Watch server logs on both hosts to see when old-IP traffic fades.
For WordPress, Drupal, marketing, and Ads landing pages, test forms, tracking tags, canonical URLs, and paid-traffic destinations again after the switch. Delete the local hosts entry, then retest the public hostname without it. Decommission the old host only after redirects, certificates, and crawl behavior stay stable.
