ServiceNow CMDB Data Quality Services: Treat the CMDB as a Product or Watch It Rot

A platform owner at a European insurer called me on a Tuesday morning with a question that sounded simple. He wanted to know why his change advisory board kept approving changes to CIs that had been decommissioned eighteen months ago. His CMDB said the servers were live. Discovery said the servers were live. The datacentre said the servers were scrap. Somebody was lying, and the board was signing off on ghosts.

I told him this was not really a data problem. It was an ownership problem wearing a data costume. His CMDB had four different teams contributing records, no product owner, no reconciliation rules that anyone could name out loud, and a Discovery schedule that had last been tuned in 2022. The result was exactly what you would expect. A large expensive table full of half-truths that nobody trusted enough to use for a decision and nobody owned enough to fix.

This is the pattern I see almost every time a mid-market or enterprise buyer asks for ServiceNow CMDB data quality services. The instinct is to reach for a tool, a bulk cleanup script, a consultant with a checklist. What is actually needed is a product mindset. A CMDB is not a database. It is a product with users, a roadmap, an SLA, and a person whose job it is to say no when someone wants to import ten thousand rows from a spreadsheet on a Friday afternoon.

Why CMDBs rot in the first place

The rot never starts in the CMDB itself. It starts upstream, in the decisions nobody made when the platform went live. Somebody agreed that any team could create CIs. Somebody else added a Discovery schedule that ran on Sundays and never got tuned again. A third team ran an import from a legacy asset management tool and mapped attributes by hand, at midnight, because the go-live date was Monday. Three years later you have three different truths about the same server, and the reconciliation rules are silently picking whichever one arrived last.

The other reason CMDBs rot is that nobody owns them. In most organisations I audit, the CMDB is technically owned by ITSM, operationally owned by nobody, and blamed by everybody. Change management complains that they cannot see impact. Incident complains that assignment routing is wrong. Problem complains that they cannot correlate incidents to the same CI. Each team is right. None of them are willing to be the product owner.

And then there is the class model. ServiceNow ships with hundreds of CI classes out of the box. Most instances I see have extended that model with another fifty custom classes that were added for one project and never retired. Nobody remembers what half of them mean. Attributes overlap, mandatory fields are inconsistent, and the CI Class Manager still shows two identical classes with slightly different names because a consultant added one in 2021 and the client added the other in 2023. This is not a data problem. It is an architecture problem that produces bad data as a side effect.

Treating the CMDB as a product, not a table

The single biggest shift that fixes CMDB rot is treating it as a product. That means it has a named owner who is accountable for its quality. Not a committee. Not a working group. One person with a job description that includes CMDB health. In practice this is usually the platform architect or a dedicated CMDB manager for larger estates.

It means the CMDB has users, and those users have needs. Change management needs impact analysis. Incident needs routing. Vulnerability response needs software inventory. Executive reporting needs application-to-business-service mapping. Each of these is a use case with a definition of done. If your CMDB cannot answer the top five questions those teams ask on a weekly basis, it is failing its users and you can measure that failure.

It means the CMDB has a roadmap. Which classes are in scope this quarter. Which reconciliation rules get tuned next. Which integrations are onboarded, which are retired. The roadmap is boring, it is short, and it is public inside the organisation. That last part matters. Half the reason CMDBs rot is that nobody knows what is being worked on, so everybody assumes nothing is being worked on, so everybody stops trusting it.

And it means the CMDB has an SLA. Not a formal contract, but a stated commitment. Servers discovered by Discovery within seventy-two hours of provisioning. Retired CIs marked retired within seven days of decommissioning. Business services reviewed quarterly. Software installations reconciled monthly. If you cannot state your SLA in one page, you do not have a CMDB product. You have a CMDB hobby.

Discovery is a garbage-in problem, not a fire-and-forget one

Almost every rotten CMDB I audit has a Discovery configuration that nobody has looked at in two years. It runs. It brings in data. Nobody validates that it is bringing in the right data, and nobody notices when it stops.

Good Discovery hygiene starts with knowing what Discovery is supposed to find. If you have three datacentres, four cloud tenants, and a hybrid pattern of on-prem and SaaS, Discovery needs a schedule and a scope for each. MID Servers need to be sized, patched, and monitored. Credentials need to be rotated. Probes need to be tuned so you are not paying compute time for classes you do not use. And Discovery status dashboards need to be visible to someone whose job it is to look at them on Monday morning.

The most common failure I see is Discovery running as if it were a background job. It brings in data, it silently fails on half the targets, and no alert fires because the pattern of partial success is indistinguishable from full success at a table-count level. You have to build the health checks yourself. How many CIs discovered this week versus last week. Which patterns errored. Which MID Servers missed their windows. This is basic operational discipline, and most instances I audit have none of it.

Service Mapping is the other half of Discovery. Discovery tells you the boxes. Service Mapping tells you what runs on them and how it connects to the business service that pays the bill. Without Service Mapping, your CMDB knows about servers but cannot answer the question a CFO actually asks. Which applications go down if this thing dies. Which business services are affected by that change. Which customer contracts depend on that database. Service Mapping is the layer where CMDB stops being an IT tool and starts being a business tool. It is also the layer that almost everyone skips because it is harder than Discovery and requires application owners to actually turn up.

Reconciliation, class discipline, and the CI life cycle

Once Discovery is behaving and Service Mapping is in place, the third leg is CMDB governance at the record level. This is where most cleanup projects live and die. The core disciplines are reconciliation rules, class curation, and a proper CI life cycle.

Reconciliation rules decide who wins when two sources disagree about the same CI. In a healthy CMDB, those rules are documented, versioned, and reviewed. In most CMDBs I see, they are the default settings from go-live plus a few emergency overrides added during incidents. Rewriting them takes a workshop and a decision matrix. Which source is authoritative for hostname. Which is authoritative for owner. Which for install status. Which for operational status. If you cannot answer these questions in a table on one slide, your CMDB is running on hope.

Class discipline is about keeping the CI class model small enough to reason about. Every custom class needs a justification, an owner, a set of mandatory attributes, and a retirement plan for the day nobody uses it any more. Most instances I audit have never retired a custom class. The list only grows. Six months of curation on the class model produces more trust in the CMDB than any bulk cleanup script ever will.

The CI life cycle is where most CMDBs quietly leak. A server goes into procurement. It gets provisioned. It gets discovered. It runs for four years. It gets decommissioned. In a healthy CMDB, every one of those transitions updates the CI state and triggers downstream actions. In a broken CMDB, decommissioned servers stay in an installed state forever because nobody wired the retirement workflow, and every subsequent audit gets slower and less trustworthy.

Where to start, practically

If you are looking at your own CMDB and recognising the pattern, here is the sequence I would run.

Name the product owner this week. Not a committee. One person. Write it down. Give them fifteen percent of their time back to do the work. Without this, nothing else will stick.

Run a one-page CMDB health assessment. Count CIs per class, compare against expected. Check Discovery success rates over the last thirty days. Sample fifty change records and see how many CIs referenced are still valid. This gives you the honest starting position.

Pick the top three use cases that matter most this quarter and make the CMDB fit for those. Do not try to fix everything. Impact analysis for change, routing for incident, and software inventory for vulnerability response is a common triad. Fix those, prove the value, then expand.

Tune Discovery and get Service Mapping running against your top ten business services. Not fifty. Ten. Prove you can keep them accurate before scaling.

If you want an outside read on where the rot sits, the Milic Media 10-Day Instance Health Report includes a full CMDB dimension with class model review, Discovery health, reconciliation audit, and a prioritised backlog against a defined data quality standard. It is a fixed-fee diagnostic that turns a vague suspicion that your CMDB is not trustworthy into a specific list of moves you can hand to the platform owner on Monday. If you want to see the pattern of engagements we deliver around this, our services page walks through the shape of the work.

The CMDB rewards the people who treat it as a product with an owner, a roadmap, and an SLA. It punishes everyone else with ghosts, bad routing, and change advisory boards that approve fictions. Which one you get depends less on the tool and more on the discipline. That is uncomfortable news for anyone hoping a cleanup script will save them, and it is the honest starting point for any real conversation about ServiceNow CMDB data quality services.

Mladen Milic runs Milic Media Kft, a boutique ServiceNow consultancy delivering implementation, health audits and HRSD work across the EU. Reach him at mladen@milicmedia.com.