Why most CMDBs fail and what to do about it

If your CMDB feels noisy, mistrusted, or quietly abandoned, you are not alone. In our experience with hundreds of ITSM teams, the same symptoms appear again and again. And almost none of them are caused by the tool.

If your CMDB feels noisy, mistrusted, or quietly abandoned, you are not alone. In our experience with hundreds of ITSM teams, the same symptoms appear again and again. And almost none of them are caused by the tool.

They are caused by the design.

This blog walks through the two most common CMDB pathologies we see, what is actually going wrong underneath each one, and the design principles that separate a CMDB people trust from a database people avoid.

Symptom #1 Nobody trusts the data

You know this one. The CMDB exists. It has data in it. But somehow, nobody uses it as their source of truth.

Change managers verify CI details by hand before approving anything. The Incident team asks in chat rather than querying the CMDB. Finance keeps its own spreadsheet of what the company owns; they don't even open the CMDB.

If this sounds familiar, the reflex is usually to blame data quality and launch a cleanup project. That cleanup will fail, and here is why: it is not a data quality problem at the root. It is a purpose problem.

Your CMDB is trying to answer three fundamentally different questions at the same time. And as a result, it answers none of them well.

• The Financial lens asks: What does it cost? Book value, depreciation, OPEX versus CAPEX, and total cost of ownership. The consumers are Finance and procurement. The cadence is monthly or quarterly. The granularity is coarse.

• The Asset & Inventory lens asks: What do we own, where is it, and who has it? Serial numbers, locations, warranties, lifecycle stages. The consumers are the ITAM team and the audit. The cadence is per-lifecycle-event.

• The Configuration lens asks: How are things connected, and what breaks if this changes? Service composition, dependencies, impact analysis, and change blast radius. The consumers are Change, Incident, and Problem management. The cadence is every change.

Each of these is a legitimate purpose for a CMDB. But none of them is the same database in disguise. When you try to design a single structure that serves all three, each group of users finds the data unsuitable for their purpose. Finance thinks it's incomplete. ITAM thinks it's out of date. Change management thinks it's missing the relationships. So they each build their own workaround. And now you have four sources of truth, none of which agree.

So, which one is yours?

Before you read further, take thirty seconds and answer honestly. Which of the three is your CMDB primarily for? Or, if you already have one running, which one is it actually being used for?

There is no wrong answer in general. But there is a wrong answer for your organisation if it doesn't match what the CMDB is actually being asked to do. Hold your answer in mind. What follows will look very different depending on which lens you picked.

The design question: where does each attribute live?

Once you know the primary lens, the next question is not "what CIs should we track?" It is: for each attribute, where does the source of truth live?

This is the single most important design decision in a CMDB. And it has exactly three valid answers.

• Held. The attribute is stored directly in your ITSM tool. The CMDB is the source. Stewardship and updates happen inside the tool.

• Synced. The attribute lives in other systems: HR, discovery, and ERP. An integration brings it into the CMDB and keeps it current. The CMDB holds a copy, but the other system owns it.

• Linked. The attribute lives in another system, and the CMDB does not copy it. It stores a reference to an ID and a URL that users click through to when they need the current value.

Every attribute in your CMDB follows one of these three patterns, whether you decided that consciously or not. To make this concrete, take a laptop. Its assigned user comes from HR and is Synced. Its cost and depreciation could be Held directly in your ITSM tool if it supports financial tracking, or Synced from your ERP. Technical configuration CPU, RAM, and OS are Synced from your MDM tool. Installed software is Synced from a software inventory. Location is Held. Warranty is Held if you track it, or Linked to a supplier portal if you'd rather click through.

Now, take a production server. The number of attributes is much bigger, 20~30 or higher. And every pattern is in play, often together. Owner and steward: Held. Cost: Held or Synced. Technical config and patches: Synced from discovery. Service mapping: Held. Application dependencies: Synced from APM. Backup and DR role: Held, or Linked to the business continuity register. Security and compliance status: Linked to the vulnerability scanner and GRC platform.

The point is this: the CMDB's job is not to own all the data. It is to know where each attribute lives, and surface it.

The wrong move is not to pick a pattern. The wrong move is to let data appear in your CMDB without anyone deciding which pattern applies. Because that is exactly what produces a CMDB nobody trusts.

The scope trap: should I include this?

Once you have the lens and the source-of-truth pattern nailed down, the scope question becomes tractable.

The most common question we hear from customers is "Should we include X in our CMDB?" The honest answer is always: it depends on which lens you picked.

Take laptops. In a Financial CMDB, yes, for depreciation. In an Asset CMDB, yes, they are assigned to users. In a Configuration CMDB, usually no. Laptops don't typically support a specific service the way a server does.

Take monitors as separate CIs. Financial: it depends on your capitalisation threshold. Asset: It depends on whether you track them individually. Configuration: monitors almost never have dependencies. Take SaaS subscriptions. All three lenses, yes. And this is often the missing layer in older CMDBs.

The pattern is clear: the same item gets different answers depending on the lens. This means the wrong question to ask is "Should we include monitors?" The right question is: "What decision would including monitors enable that we cannot make today?" If you cannot answer that question, do not include them. Because including something has a cost. And the cost is far higher than most people realise.

The hidden cost: scope is two-dimensional

Here comes the uncomfortable part. Every CI you add to your CMDB is a CI you must maintain forever. And so is every attribute on every CI.

A rough model for what maintenance actually costs, per CI, per year:

• Quarterly attribute audit takes about five minutes, four times a year. Twenty minutes.

• Annual deep re-validation takes about fifteen minutes.

• Change-driven updates take five to ten minutes per change that touches the CI.

• Lifecycle events like create and retire amortised, about five minutes.

• Source reconciliation scales with the number of attributes you have.

Add it up. In the middle case, you get roughly one hour per CI per year. More if you have many attributes. That means a CMDB with 10,000 CIs and moderate attribute depth carries a stewardship load of about 5 full-time equivalents. A CMDB with 40,000 CIs and comprehensive attributes carries a load of around 20 FTE or 40 FTE if you push the attribute depth further.

These numbers are illustrative, not benchmarks. Plug your own per-CI minutes into the model and see what you get. But the shape is real, and it is a shape most organisations never explicitly consider.

Which brings us to the principle worth writing on a wall:

If you include it, you must audit it.

A CI you don't audit is a CI nobody trusts. And as we said right at the beginning, that is exactly the symptom that brought us here.

So the question is not "can we track 40,000 CIs?" The question is: "Do we have 20 FTE we would rather assign to stewardship than to delivery?" For most organisations, the answer is no. Which means the scope is not free.

Symptom #2 Discovery should be updating this for us

Third symptom. This one is technical.

You bought an auto-discovery tool. It is running. The CMDB is filling up automatically. And somehow the CMDB is getting less useful over time, not more. New CIs appear without any business context. Old CIs never leave. The relationships shown are technical, which connect to what on the network, not business, which support what service.

More data. Less meaning.

This is the auto-discovery myth. Discovery is necessary. But it is never sufficient.

Discovery does some things very well. It finds what is on the network. It captures technical attributes: OS, version, and capacity. It detects changes. It maps network adjacency. These are real and valuable.

But there is a whole layer of information that discovery cannot see. It cannot tell you the business owner. It cannot tell you the criticality. It cannot tell you what service the CI supports. It cannot tell you the lifecycle stage planned, live, or retired. And most importantly, it cannot tell you why the CI exists.

Discovery is a feed. It is not a strategy. Discovery without governance produces a noisy inventory. Not a CMDB.

What actually works and what the frameworks eventually agreed on

If you strip away the tooling, five things separate sustainable CMDBs from unsustainable ones.

• A source of truth per CI type. Not one tool for everything. Federated design, deliberate patterns per attribute.

• Reconciliation rules. When two sources disagree, you know which one wins and how the disagreement is logged.

• Process integration. Every Change, every Incident, every Request touches the CMDB as a side effect of doing the work, not as a separate task afterwards.

• Stewardship. Each CI class has a named owner. Not "the CMDB team", a specific role, or a specific person.

• Decommissioning. This is the most-skipped lifecycle step and the single largest source of decay.

None of this is our invention. It is where the ITIL frameworks landed after twenty years of watching practitioners learn the hard way.

In ITIL v2, v3, and 2011, all of this was bundled into one process called SACM Service Asset and Configuration Management. One process, serving two very different masters. The result was always a compromise: either the CMDB became a glorified fixed-asset register, or it became disconnected from financial reality.

ITIL 4, released in 2019, deliberately split SACM into two distinct practices:

• IT Asset Management lifecycle, cost, contracts, compliance.

• Service Configuration Management relationships, service composition, and impact.

They share data. But they do not share purpose, cadence, or audience. They are siblings, not synonyms. ITIL Version 5, released in February 2026, preserves this split. The lesson is now well-established.

Five key takeaways

If you take nothing else from this post, take these five.

1. Name your primary purpose before designing CI classes. Financial, Asset, or Configuration, pick one. Federate the other two into their own layers.

2. Federate, don't conflate. For every attribute, decide the pattern: Held, Synced, or Linked. Write it down. Make it a design decision, not an accident.

3. Every CI class needs a consumer and a steward. If you can't name both, the class does not belong in your CMDB.

4. Discovery is a feed, not a strategy. Governance sits on top of the feed. Without it, you have an inventory, not a CMDB.

5. Treat IT Asset Management and Service Configuration Management as siblings, not synonyms. They share data. They don't share a purpose.

If you would like to see how Marval MSM supports each of these principles, the native modules that make Held work, the integrations and staging tables that make Synced work, and the reference fields that make Linked work, you can contact us, and we can schedule a consulting or demo session for you.