Introduction

A WAN or edge migration can bring the new transit, ISP, or interconnect online while routers still advertise prefixes toward the old one. Traffic follows the wrong egress path, failover behaves unpredictably, or one edge router prefers the new transit while another still leaks routes to the retired provider because BGP neighbors, route maps, and local-preference policy often move in stages.

Treat this as a route-policy problem instead of a generic connectivity outage. Start by checking which neighbors actually receive and advertise the affected prefixes on a live edge device, because migrations often validate new circuits and sessions while existing routing policy continues steering traffic toward the previous transit.

Symptoms

  • Routers still advertise routes to the old transit after migration
  • Traffic exits through the previous provider even though the new one is online
  • One edge router uses the new transit while another still prefers the old path
  • Connectivity fails only after the old provider session is shut down
  • BGP sessions appear healthy, but the wrong route policy still controls traffic
  • The issue started after moving WAN edge, ISP circuits, or interconnect routing

Common Causes

  • Old BGP neighbors are still configured and active on edge routers
  • Route maps, prefix lists, or communities still prefer or export to the previous transit
  • Local preference, MED, or AS-path policy was updated on one router but not another
  • Automation templates or route-policy rollouts keep restoring the old session behavior
  • VRF-specific neighbors or failover policies still reference the retired provider
  • Validation confirmed the new transit session was up but did not verify where live prefixes were actually advertised and preferred

Step-by-Step Fix

  1. Capture one affected edge router and record the BGP neighbors, advertised routes, and best-path attributes for the impacted prefixes, because the live policy state determines where traffic really exits.
  2. Compare that active routing state with the intended post-migration WAN design, because one stale route map or neighbor can keep large traffic volumes tied to the retired transit.
  3. Review neighbor definitions, route maps, prefix lists, local-preference policy, communities, and automation templates for references to the old provider, because BGP migration depends on both session state and policy logic.
  4. Check each edge router, VRF, and region separately if behavior differs, because migrations often fix one routing domain while another still advertises to the previous transit.
  5. Update the authoritative BGP and policy configuration so affected prefixes are advertised and preferred through the intended transit, because turning up the new circuit alone does not change existing best-path decisions.
  6. Generate controlled traffic and confirm the intended transit now carries the affected flows, because an established BGP session does not prove the right provider is winning or receiving routes.
  7. Verify the old transit no longer receives advertisements or preferred traffic from migrated edges, because split route policy can remain hidden while both providers stay connected.
  8. Review timers, graceful restart, and upstream filtering if routes still behave unexpectedly, because the destination can be correct while stale path state or provider-side policy still interferes.
  9. Document which team owns edge policy, route-map deployment, and migration validation so future WAN cutovers verify the actual advertised and preferred transit path before retiring the previous provider.