Introduction

A CMDB or asset discovery migration can bring the new platform online while scanners still upload results to the old collector, MID server, or discovery gateway. New configuration items never appear in the target CMDB, reconciliation stays stale, or one scanner group reports correctly while another still feeds the retired environment because discovery jobs, relay nodes, and credential sets often outlive the backend change.

Treat this as a discovery-path problem instead of a generic CMDB data-quality issue. Start by checking where an affected scanner actually sends its discovery results and which collector or relay processes them, because migrations often validate the new CMDB instance first while existing scanners continue posting to the previous ingestion path.

Symptoms

  • Discovery data still lands in the old CMDB or asset platform after migration
  • New devices are missing from the target CMDB even though scans keep running
  • One scanner group reports correctly while another still uses the previous collector
  • Reconciliation or enrichment fails only after the old collector is shut down
  • Discovery schedules appear healthy, but the new platform never receives fresh data
  • The issue started after moving CMDB, asset inventory, discovery relays, or MID servers

Common Causes

  • Discovery jobs still target the old collector, MID server, or ingestion API
  • Scanner agents or probe appliances still use the previous relay hostname, token, or queue
  • Credentials or connector settings were migrated, but the result-upload endpoint was not
  • One relay node or regional collector was updated while another still serves the retired environment
  • Golden images or automation keep redeploying discovery agents with the old target
  • Validation confirmed the new CMDB could ingest data but did not verify which backend live scanners actually used

Step-by-Step Fix

  1. Capture one affected discovery scanner and record the exact collector, relay, queue, or API endpoint it is sending results to, because the runtime upload path determines where inventory actually lands.
  2. Compare that active discovery path with the intended post-migration CMDB design, because one stale relay or ingestion URL can keep an entire scanner estate tied to the retired platform.
  3. Review discovery schedules, scanner configs, MID or relay settings, enrollment tokens, and automation templates for references to the old collector, because CMDB discovery usually spans agent, relay, and platform layers.
  4. Check regional scanners, network segments, and relay pools separately if behavior differs by site, because migrations often fix one ingestion path while another still uses the previous collector.
  5. Update the authoritative scanner and relay configuration so affected probes upload to the intended CMDB backend, because standing up the new platform alone does not retarget already deployed discovery workers.
  6. Run a controlled discovery job and confirm the new platform receives the expected CI updates from the affected scanner, because seeing the scanner online does not prove results now reach the right backend.
  7. Verify the old collector no longer receives discovery traffic from migrated scanners, because split discovery pipelines can hide for a long time while both systems remain available.
  8. Review credentials, firewall policy, and reconciliation rules if scans still appear incomplete, because the destination can be correct while transport or ingest processing still fails.
  9. Document which team owns scanner packaging, relay routing, and migration validation so future CMDB cutovers verify the real discovery upload path before retiring the previous environment.