CI Reclassification Explained: What We Should Know
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thursday
CI Reclassification Explained: What We Should Know
In IT Service Management, Configuration Items (CIs) form the backbone of your Configuration Management Database (CMDB). They help you track, manage, and understand every component in your IT environment. But as systems evolve, you may need to reclassify a CI so it better matches its current purpose or characteristics.
Reclassification changes the CI’s class, which affects the attributes it carries and what information is kept or removed. Below is a clear breakdown of how CI reclassification works and what to consider before making changes.
What Happens When You Reclassify a CI?
Reclassifying a CI triggers a few important processes:
1. Attribute Updates
The CI’s attributes are adjusted to fit the structure of the new class. Some attributes may be added, and others may disappear depending on what the new class supports.
2. Loss of Class-Specific Data
If the current class contains attributes that the new class doesn’t support, those values are removed during reclassification.
3. New Class Record Creation
A new record is created under the new class, but the CI keeps its original sys_id, ensuring continuity across the CMDB.
Types of CI Reclassification
Reclassification generally falls into one of three categories: downgrade, upgrade, or switch. Each affects the CI differently.
1. Downgrade
Definition:
Moving a CI to a more general class higher in the hierarchy.
Example:
Reclassifying a cmdb_ci_server to cmdb_ci_computer.
Impact:
You lose server-specific attributes—like RAM, CPU speed, and disk size—because the broader computer class doesn’t support them.
2. Upgrade
Definition:
Moving a CI to a more specific class lower in the hierarchy.
Example:
Reclassifying a cmdb_ci_computer to a cmdb_ci_server.
Impact:
The CI gains additional attributes such as server type or operating system—attributes available only in the more specific class.
3. Switch
Definition:
Reclassifying a CI to a class on a different branch of the hierarchy. This change includes aspects of both a downgrade and an upgrade.
Example:
Moving a CI from cmdb_ci_linux_server to cmdb_ci_win_server.
Impact:
Linux-specific attributes (e.g., distribution) are removed.
Windows-specific attributes (e.g., Windows version) are added.
This makes switch reclassifications the most impactful and potentially risky.
Key Considerations Before Reclassifying
Data Loss Risks
Downgrades and switches often remove attributes that don’t exist in the new class. Review what information could be lost to prevent unintended data gaps.
Automatic Reclassification Settings
Many platforms—such as those using the Identification and Reconciliation Engine (IRE)—may reclassify CIs automatically. While useful, this can cause silent data loss if not configured carefully. Understanding your IRE or CMDB rules is essential.
Final Thoughts
CI reclassification is essential for keeping your CMDB accurate and aligned with your evolving environment. By understanding how downgrades, upgrades, and switches work—and by reviewing attributes before making changes—you can better protect your data and maintain a clean, reliable CMDB.
Thoughtful planning and awareness of automatic reclassification behaviours will help ensure smooth transitions and prevent surprises along the way.
