stale CIs in our CMDB that haven’t been updated in a long time

[ShivamKumar78]

We currently have over 100,000 stale CIs in our CMDB that haven’t been updated in a long time. What’s the best approach to handle them? Should we consider deleting these records, or is there a recommended cleanup strategy?

[Tanushree Maiti]

Hi @ShivamKumar78 

• To improve CMDB hygiene and reduce manual cleanup effort, use the native CMDB Data Manager to automate CI lifecycle management. Configure Data Manager policies to automatically transition Configuration Items (CIs) to a Retired state (for example, Install Status = 7) when they have not been discovered or updated for 90–120 days.
• Before performing any bulk retirement or cleanup activities, verify that the target CIs are not associated with active incidents, change requests, or critical business applications. Use the CMDB Health Dashboard to identify stale CI classes, assess data quality, and prioritize cleanup activities based on the greatest impact.
• When retiring CIs, ensure that related records are also managed appropriately. Implement a business rule or scheduled flow to identify and remove or archive orphaned relationship records (such as those in the cmdb_rel_ci table). Cleaning up these relationships helps preserve the structural integrity of the CMDB and prevents invalid dependency mappings.

[Bhargavi Patel · Accepted solution]

Hi @ShivamKumar78 

For 100,000+ stale CIs, the best approach is structured cleanup, not mass deletion. First, identify which are truly obsolete, then retire or archive them so they don’t clutter active operations but remain available for audit. Automate discovery to validate active CIs and set lifecycle rules like auto‑retire after 12 months of no updates to prevent future buildup. Delete only if you’re certain there’s no compliance or reporting need.

Please Accept the solution if it assisted you with your question & Mark this response as Helpful.

In short: assess → archive/retire → automate → govern → delete cautiously

[IanCox]

Good advice above from Bhargavi and Tanushree on Data Manager, the retirement lifecycle (Install Status = 7), and cleaning up orphaned cmdb_rel_ci records. I'd add one step before any of it, because it decides whether the cleanup actually sticks: diagnose WHY they went stale first.

A 100,000-CI stale spike is usually one of two very different situations, and they call for opposite actions:

1) The assets are genuinely gone/decommissioned and Discovery correctly stopped seeing them. These are your retire/archive candidates -- exactly the Data Manager to Retired flow described above.

2) The assets still exist, but Discovery stopped reaching them: a MID Server went down, credentials expired, a schedule got disabled, a subnet or cloud account fell out of scope, or a Service Graph connector broke. These CIs aren't obsolete -- they're just invisible. Retire them and you'll retire live infrastructure and break impact analysis for change and incident.

So before applying a blanket 90-120 day threshold, segment the stale set by CI class and by last discovery source, and sanity-check each segment against reality. Very often a big chunk of "stale" CIs trace back to a handful of broken discovery schedules or credential issues -- fix those and the number drops without deleting anything real.

Two more that save pain:

- Don't use one staleness threshold across all classes; some legitimately update infrequently and a flat rule over-retires them.

- Fix the source or it rebuilds. Retirement policy is the cure; discovery hygiene is the prevention. Clean up without restoring coverage and you'll be back here in a few months.

Net sequence: assess why, fix the discovery gaps (recover the false positives), retire the genuinely dead via Data Manager, clean up relationships, then govern the cadence with the CMDB Health dashboard.

(Disclosure: I run a ServiceNow consultancy focused on CMDB remediation -- this gone-vs-not-discovered split is the pattern we see on almost every stale-CI cleanup.)

[Harish Bainsla]

Hi @ShivamKumar78 

There is a system property that lets you set the stale CI during like 60days or 90days ETC..., its recommended to set the stale CI to ''Retired' instead to delete them. 

For more best practice check below link

https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB2688522

if my answer helps you mark helpful and accept solution