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

sattar3
Tera Contributor

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!

0 REPLIES 0