Review configuration quality and retire resources

Configuration data stays useful through stewardship. Production changes, platform migration, failover redesign, repeated incidents, reconciliation findings and support ownership changes should trigger a review.

Before you start

Assign technical stewards and agree where review evidence is recorded. Review dates and exception registers can be governance records; this guide does not imply native review fields or automatic scoring for every CI.

Steps

1. Check meaningful identity, correct CI type, environment class/type, applicable status, active state and criticality.
2. Verify support context, technical stewardship and relevant routing/maintenance/availability overrides.
3. Inspect direct relationships for valid endpoints, direction, environment and intentional impact mode, including descriptive no-impact edges.
4. Remove unintended duplication or stale relationships through controlled review. Test a representative Incident/Change after material corrections.
5. For a linked physical Asset, review custody/repair/commercial history separately from the CI's configuration and operating state.
6. Before decommissioning, inspect associations, dependent resources, policies, operational history, Catalog consumers and historical references. Coordinate with owners and preserve traceability.
7. Retire or deactivate records under the applicable lifecycle process, and only delete after reviewing the implementation's constraints and possible orphaned references.

Assets and configuration

Asset Management can be activated independently. A useful Asset–CI reference connects physical/commercial and operational perspectives, but it is optional and does not automatically synchronize either side. Multiple Assets can point to the same CI; scalar references can become orphaned. Reconciliation highlights suspected issues for review.

Several Contracts can cover one Asset in the later documented implementation. Contract coverage is not the CI's dependency structure. The Asset financial overview treats purchase/repair expense and contract coverage separately; do not infer operational topology from procurement links.

Retirement and deletion boundaries

CI deletion is blocked while relationships or Offering–Instance associations reference it. Deleting a Business Application clears application references on Instances instead of deleting those Instances. Neither action automatically retires the Service or all Offerings.

A large graph is not necessarily a good graph. Prioritize critical production paths and high-use service commitments, track accepted exceptions and retain evidence that directions and impact modes were checked.

Expected result

The map remains explainable, and resource retirement does not silently erase the meaning of associated service commitments or physical custody records.

Important behaviour

Editable Asset status names influence some lifecycle/reconciliation checks; validate changes rather than assuming universal semantic matching. Reconciliation acknowledgement records review, not source correction. Discovery, SBOM, dynamic CI groups and full software licence compliance are not implied by the configuration type catalogue.

Related guides