Introduction

A monitoring migration can bring the new flow collector online while routers, switches, or firewalls still export NetFlow, IPFIX, or sFlow records to the old one. The target analytics platform shows no traffic, one device set reports correctly while another still feeds the retired collector, or visibility disappears only after the previous collector is shut down because flow exporter settings often remain buried in device templates and management systems.

Treat this as a telemetry-destination problem instead of a generic monitoring outage. Start by checking which collector IP, port, and source interface an affected device actually uses for flow export, because migrations often validate the new collector first while field devices continue following earlier exporter definitions.

Symptoms

  • Flow telemetry still goes to the old collector after migration
  • NetFlow, IPFIX, or sFlow data is missing from the new monitoring platform
  • One router, switch, or firewall group exports correctly while another still uses the previous collector
  • Visibility fails only after the old collector is disabled
  • The new collector is healthy, but no live flow records arrive from affected devices
  • The issue started after moving network monitoring, flow analytics, or telemetry infrastructure

Common Causes

  • Device exporter configuration still points to the old collector IP or hostname
  • Network automation templates or controller policies keep restoring the previous exporter target
  • Source interface, VRF, or ACL settings were updated for one environment but not another
  • Different flow formats or exporters were migrated separately, leaving part of the traffic on the retired platform
  • DNS aliases or load balancers still resolve the collector name to the old environment
  • Validation confirmed the new collector was listening but did not verify where live devices actually exported telemetry

Step-by-Step Fix

  1. Capture one affected device and record the configured collector, export port, and source interface or VRF it actually uses, because the runtime exporter path determines where flow data really goes.
  2. Compare that active telemetry path with the intended post-migration monitoring design, because one stale exporter statement can keep a large device population tied to the retired collector.
  3. Review device exporter config, sampling policies, automation templates, controller profiles, and DNS references for the old collector, because flow export often spans local config and centralized automation.
  4. Check routers, switches, firewalls, and sites separately if only some telemetry is missing, because migrations often fix one hardware class while another still carries the previous exporter target.
  5. Update the authoritative exporter and template configuration so affected devices send flow records to the intended collector, because standing up the new analytics platform alone does not retarget already deployed exporters.
  6. Generate controlled traffic and confirm the intended collector receives new flow records from the affected device, because a healthy collector service does not prove exporters switched destinations.
  7. Verify the old collector no longer receives telemetry from migrated devices, because split monitoring can remain hidden while both collectors continue accepting data.
  8. Review ACLs, MTU, and exporter format compatibility if records still fail to appear, because the destination can be correct while transport or parsing still blocks usable telemetry.
  9. Document which team owns exporter templates, collector routing, and migration validation so future monitoring cutovers verify the actual telemetry destination before retiring the previous platform.