Introduction

A server migration can finish successfully while one workstation or test device still reaches the old server because of a hosts file override. Public DNS may already point to the new environment, but local name resolution bypasses it entirely and keeps sending traffic to the previous IP.

Treat this as a local-resolution problem instead of a global DNS problem. Start by comparing results from the affected machine with a clean external lookup, because a hosts file override can make one device look broken while the rest of the internet is already correct.

Symptoms

  • One computer still reaches the old server after migration
  • Public DNS checks look correct, but the affected machine resolves the old IP
  • Browser tests from one workstation differ from phone or remote-network tests
  • Only local admin, QA, or jump-host systems still show the old environment
  • Flushing DNS cache does not change the result
  • The issue started after cutover, testing, or temporary migration validation work

Common Causes

  • The hostname was hardcoded in a local hosts file during migration testing
  • A QA workstation, jump box, or admin laptop still bypasses live DNS
  • The override was added temporarily and never removed after cutover
  • Different devices have different local resolution rules for the same hostname
  • Teams validated DNS publicly but forgot machine-specific overrides
  • The old server remains reachable, so the hardcoded entry still appears to work

Step-by-Step Fix

  1. Compare DNS resolution for the affected hostname on the problem machine versus a clean external resolver, because you need to prove whether the difference is local or truly global.
  2. Check the local hosts file on the affected system for any entry that maps the domain or subdomain to the old IP, because that override bypasses authoritative DNS entirely.
  3. Review related machines such as admin laptops, QA devices, jump hosts, and deployment workstations, because migration testing often leaves overrides on more than one system.
  4. Remove or update the stale hosts file entry and retest the exact hostname, because flushing DNS cache alone will not override a hardcoded local mapping.
  5. Confirm there are no browser-specific, proxy, or VPN rules still forcing the same hostname to the previous server, because local path overrides can stack together.
  6. Verify the machine now resolves the hostname through normal DNS and reaches the intended new environment, because deleting the entry is only useful if the live path is also correct.
  7. Compare the result from more than one network or device after the fix, because a single corrected workstation does not prove the rest of the testing fleet is clean.
  8. Audit any migration notes or temporary validation procedures that instructed teams to add hosts file entries, because those instructions often outlive the cutover.
  9. Document where local overrides were removed and how future migrations should track temporary hosts-file changes, because hardcoded test mappings are easy to forget.