Impact and Best Practices for Updating Stale CIs to Absent or Retired Status

[sattar3]

Hi Everyone,

I’m looking to understand the impact and best practices around updating stale Configuration Items (CIs) to Absent or Retired status in our CMDB. Specifically:

• Are there any known impacts or risks when changing stale CIs to these statuses?
• What prerequisites or validations should be in place before performing these updates?
• Are there any existing scripts or automation available that others have recently used for this process? If so, could you please share them or point me to related posts/articles?

Currently, the approach is:

• If a CI hasn’t been discovered or updated in the last 45 days, it is marked as Absent.
• If a CI hasn’t been discovered or updated in the last 90 days, it is moved to Retired status.

Below are some outlined Acceptance Criteria (AC) and rules we are considering for automating this lifecycle update:

1. CI Identification:

• CIs are identified as outdated if last discovery or update is beyond the defined staleness thresholds and the CI is missing from the latest discovery results.

2. Discovery Validation:

• Only CIs previously discovered by a source and currently missing from the latest discovery data are considered outdated.
• Exclusions apply for CIs intentionally excluded from discovery or managed by non-discovery authoritative sources.

3. CI State Transitions:

• Before retirement, CIs should be marked as Inactive/Absent with proper logging.
• After a grace period (e.g., 90 days in Absent state), the CI status changes to Retired with audit trail.

4. Safeguards & Exclusions:

• CIs referenced by active Business Applications, services, or open tickets must not be retired; instead, flagged for manual review.

5. Audit & Logging:

• All updates must be logged with previous and new status, discovery dates, and automation job details for audit and troubleshooting.

6. Error Handling:

• Automation failures should prevent status changes, trigger error logs, and alert support teams.

7. Communication & Change Readiness:

• Proper documentation and approval must exist covering identification logic, status changes, and exception handling.

If anyone has implemented a similar lifecycle automation or has recommendations on safe ways to update CI statuses to Absent or Retired, I’d appreciate your insights and any script examples.

Thank you!

[jerry01]

Bit late to the conversation, but I've only recently started digging into our CI lifecycle approach and reached the point where I'm looking at retirement/archive policies in more detail.

Interesting to see that there has been no response on this thread yet.

The biggest challenge isn't necessarily deciding on the 45/90-day thresholds, but determining what the most appropriate thresholds are across different CI classes and tiers. I couldn't find many best-practice references for these specific numbers, and most discussions seem to treat them as organization-specific. However, any guidance would definitely be helpful for customers who are starting to set this up rather than directing them to CMDB manager.

For example, a server, cloud resource or container can have very different update/discovery patterns. A single stale threshold may result in either false positives or stale data lingering longer than necessary. Similarly, a server supporting a critical application may need a different threshold than, say, a server in a lab environment.

I'm also interested to hear how your implementation went in practice:

• Did you end up using the 45-day Absent and 90-day Retired values? More importantly, did you differentiate between CI classes and tiers?
• What classes were included/excluded?
• Did you encounter many false retirements due to Discovery issues, MID Server issues or temporary outages?
• Looking back, is there anything you would change in the approach?

Keen to hear any lessons learned from production usage.