Introduction

A migration can look finished while traffic still splits between the old and new servers because the hostname still has more than one A record. If both IPs remain published, recursive resolvers may return either server and users will keep landing on different environments even though the cutover was supposed to be complete.

Treat this as an authoritative DNS record-set problem instead of a normal propagation delay. Start by checking the full set of live A records for the exact hostname, because if the old and new IPv4 addresses are both published on purpose or by mistake, traffic will keep dividing until the record set is cleaned up.

Symptoms

  • Some visitors reach the old server while others reach the new server after migration
  • Refreshing the site or switching networks produces different content or behavior
  • Logins, sessions, carts, or uploads break because requests land on different servers
  • DNS lookups return more than one IPv4 address for the same production hostname
  • The old server continues receiving real traffic even though the new server is live
  • The issue started after a DNS cutover, server replacement, or staged migration

Common Causes

  • The old A record was left in place alongside the new server IP
  • Multiple A records were inherited from an older high-availability setup that is no longer valid
  • A temporary second A record was kept during cutover and never removed afterward
  • A hosting panel or DNS provider auto-created an extra A record during migration
  • Validation checked only one lookup result and missed the full authoritative record set
  • Teams assumed the issue was propagation even though the live zone itself still published both IPs

Step-by-Step Fix

  1. Query the authoritative nameservers for the exact hostname and list every returned A record, because you need to confirm whether the split happens in the live zone itself.
  2. Decide whether the hostname is supposed to point to one production server or to a real load-balanced setup, because multiple A records are only correct when both backends are intentionally active and synchronized.
  3. Compare traffic and logs on the old and new servers to confirm that production requests are actually being divided, because that shows the operational impact of the duplicate A records.
  4. Review the authoritative DNS zone at the provider that controls the domain and identify the leftover old IPv4 address, because editing the wrong DNS panel will not stop the split traffic.
  5. Remove the stale old A record or replace the record set with the intended final IPs only, because keeping the retired address published will continue routing users to the wrong server.
  6. Save the DNS change and re-query the authoritative nameservers until they return only the intended record set, because that confirms the cleanup happened at the source.
  7. Compare results from several public recursive resolvers after the fix, because caches may lag for a while even after the authoritative answer is corrected.
  8. Monitor the old server until meaningful traffic stops arriving and keep a visible maintenance marker there if needed, because that makes residual stale traffic easier to recognize.
  9. Document the final DNS design for the hostname and avoid leaving temporary second A records in place after future migrations, because round-robin leftovers are a common cutover mistake.