Introduction

A monitoring migration can bring the new observability platform online while routers, switches, firewalls, UPS devices, or appliances still send SNMP traps to the old monitoring server. Dashboards in the new system stay quiet, alerting looks incomplete, or one device class appears in the new platform while another still reports only to the retired receiver because trap targets usually live on each device or template rather than in one central console.

Treat this as an alert-destination problem instead of a generic monitoring outage. Start by checking which trap receiver the affected device actually sends to, because migrations often build the new NMS and import dashboards first while network devices continue using the previous SNMP target.

Symptoms

  • Devices still send SNMP traps to the old monitoring server after migration
  • The new monitoring platform receives polls but not traps or alerts
  • One device class or site reports correctly while another still uses the retired trap receiver
  • Alerting fails only after the old monitoring server is decommissioned
  • Trap test messages never appear in the new platform even though devices are otherwise reachable
  • The issue started after moving monitoring, NMS, or alert collection infrastructure

Common Causes

  • Device SNMP trap receiver settings still point to the old monitoring server IP or hostname
  • Community-based trap settings or SNMPv3 target users were updated only on the new platform, not on the sending devices
  • Device templates, automation, or controller pushes keep restoring the old trap receiver
  • One site or hardware class was migrated while another still uses the retired monitoring target
  • NAT, DNS aliases, or firewall rules still direct trap traffic to the previous server
  • Validation confirmed polling and dashboard imports but did not test a live trap from each device type

Step-by-Step Fix

  1. Capture one test trap or recent alert from an affected device and record the exact receiver it is configured to use, because the sender configuration determines where alerts really go.
  2. Compare that active trap destination with the intended post-migration monitoring server, because one stale receiver entry can keep an entire device class tied to the retired platform.
  3. Review SNMP trap targets, v3 users, controller templates, automation pushes, and device config baselines for references to the old receiver, because trap settings often live on every appliance.
  4. Check each hardware family or site separately if behavior differs, because network migrations commonly update one template set while another still applies the old monitoring target.
  5. Update the authoritative trap destination settings and push the new config to affected devices, because changing only the monitoring platform does not retarget outgoing alerts.
  6. Send a controlled test trap and confirm the intended platform receives and parses it, because a reachable device does not prove its alerts now flow to the right destination.
  7. Verify the old monitoring server no longer receives traps from migrated devices, because split alert routing can leave incident visibility inconsistent across environments.
  8. Review firewall rules, SNMPv3 engine settings, and event processing on the new platform if traps still fail, because the destination can be correct while transport or parsing still blocks alerts.
  9. Document which team owns trap receiver templates, automation, and migration validation so future monitoring cutovers test both polling and real alert delivery before retiring the old server.