CI Reclassification: When Your Infrastructure Changes its Identity
What is Reclassification? Reclassification happens when a Configuration Item (CI) moves from one class in the CMDB to another. This usually occurs because new data provides more detail about what the device actually is.
- Upgrade: A generic "Server" is identified as a "Linux Server."
- Downgrade: A "Windows Server" is re-identified as a generic "Hardware" device (rare, usually indicates a data error).
- Switch: A device incorrectly identified as a "Linux Server" is correctly identified as a "Unix Server."
- Assess and Baseline: We monitor "Reclassification Tasks." If a large number of CIs are constantly switching classes, it’s a sign that your Discovery patterns or Identification rules are conflicting.
- Operating Model: We establish "Reclassification Governance." For critical classes, we require a manual review before a class change is finalized. This prevents a critical "Database" from being accidentally downgraded to a "Software" record.
- Fix Data Quality: We use "Normalisation" to ensure that the source data is consistent. If your cloud provider calls a device a "Compute Instance" but your on-premise tool calls it a "VM," we ensure both map to the same target class to prevent unnecessary reclassification.
- Does the SysID change? No. The record remains the same; only the "Class" field and the available attributes change.
- Can I block reclassification? Yes, you can configure the IRE to reject class changes for specific high-value CIs.
- What is a "reclassification task"? It is a record created in ServiceNow that asks a human to approve or reject a suggested class change.
The Risk of Data Loss When a CI changes class, it may lose data. If you move from a class with many fields (like a Server) to a simpler class (like a PC), the fields that don't exist in the new class are "dropped."
How Apex Manages Reclassification Safely
- Assess and Baseline: We monitor "Reclassification Tasks." If a large number of CIs are constantly switching classes, it’s a sign that your Discovery patterns or Identification rules are conflicting.
- Operating Model: We establish "Reclassification Governance." For critical classes, we require a manual review before a class change is finalized. This prevents a critical "Database" from being accidentally downgraded to a "Software" record.
- Fix Data Quality: We use "Normalisation" to ensure that the source data is consistent. If your cloud provider calls a device a "Compute Instance" but your on-premise tool calls it a "VM," we ensure both map to the same target class to prevent unnecessary reclassification.
FAQ:
- Does the SysID change? No. The record remains the same; only the "Class" field and the available attributes change.
- Can I block reclassification? Yes, you can configure the IRE to reject class changes for specific high-value CIs.
- What is a "reclassification task"? It is a record created in ServiceNow that asks a human to approve or reject a suggested class change.
