Introduction

A cutover can move application traffic to a new backend tier while Citrix ADC still routes requests to the old one. The VIP remains online, but real traffic continues landing on the retired service, one virtual server uses the new pool while another still follows the previous service group, or failures begin only after the old backend is decommissioned because vServer bindings, service groups, monitors, and automation often change separately.

Treat this as a load-balancing target problem instead of a generic ADC outage. Start by checking which backend service an affected virtual server actually selects at runtime, because migrations often validate the new VIP listener first while live traffic continues following older bindings.

Symptoms

  • Citrix ADC still routes traffic to the old backend service after cutover
  • The VIP is healthy, but requests still land on the retired application tier
  • One virtual server or path uses the new backend while another still uses the previous one
  • Routing failures begin only after the old servers, monitor, or service binding is removed
  • The new backend is healthy, but migrated traffic never reaches it consistently
  • The issue started after moving Citrix ADC service groups, backend pools, or cutover automation

Common Causes

  • The virtual server still binds to the old service or service group
  • Backend services were recreated, but policy bindings or content switching still reference the previous target
  • Monitors, weights, or persistence settings keep the old pool preferred or still marked usable
  • A config sync, backup restore, or automation run restored earlier backend bindings
  • One listener, path rule, or service group was updated while another still points to the retired backend
  • Validation confirmed the new backend responded to test traffic but did not verify which pool the live vServer actually selected

Step-by-Step Fix

  1. Capture one affected request path and record the virtual server, policy chain, bound service or service group, and backend IP it actually reaches, because the live ADC decision path determines where traffic really lands.
  2. Compare that active routing path with the intended post-cutover design, because one stale binding can keep production traffic tied to the retired backend tier.
  3. Review vServer bindings, service groups, content-switching policies, monitors, persistence settings, and automation templates for references to the old backend, because Citrix ADC routing depends on several layers of config together.
  4. Check each listener, hostname, path rule, and service group separately if behavior differs, because cutovers often update one route while another still selects the previous target.
  5. Update the authoritative backend mapping and policy chain so affected traffic reaches the intended service tier, because bringing the new backend online alone does not retarget existing ADC listeners.
  6. Run a controlled request and confirm the intended backend handles it through the expected vServer and service group, because a healthy VIP does not prove the right target served production traffic.
  7. Verify the old backend no longer receives requests from migrated Citrix ADC paths, because split routing can remain hidden while both service tiers stay reachable.
  8. Review monitor thresholds, persistence cookies, SSL offload settings, and sync status if traffic still fails, because the destination can be correct while health logic or appliance state still blocks the new path.
  9. Document which team owns ADC bindings, backend pool changes, and migration validation so future cutovers verify the actual runtime target before retiring the previous service tier.