Every configuration item in ServiceNow has a lifespan. Hardware gets decommissioned, software licenses expire, virtual machines are spun down, and services are discontinued. When that happens, the CI representing that asset does not simply disappear from the CMDB, and how it is handled at end of life has a direct impact on CMDB data quality, reporting accuracy, and the reliability of any automation or AI-driven processes running on the platform. Mismanaged retired CIs ServiceNow teams encounter most often are not deleted or updated promptly, leading to stale records that quietly corrupt downstream data.
The CI retirement process in ServiceNow is one of those areas where good intentions and poor execution frequently collide. Teams know a CI should be retired, but without a clear, enforced process, records linger in active states, relationships go unresolved, and reporting becomes unreliable. This article walks through the end-of-life process in practical terms, when to retire a CI, what to check before doing so, how to handle relationships and references, and what to keep for retention and reporting purposes.
When a CI Should Be Retired
A CI should be retired when the physical or logical asset it represents is no longer operational and will not return to service. This sounds straightforward, but in practice the trigger point is often unclear. The CI lifecycle management process needs to define retirement criteria explicitly, otherwise, CIs drift into a grey zone where they are neither active nor formally retired.
Common retirement triggers include the physical decommissioning of hardware, the end of a software contract or license, the shutdown of a cloud instance or virtual machine, and the discontinuation of a business service. In each case, the CI status in ServiceNow should move to Retired only after the asset itself has been confirmed as no longer in use, not when decommissioning is merely planned or in progress. Using intermediate lifecycle states such as Decommissioning or Pending Retirement helps distinguish intent from completion and keeps the CMDB accurate during transition periods.
One practical consideration: retirement should be driven by a formal change or decommissioning request in ServiceNow, not handled informally by an individual team member. Tying the retirement action to a completed change record creates an audit trail and ensures the update is deliberate rather than accidental.
Required Checks Before Retiring a CI
Before a CI is moved to Retired status, a structured set of checks should be completed. Skipping this step is where most CI retirement problems originate, a record is marked retired without verifying whether it is still actively referenced elsewhere in the platform.
Ownership and Responsibility
Confirm that the CI’s assigned owner or support group has signed off on the retirement. This is particularly important for CIs that underpin services or are referenced in SLAs. Retiring a CI without stakeholder confirmation can create gaps in service coverage that are difficult to trace after the fact.
Open Incidents, Problems, and Changes
Check whether any active incidents, problem records, or open change requests reference the CI being retired. Closing or reassigning these records before retirement prevents orphaned tickets and ensures that any ongoing work is not silently disconnected from its context. In ServiceNow, the CI field on these records will still point to a retired asset if not updated, which can mislead teams investigating recurring issues.
Active Monitoring and Discovery
If the CI is being monitored through ServiceNow Discovery or an integrated monitoring tool, confirm that monitoring has been disabled or removed. Retired CIs that remain in monitoring scope can generate false alerts or, worse, get rediscovered and automatically flipped back to an active state, undoing the retirement entirely.
Enforcing these checks consistently across teams is where many organisations struggle. Without a mechanism to validate that pre-retirement conditions are met, the process depends entirely on individual discipline. Data Content Manager’s data model enforcement capabilities allow teams to define mandatory field completions and validation rules that must be satisfied before a CI status transition to Retired is permitted, removing the reliance on manual checklists.
Relationships and References
Retiring a CI without addressing its relationships is one of the most common sources of CMDB data quality degradation. A CI does not exist in isolation, it typically has upstream and downstream dependencies, is mapped to services, and may be referenced by configuration baselines or application portfolios.
Before or immediately after retirement, the CI’s relationship map should be reviewed. Relationships to active CIs should be assessed for whether they remain valid. In most cases, a retired CI’s relationships should either be removed or marked as historical, depending on the organisation’s data model. Leaving active relationship records pointing to a retired CI creates misleading dependency maps and can cause service impact analysis to produce inaccurate results.
Service Mapping and CSDM Alignment
Under the Common Service Data Model (CSDM), CIs are connected to business services, technical services, and application services in a structured hierarchy. When a CI is retired, its connections within that hierarchy need to be reviewed. If a retired server was the sole host for a technical service component, that gap needs to be documented or the service record updated to reflect the change in infrastructure.
Integration and Dependency References
CIs referenced in integration payloads, automation workflows, or orchestration scripts present a particular risk. If an external system or a ServiceNow workflow references a CI by sys_id or name, retiring the CI without updating those references can cause silent failures in integrations. A review of integration logs and workflow configurations that reference the CI is a worthwhile step before finalising retirement.
Retention and Reporting
Retiring a CI does not mean erasing it. Retaining the record in a Retired state, rather than deleting it, preserves the historical context that auditors, capacity planners, and compliance teams often need. The question is not whether to keep retired CI records, but how to manage them so they do not pollute active reporting.
Retired CIs should be excluded from operational dashboards and active CMDB health metrics by default. Most ServiceNow reports and dashboards can be filtered by CI status, but this requires that the Retired status is applied consistently and accurately across all relevant records. If even a portion of decommissioned assets remain in an active or undefined state, those filters become unreliable and the data loses its integrity.
Audit Trails and Compliance
For regulated industries, the retirement record itself carries compliance value. The date of retirement, the associated change record, the approving owner, and the final configuration state of the CI are all details that may be required during an audit. ServiceNow’s native history logging captures field-level changes, but only if the retirement was processed through a formal record update rather than a bulk data operation that bypasses audit logging.
Reporting on Retired Assets
Periodic reporting on retired CIs, how many were retired in a given period, what asset types they represent, and whether retirements align with planned decommissioning schedules, provides useful visibility for IT asset management and capacity planning. This kind of reporting is only meaningful when the retirement data is clean and consistently applied. Inconsistent CI lifecycle management produces retirement reports that reflect process failures as much as actual asset turnover.
Maintaining that consistency over time, across teams and asset classes, is precisely the kind of data governance challenge that benefits from structured enforcement rather than documentation alone. When the rules for what constitutes a properly retired CI are embedded in the platform itself, the data stays reliable without depending on every individual to follow a separate process guide.
If your organisation is working through CI retirement backlogs or trying to establish a more consistent end-of-life process in ServiceNow, we are happy to show how Data Content Manager can help enforce lifecycle rules and keep your CMDB data accurate. Book a demo to see it in action.
