If your site is still showing old server content after a migration, the DNS records may already be correct — the problem is almost always cached DNS resolutions that haven't expired yet, or an oversight in how the cutover was staged. This is one of the most common support tickets hosting companies get right after a server or hosting provider move, and it usually has nothing to do with the new server itself. Here's exactly why it happens and how to fix a stuck DNS cutover without taking the site offline.
Why DNS Still Points to the Old Server After Migration
Every DNS record has a TTL (Time To Live) value that tells resolvers how long to cache the answer before checking again. If your A record's TTL was set to 24 hours (86400 seconds) before the migration, any resolver that already cached the old IP will keep serving it to visitors for up to a full day after you updated the record — regardless of how fast you switch the DNS panel setting.
Other common causes beyond simple TTL caching:
- ISP-level DNS caching — some ISPs cache records longer than the TTL specifies, especially for high-traffic domains
- Browser DNS cache — Chrome and other browsers maintain their own DNS cache separate from the OS
- Stale nameserver records — if you changed nameservers (not just an A record) at the registrar, propagation can take up to 48 hours globally
- CDN or proxy layer — if Cloudflare or another CDN sits in front of your DNS, changes may need to propagate through their edge network separately
💡 None of these worked? Skip the guesswork.
Get Expert Help →Step-by-Step Fix: Speeding Up Propagation and Confirming Cutover
If you're planning a future migration, drop the A record TTL to 300 seconds (5 minutes) at least 24 hours ahead of time. Lowering TTL at the moment of the change doesn't help — resolvers that already cached the old, higher TTL value won't check again until it expires.
Don't decommission the old server the moment you flip DNS. Keep it running and serving identical content for 48–72 hours so visitors hitting cached DNS records still land on a working, up-to-date site instead of a dead server.
Run a DNS lookup against public resolvers to check what's actually being served globally:
dig +short yourdomain.com @8.8.8.8
dig +short yourdomain.com @1.1.1.1
nslookup yourdomain.com 208.67.222.222If these all return the new server's IP but a specific visitor still sees the old site, the issue is local caching on their end, not your DNS.
# Windows
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Linux (systemd-resolved)
sudo systemd-resolve --flush-cachesAlso clear the browser's internal DNS cache by visiting chrome://net-internals/#dns and clicking "Clear host cache."
If Cloudflare (or similar) is proxying your domain, confirm the orange-cloud proxy status points to the correct origin IP. CDN edge nodes cache DNS resolution independently and may need a manual cache purge from the CDN dashboard, not just the DNS zone.
Verifying Cutover From Multiple Locations
Don't rely on a single machine to confirm a migration is complete — your own computer's cache can lie to you. Use a global DNS propagation checker to see resolution results from dozens of locations worldwide simultaneously, and cross-check with a curl request that bypasses DNS entirely:
curl -H "Host: yourdomain.com" http://NEW_SERVER_IP/If this returns the correct site content directly from the new server's IP, you've confirmed the new server itself is correctly configured — any remaining "old content" reports are purely a caching/propagation issue on the client side, not a server misconfiguration.
How to Prevent This on Future Migrations
- Always lower TTL to 300 seconds at least 24–48 hours before a planned migration
- Keep the old server active and serving current content for a minimum 48-hour overlap period
- Document the exact timestamp of every DNS change so you can correlate support tickets against propagation timing
- Communicate expected propagation windows to customers or stakeholders in advance so "old site" reports don't trigger unnecessary panic
- After confirming full propagation via multiple resolvers, raise TTL back to a normal value (3600+) to reduce DNS query load
When to Call a Server Migration Expert
A stalled or partial DNS cutover during a live migration can quickly turn into a support fire drill if it's not planned for in advance. CloudHouse's server migration service handles the entire cutover process — TTL scheduling, dual-server overlap, SSL cert pre-provisioning, and propagation verification — so migrations complete with zero visible downtime for your customers.
Frequently Asked Questions
How long does DNS propagation actually take?
With a properly lowered TTL (300 seconds), most resolvers will pick up the change within 5–30 minutes. Without a lowered TTL beforehand, propagation can take anywhere from a few hours up to 48–72 hours depending on how long the previous TTL was cached.
Why does my site show the old server on my phone but the new one on my laptop?
Different devices and networks cache DNS independently. Your mobile carrier's DNS resolver may have cached the old record at a different time than your home ISP or router, resulting in inconsistent results until both caches expire.
Should I keep the old server running during migration?
Yes — keeping the old server live and serving identical content for 48–72 hours after the DNS change prevents downtime for any visitor still hitting a cached old DNS record.
Does changing nameservers take longer than changing an A record?
Yes. Nameserver changes at the registrar level typically take longer to propagate globally — often up to 48 hours — because registries and resolvers cache NS delegation records separately from individual DNS records.
How can I check DNS propagation without waiting?
Query multiple public resolvers directly with dig or nslookup pointed at Google (8.8.8.8), Cloudflare (1.1.1.1), and OpenDNS (208.67.222.222). If all three already show the new IP, propagation is effectively complete globally — any remaining reports are local caching issues.