Introduction

A migration can look finished while users still hit the old server because the load balancer never stopped sending it traffic. DNS may already point to the balancer, the new application may be healthy, and yet one stale backend target remains in rotation. That creates a mixed environment where some requests hit the new stack and others reach a decommissioned or outdated server.

This is not a normal propagation problem. It is usually a backend pool, draining, or stickiness problem inside the load-balancing layer. Start by proving whether the old server is still a registered target and whether clients are being pinned to it.

Symptoms

  • Some users still see old content or intermittent errors after migration
  • Requests alternate between the new and old application state
  • The old server appears to receive traffic even though it was supposed to be removed
  • Monitoring shows mixed health or inconsistent backend responses after cutover
  • Only some sessions or regions are affected while others reach the new server normally
  • The issue starts immediately after moving traffic behind a new server pool or target group

Common Causes

  • The old server was never removed from the load balancer backend pool or target group
  • Connection draining or deregistration did not complete cleanly
  • Session stickiness keeps some clients pinned to the old backend
  • Health checks still treat the old server as valid even though it should be retired
  • A listener rule or path-based route still sends part of the traffic to the old target
  • Autoscaling, service discovery, or automation re-added the old server after migration

Step-by-Step Fix

  1. Verify that requests are actually reaching the old server by comparing logs, headers, or backend-specific responses, because you need proof of stale load-balancer routing before changing the target pool.
  2. Check the current backend pool, target group, or server list for the affected listener, because the simplest cause is that the old server is still registered and eligible for traffic.
  3. Review health status for every backend target and confirm whether the decommissioned server is still marked healthy, because a stale but healthy target will keep receiving requests.
  4. Inspect connection draining, deregistration, or graceful shutdown status if the old backend was recently removed, because partially drained targets can continue serving traffic longer than expected.
  5. Check whether session stickiness, cookies, or source-IP affinity are pinning clients to the old server, because some users may keep hitting the legacy backend even after the pool changed.
  6. Review listener rules, host-based routes, and path-based routing for hidden references to the old target, because one route can stay pointed at the legacy server while the main pool looks correct.
  7. Confirm that autoscaling, orchestration, or service-discovery automation is not re-registering the old backend after you remove it, because otherwise the bad target will keep coming back.
  8. Remove the old server cleanly from every relevant target path and retest from fresh sessions, because cached cookies or sticky sessions can hide whether the backend cleanup really worked.
  9. Decommission or isolate the old server only after the load balancer no longer reaches it, and document the target removal steps for future migrations, because mixed-backend cutovers are easy to repeat if the removal sequence is not explicit.