Looking for Advice: CMDB Archival & Staleness Strategy for Legacy CMDB (200+ Classes)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Wednesday
Hi Community,
We are designing an archival process to identify stale records across 200+ CMDB classes populated over time via various ingestion methods without IRE or archival rules.
Our current criteria for identifying stale CIs relies on Created by, Most recent discovery, and checking for orphaned relationships.
For those who have remediated a large, unmonitored CMDB:
What criteria/attributes provided the most reliable signal for "staleness"?
Did you use ServiceNow Data Manager or custom archival rules?
What pitfalls should we watch out for before archiving at scale?
Thanks in advance for sharing your experience!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
@kishanbarai The most reliable criterian attributes to consider for staleness would be the 'Updated' field. If it's discovered by any source/updated the relationships, the updated field would be definitely updated (Even if there is no change in the data).
Along with this, I would suggest with below:
What criteria/attributes provided the most reliable signal for "staleness"? -> Update field
Did you use ServiceNow Data Manager or custom archival rules? --> Data Manager is best as you can link OOB sub-flow or your custom one (Custome one can be created to update the Operational Status/Life cycle stages to retired) Also, there are dashboards created on Data manager for the amount of tasks created and whom it's assigned and not to trigger another task if already one exists for the same Archival/team/assigned to.
What pitfalls should we watch out for before archiving at scale? -> Do it on one class or select few CI's in Archival rule and examine the results. Basing on that when you are confident, extend class by class. Not advisable to do it on all the 200+ classes at one shot.