One of the biggest challenges IT leaders face is working out how to transition from managing standalone assets to properly leveraging Configuration Items in a CMDB. And that’s understandable – it’s not exactly straightforward.
The problem is that not every asset needs to become a CI, but figuring out which ones should make the cut? That’s where most organisations get stuck.
Get this wrong, and you’ll either end up with a bloated CMDB that nobody wants to use, or you’ll miss critical components that could save you hours during your next major incident. Neither’s ideal.
So let’s walk through the criteria that actually matter, share some practical steps that won’t overwhelm your team, and give you the best practices we’ve learned from helping organisations navigate this transition without losing their sanity.
Why This Transition Actually Matters
Here’s the thing: ITAM and ITSM are supposed to work together, but in most organisations they operate like distant cousins who only meet at family gatherings.
ITAM tracks the lifecycle of your physical and digital assets. ITSM focuses on using those assets to deliver reliable services. A decent CMDB is what bridges that gap.
But here’s where it gets tricky – not every asset needs to be a CI. Your coffee machine probably doesn’t need change tracking and dependency mapping. Your core network switches? Absolutely they do.
The gap between asset management and configuration management isn’t just administrative paperwork. It leads to inefficiencies, wasted resources, and that horrible moment during an outage when nobody’s quite sure what depends on what.
When you get the alignment right, several things improve dramatically:
Decision-making becomes genuinely better. Instead of having disconnected lists of equipment, you can see how assets actually support business services. This changes everything about how you plan upgrades, assess risks, and justify investments.
We’ve worked with organisations that shifted from making decisions based on “this server’s getting old” to “this server supports our three most critical business applications.” The difference in resource allocation is substantial.
Downtime becomes less frequent and much shorter. Service outages rarely affect just one thing – they cascade through interconnected systems in ways that aren’t immediately obvious. A robust CMDB reveals these hidden connections.
One healthcare client reduced their mean time to resolution by 43% after implementing proper dependency mapping. That directly translated to better patient care, which is what actually matters.
Compliance audits stop being a nightmare. Instead of manually hunting through spreadsheets and hoping you haven’t missed anything, a well-structured CMDB provides clear evidence of what systems you have, how they’re configured, and what changes have occurred.
Financial sector clients particularly benefit here. They can demonstrate compliance with regulations like PCI DSS or GDPR by generating comprehensive reports directly from their CMDB.
Working Out Which Assets Should Become CIs
Not everything in your asset register needs to be a CI. And that’s actually a good thing – including unnecessary items clutters your CMDB and makes it harder for people to find what they actually need.
Here’s what we look for when deciding whether an asset should transition to CI status:
Does It Support a Critical Service?
If an asset plays a direct role in delivering a key IT service, it probably belongs in your CMDB. This becomes much easier when you have a proper Service Catalogue rather than just an informal list of applications.
Many organisations we work with struggle with CI selection precisely because they lack this structured view. Without a catalogue, teams make inconsistent decisions based on individual perspectives rather than business impact.
If you haven’t developed a comprehensive Service Catalogue yet, start simple. Map your most critical business functions to their supporting applications. This alone can dramatically improve your CMDB implementation.
Does It Need Change Tracking?
If you need to monitor something for changes – software versions, hardware configurations, security patches – it’s probably a CI candidate.
Here’s a sobering statistic: organisations without proper change tracking for critical components experience 3-4 times more change-related incidents than those with robust tracking mechanisms.
Your change management process should help identify these assets. If something regularly appears in Change Advisory Board discussions or requires formal approval before modifications, it’s almost certainly a CI candidate.
Does It Have Dependencies?
This is where CMDBs really show their value. Assets that interact with other components, form part of application stacks, or support multiple services should be prioritised for CI inclusion.
In our experience, dependency mapping reveals surprising connections that aren’t obvious even to knowledgeable staff. One client discovered that a seemingly minor database server actually supported five critical business applications through various integration points. That information prevented a potentially disruptive decommissioning.
Does It Have a Complex Lifecycle?
Assets that get frequently updated, replaced, or maintained over time belong in the CMDB. Server hardware, enterprise applications, and networking equipment typically fall into this category.
We’ve helped organisations map lifecycle states to configuration states, which often reveals critical windows where undocumented changes occur. Many organisations lose track of configuration details during major upgrades, creating technical debt that accumulates over time.
Does It Feature in Incidents and Requests?
Components that regularly appear in incidents or service requests should be represented in your CMDB to facilitate faster resolution.
We’ve consistently seen how proper CMDB configuration creates tangible operational benefits. Clients who’ve implemented well-structured CMDBs report significant improvements in ticket processing efficiency. Users can select from accurate listings of configuration items through self-service portals, eliminating the time-consuming back-and-forth typically required to identify affected assets.
The bottom line: A network switch that supports your core internet connectivity should absolutely be a CI. The breakroom coffee machine? Probably not.
Getting Your Data Right
Quality data is what makes or breaks your CMDB. But “quality” doesn’t mean perfect – it means complete enough, accurate enough, and relevant enough to support the decisions you need to make.
To effectively manage a CI, your team needs access to certain key information:
- Basic details: Name, type, owner, and unique identifiers
- Relationships: How the CI interacts with others
- Lifecycle information: Purchase date, warranty details, end-of-life status
- Change history: Records of modifications, updates, or replacements
Before an asset can transition to a CI, its data needs to hit a minimum quality threshold. This usually requires collaboration between ITAM and ITSM teams to fill in gaps.
The trick is striking the right balance – don’t overwhelm your CMDB with excessive information, but include enough to support informed decision-making.
Best Practices That Work
Connecting assets to the CMDB efficiently requires a structured approach. Here’s what we’ve learned works:
Automate Asset Identification
Invest in discovery tools that can identify assets eligible for transition automatically. Manual asset discovery is tedious, error-prone, and doesn’t scale well.
Map the Relationships
Understanding how each CI interacts with others in your IT environment is invaluable for troubleshooting and planning. This is where many CMDB implementations provide the most value, but it’s also where they often fall short.
Use Established Standards
Frameworks like ITIL provide widely recognised best practices for CMDB management. Don’t reinvent the wheel – use proven approaches that other organisations have already validated.
Schedule Regular Maintenance
Adding a CI to the CMDB isn’t a one-time activity. Without ongoing maintenance, even the best CMDB implementation will degrade over time.
Common Problems (And How to Fix Them)
Transitioning assets to CIs comes with predictable challenges:
Incomplete or Outdated Data
This usually stems from poor record-keeping or lack of collaboration between teams. The quality of your CMDB directly reflects the quality of data going into it.
Start with a targeted data quality assessment focusing on your most critical assets rather than trying to fix everything at once. One retail client overcame severe data quality issues by implementing quarterly “data cleansing sprints” – dedicating specific resources to verifying and updating a prioritised subset of CIs each quarter.
CMDB Overload
The temptation to include everything often leads to unsustainable maintenance requirements. Combat this by establishing clear inclusion criteria based on business impact rather than technical classifications.
We’ve implemented “CMDB value audits” with clients, evaluating each CI category based on how frequently it’s referenced in key processes. This data-driven approach often reveals opportunities to streamline without compromising functionality.
People Resistance
This is often the most challenging aspect. Technical teams may view new documentation requirements as bureaucratic overhead, whilst management might question the investment.
Focus on the “what’s in it for me” factor for each stakeholder group. For technical teams, demonstrate how a reliable CMDB reduces repetitive work and troubleshooting time. For management, quantify the cost of poor configuration management through metrics like extended outages or failed changes.
Technology Limitations
Not all ITSM platforms provide equal CMDB functionality. If you identify gaps, consider supplementary solutions rather than complete replacements. Many organisations successfully enhance their core CMDB with specialised tools.
Remember: well-designed processes with moderate technology often deliver more value than advanced technology with poorly designed processes.
Managing the Change Process
Each CI transition creates ripple effects across processes, teams, and sometimes services. Here’s how to handle it properly:
Proper Change Advisory Board Oversight
Your CAB should assess the impact of each CI addition, but this means including representatives beyond just IT. Business stakeholders who understand the services these CIs support should have input.
We’ve found that organisations with CABs that specifically incorporate CMDB considerations into their evaluation criteria experience fewer data quality issues than those treating CMDB updates as administrative afterthoughts.
Genuine Stakeholder Buy-in
Securing meaningful commitment requires ongoing engagement throughout implementation. Map all stakeholders and their specific interests in CMDB success.
One manufacturing client created “day in the life” simulations showing how various roles would benefit from improved CMDB data, which dramatically increased voluntary adoption.
Comprehensive Documentation and Training
Create role-specific training modules rather than generic CMDB education. Training should include hands-on exercises with actual CMDB data, not just theoretical concepts.
Continuous Improvement
Even carefully planned implementations reveal unforeseen challenges. Establish regular review cycles to assess what’s working and what needs adjustment.
Organisations that implement structured improvement cycles typically see continuous gains in data quality and utilisation.
Making It Work Long-Term
Shifting from asset management to configuration management isn’t just a technical exercise – it’s an opportunity to align IT operations with broader business goals.
The transition takes time and collaboration, but the benefits far outweigh the effort. Start small, track your results, and don’t hesitate to bring in experts when needed.
After all, the smoother this transition, the faster your organisation can benefit from aligned ITAM and ITSM frameworks. And that’s what makes the difference between IT being seen as a cost centre and being recognised as a genuine business enabler.
