Introduction

An application migration can move the new backend into production while the API gateway still forwards requests to the old upstream. Clients keep hitting stale data, authentication behaves inconsistently between routes, or one API path works while another still lands on the retired service because the gateway configuration, service registry, or route mapping did not fully move during cutover.

Treat this as a traffic-routing problem instead of a generic API outage. Start by checking where the live gateway actually proxies the affected route, because migrations often update DNS and backend deployments first while the edge gateway keeps its previous upstream target.

Symptoms

  • API requests still reach the old backend after migration
  • Clients receive stale data or behavior that does not match the new platform
  • One route or hostname works while another still uses the previous upstream
  • Authentication, rate limits, or headers differ depending on which path the request takes
  • Gateway health checks look green, but application behavior suggests traffic still lands on the retired environment
  • The issue started after moving API services, ingress layers, or reverse proxy infrastructure

Common Causes

  • The gateway route still points to the old upstream hostname, IP, or service name
  • A gateway service registry, discovery backend, or cluster membership entry still resolves to the previous environment
  • Canary, weighted routing, or path-based rules still send part of the traffic to the retired backend
  • A declarative config bundle, ingress manifest, or admin API update was only partly applied
  • DNS, internal load balancer aliases, or upstream TLS settings still bind the route to the old service
  • Validation checked the public endpoint but did not confirm which backend actually served the request

Step-by-Step Fix

  1. Capture one affected request and record which upstream server, cluster, or service instance actually handled it, because the live route matters more than the config you intended to deploy.
  2. Compare that active upstream with the intended post-migration backend, because one stale target in the gateway can keep all matching traffic pinned to the retired service.
  3. Review gateway routes, upstream pools, service discovery records, and any config pushed through the admin API or GitOps pipeline for references to the old backend, because edge routing often spans more than one control layer.
  4. Check for weighted rules, canary policies, header-based routing, or path-specific overrides, because partial migrations often leave only some requests on the legacy upstream.
  5. Update the authoritative gateway configuration and reload or redeploy the gateway if required, because editing one route definition does not help if the running proxy still uses cached state.
  6. Send a controlled test request with unique data or headers and confirm it reaches the intended backend, because a 200 response alone does not prove the gateway stopped using the old upstream.
  7. Verify the retired backend no longer receives traffic from the gateway, because split routing can hide itself when both environments remain reachable.
  8. Review rate limiting, auth plugins, and response transformation policies if behavior still differs, because some gateway features can stay attached to old route objects even after the backend target changes.
  9. Document which team owns gateway routing, service discovery, and migration validation so future cutovers confirm the real upstream path before decommissioning the old environment.