Introduction

A staged migration often uses weighted DNS to move traffic gradually, but problems start when the final cutover happens and the old destination still keeps a share of live requests. The new site may be healthy and intended to take all production traffic, yet the DNS traffic policy still gives the legacy endpoint a nonzero weight or keeps it eligible through health-based logic. This creates a confusing situation where the migration appears complete but some users still reach the old infrastructure.

Treat this as a traffic-policy problem instead of assuming propagation alone is responsible. Start by checking the live weighted record set or DNS traffic policy, because a migration can look complete in dashboards while the old target is still intentionally included in the answer pool. This issue is common with AWS Route53 weighted routing, Google Cloud DNS, Azure Traffic Manager, and other DNS-based traffic distribution systems.

The problem frequently appears after gradual migrations, canary deployments, blue-green cutover attempts, or when organizations forget to remove the "old" weights after successfully completing a phased rollout. DNS administrators may reduce the weight to a small value like 5% for safety but forget to set it to zero or remove it entirely after the migration succeeds.

Symptoms

  • Some users still reach the old site after the cutover should be complete
  • Traffic, logs, or analytics show both old and new environments receiving requests in parallel
  • Authoritative DNS answers alternate between legacy and current targets on repeated queries
  • The issue is worst after a canary, phased rollout, or gradual migration plan where weights were used
  • Teams believe the old target was removed, but intermittent requests still hit the legacy infrastructure
  • Different resolvers appear to return different valid answers for the same hostname
  • Customer complaints about inconsistent behavior or missing features on the "old" site
  • Backend logs show traffic split between old and new servers despite migration completion
  • Load on the old server continues despite expectations of zero traffic

Common Causes

  • The old target still has a nonzero weight in the DNS policy (e.g., weight of 10 vs 90 for new)
  • Health-based routing or failover rules keep the legacy destination eligible because it's still responding
  • Only one branch of the weighted policy was updated while another branch still points to the old environment
  • Related records such as AAAA (IPv6), CNAME, or regional policy branches were not updated consistently
  • Cached answers from the pre-cutover weighted policy are still draining out from recursive resolvers
  • Validation focused on the main hostname but not the full traffic policy attached to it
  • Multiple weighted record sets exist (different regions) and only one was updated
  • The old target was reduced to a small weight but never set to zero or removed

Step-by-Step Fix

  1. 1.Identify the exact weighted record set or traffic policy serving the production hostname in your DNS provider dashboard (AWS Route53, Google Cloud DNS, Azure Traffic Manager), because you need to inspect the active routing object and not just one visible DNS answer.
  2. 2.Review every target in that policy and confirm whether the legacy destination still has any weight at all (even weight=1 keeps it eligible), because even a small nonzero value can keep sending real users to the old environment.
  3. 3.Check health-based routing, failover logic, and automatic policy behavior in the DNS configuration, because some providers can keep or restore an old target when they still consider it healthy (responding to health checks).
  4. 4.Compare authoritative answers for the hostname over repeated queries and from multiple resolvers (dig @8.8.8.8 hostname.example multiple times), because weighted policies can hide stale routing when you test only once and the randomness might favor the new target.
  5. 5.Inspect related DNS records such as AAAA (IPv6), CNAME, regional branches (Geolocation routing), or provider-specific policy layers, because removing the old target from one branch does not help if another branch still serves it.
  6. 6.Set the legacy target weight to zero or remove it entirely only after confirming the new destination is ready for full production traffic and healthy, because a partial policy cleanup leaves the split-brain behavior in place. Use the DNS provider's console or API to update the weighted routing policy.
  7. 7.Wait through the original TTL window (typically 60-300 seconds) before judging the fix, because resolvers may continue returning cached weighted answers even after the authoritative policy is corrected.
  8. 8.Confirm in server logs, application logs, and monitoring that the old environment stops receiving new requests once the cache window expires, because traffic data proves the policy change more reliably than one DNS lookup.
  9. 9.Record how the weighted rollout was retired after cutover, including the exact policy changes made, because staged traffic policies are easy to leave behind and can quietly split production traffic long after migration day.

Verification

Confirm the fix is complete:

  1. 1.Query the authoritative DNS multiple times and verify all answers point to the new target: for i in 1..10; dig hostname.example; done
  2. 2.Check backend logs on the old server to confirm zero new requests
  3. 3.Verify all traffic metrics show requests hitting only the new environment
  4. 4.Test from multiple geographic locations if using geolocation-based routing
  5. 5.Confirm the DNS policy dashboard shows the old target with weight=0 or removed

Prevention

To avoid this issue in future migrations:

  • Document the weighted DNS policy before starting a phased migration
  • Include "Set old target weight to zero" as a mandatory step in the cutover checklist
  • Use DNS TTLs appropriate for your migration timeline to speed up cache draining
  • Monitor traffic on both old and new targets throughout the migration
  • Schedule a specific review 24 hours after cutover to verify weights are correct
  • Consider using DNS failover with health checks instead of manual weighted routing
  • Remove or disable old targets entirely rather than just setting weight to zero
  • [Fix DNS Caa Record Blocking Letsencrypt Certificate Issuance Issue in DNS](dns-caa-record-blocking-letsencrypt-certificate-issuance)
  • [DNS CAA Record Blocking Let's Encrypt Renewal in a Multi-Provider Zone](dns-caa-record-blocking-letsencrypt-renewal-multi-provider-zone)
  • [Fix Dns Cdn Apex Domain Cname Restriction Alias Aname Record Issue in Dns](dns-cdn-apex-domain-cname-restriction-alias-aname-record)
  • [Fix DNS Cname Apex Not Supported Rfc Violation Registrar Issue in DNS](dns-cname-apex-not-supported-rfc-violation-registrar)
  • [Fix DNS Dnssec Validation Failure Chain Of Trust Broken Issue in DNS](dns-dnssec-validation-failure-chain-of-trust-broken)

<script type="application/ld+json"> { "@context": "https://schema.org", "@type": "TechArticle", "headline": "How to Fix Weighted DNS Still Splitting Traffic After Cutover", "description": "Resolve weighted DNS still splitting traffic after cutover by checking traffic policy records, legacy weights, health rules, and cached answers.", "url": "https://www.fixwikihub.com/fix-weighted-dns-still-splitting-traffic-after-cutover", "publisher": { "@type": "Organization", "name": "FixWikiHub", "url": "https://www.fixwikihub.com" }, "author": { "@type": "Person", "name": "FixWikiHub Editorial Team" }, "datePublished": "2025-10-31T08:19:59.493Z", "dateModified": "2025-10-31T08:19:59.493Z" } </script>