Introduction

This problem happens after the DNS cutover was already made but some traffic still reaches the previous server. At that point the main question is no longer whether the record was edited in the right provider. It is which cache or proxy path still believes the old IP is valid. This guide is for draining stale traffic after a migration when the authoritative DNS should already be correct.

Symptoms

  • The domain still loads the old server after a migration or cutover
  • Some users reach the new site while others see the old environment
  • The authoritative nameservers already return the new IP
  • The old server keeps receiving production traffic after the planned switch
  • Behavior differs by office network, ISP, browser, or geography

Common Causes

  • Recursive resolvers are still honoring the previous TTL
  • Local operating system, browser, or router caches have not refreshed yet
  • Enterprise DNS appliances or ISP resolvers still serve stale answers
  • Cloudflare or another proxy still points at the old origin behind the scenes
  • The old server remains online, so stale traffic looks normal instead of failing visibly

Step-by-Step Fix

  1. Query the authoritative nameservers and confirm they already return the new IP before treating the issue as residual cache.
  2. Compare results from several public resolvers to identify whether the stale answer is limited to specific recursive DNS providers.
  3. Check browser, operating system, office network, and local router caches if only certain environments still reach the old server.
  4. Verify whether a CDN or proxy is enabled and confirm the origin target behind that layer is also updated to the new infrastructure.
  5. Review logs on the old server so you can measure which traffic is still arriving and from where.
  6. Flush local or managed resolver caches only after the authoritative answer is confirmed correct so you are fixing the right layer.
  7. Keep the old server serving a maintenance banner, redirect, or visible marker during cutover if possible so stale traffic is easy to recognize.
  8. Re-test from different networks until the new IP is returned consistently and the old host stops receiving meaningful traffic.
  9. Lower TTLs before future migrations and plan a brief overlap window so stale-cache traffic can drain in a controlled way.