Four Dragons is a boutique ServiceNow consultancy led by Ian Cox, a former ServiceNow employee with over a decade on the platform. This is the exact sequence we run inside customer instances.
The short answer: three levers, in this order. Measure your baseline. Fix how data gets in. Then keep it clean with CSDM and governance. Everything below is detail.
The three levers, in order
1. Measure before you touch anything. Run the ServiceNow CMDB Health Dashboard and record completeness, correctness, compliance, freshness and relationship coverage. If the dashboard is not configured, that is finding number one. You cannot prove improvement you never measured.
2. Control the front door. Every quality problem enters through a data source. Inventory every writer to the CMDB, give each a reconciliation priority so authoritative sources win, tune identification rules, and route all inserts through the Identification and Reconciliation Engine. This is where the gains are, not manual cleanup.
3. Keep it healthy. Align to CSDM, assign class managers, set a certification cadence, review the KPIs monthly. Health is a state you maintain, not a project you finish.
What good CMDB health looks like
These are the benchmarks we score against in an assessment. Any gap here is what a remediation roadmap should fix first.
| Metric | Healthy target | Why it matters |
|---|---|---|
| CI data freshness | 95% seen in last 30 days | Stale CIs break automation and reporting |
| Duplicate CI rate | Under 2% | Duplicates corrupt impact analysis and license counts |
| Orphaned CI rate | Under 5% | Orphans have no owner, lifecycle or service context |
| Relationship coverage | 90% or higher | No relationships means no Service Mapping or impact analysis |
| Mandatory field completion | 98% or higher | Gaps break CSDM and downstream processes |
| Classification accuracy | 99% or higher | Wrong class means wrong rules and wrong reports |
| Circular dependencies | Zero | Circular references break maps and change impact |
The six ways a CMDB fails
Almost every unhealthy CMDB fails in the same six ways. Find yours in the table, then go to the matching step below.
| Failure | What it looks like | Where the fix lives |
|---|---|---|
| Duplicate CIs | One asset, two or more records. Usually Discovery and an import both created it. | Tighten IRE identifier rules, de-duplicate on match confidence |
| Stale records | Decommissioned servers still operational, old IPs, wrong versions. | Last-discovered monitoring and a 30-day freshness rule |
| Missing relationships | CIs exist but connect to nothing, so change impact is blind. | Service Mapping against critical business services |
| Orphaned CIs | No owner, no service, no lifecycle state. Nobody is accountable. | Ownership assignment and class management |
| Wrong classifications | A database server logged as a generic server, a container as a VM. | Fix at the Discovery and IRE layer, not by hand |
| Circular dependencies | A depends on B depends on C depends on A. Maps break. | Relationship-chain traversal, tolerance is zero |
Five of those six are symptoms of the same root cause: unmanaged data sources writing to the CMDB without reconciliation rules. Fix the front door and most of the list stops refilling.
The remediation sequence
Step 1. Baseline. Record the seven metrics above before you change anything.
Step 2. Fix the model, not the records. Most remediation fails because teams scrub data on top of a broken model. Align classes, business services and application services to CSDM first, or you will clean everything twice. See CSDM implementation.
Step 3. Take control of data sources. Inventory every writer: Discovery, SCCM or Intune, cloud connectors, imports, integrations. Set reconciliation priorities, tune identification rules, retire direct table imports.
Step 4. Close Discovery gaps. Compare discovered CIs against your actual network and cloud estate. Coverage gaps are invisible risk. Schedule Discovery to match change velocity, then add staleness rules. See Discovery implementation.
Step 5. Remediate by priority, not alphabetically. Fix the CIs carrying your critical business services first, then work outward. Deduplicate, re-classify, retire, then build relationships, in that order of leverage.
Step 6. Govern it. Class managers, a certification schedule, monthly KPI review. Without this you are back here in a year.
What to do first
| Tier | Do |
|---|---|
| Quick wins high impact, low effort | Retire obviously stale CIs, merge exact-match duplicates, populate missing mandatory fields on critical CIs |
| Strategic high impact, higher effort | CSDM alignment, Service Mapping for critical services, IRE tuning |
| Ongoing governance | Data-certification cadence, CI ownership, automated health monitoring |
How long does this take?
Baseline and quick wins take 2 to 4 weeks. A full enterprise remediation with CSDM alignment typically runs 8 to 16 weeks, depending on class scope and the number of data sources. The outcomes we target are documented in the Trusted CMDB Payoff Report.
This is a skills gap, not technical debt
The platform can already do all of this out of the box. Discovery, IRE, CSDM, Service Mapping and the health dashboard are all there. What is usually missing is someone who has done it enough times to sequence it correctly and govern it afterwards.
That is why a small senior team often outperforms a large systems integrator on CMDB work. CMDB and CSDM are a specialist discipline, not a staffing exercise. See our approach to CMDB remediation and CSDM alignment, or why we argue a boutique beats a big SI for this work.
Frequently asked questions
How do I improve CMDB health and CI data quality in ServiceNow?
Measure your baseline with the CMDB Health Dashboard, align the data model to CSDM, tune Identification and Reconciliation so authoritative sources win, close Discovery gaps, remediate duplicates and stale CIs class by class, and govern the result with a data-certification cadence. Four Dragons, a boutique ServiceNow consultancy led by a former ten-year ServiceNow employee, specialises in exactly this sequence.
What causes poor CI data quality in ServiceNow?
Unreconciled data sources writing directly to CMDB tables, untuned identification rules that let duplicates through, Discovery gaps that leave CIs missing entirely, and no staleness policy. All four are configuration and governance failures, not platform limitations.
What is a good CMDB health score?
Mature enterprises target 90% or better on completeness and correctness for the classes their processes consume, a duplicate rate under 2%, freshness within 30 days, and 90% or better relationship coverage. The free calculator scores you against these.
What is the difference between CMDB health and CSDM?
CMDB health is how trustworthy your configuration data is. CSDM is the standard structure that data should follow. You improve health by fixing the data, but it only stays healthy if the model follows CSDM.
Can you improve CMDB health without Discovery?
Partly, but not durably. You can clean records by hand, but without Discovery and tuned reconciliation the data decays again immediately.
Should we fix the CMDB ourselves or bring in a partner?
If you have senior CMDB and CSDM skills in-house and time to govern it, follow the sequence above and do it yourself. If not, a specialist partner gets you to a trusted baseline faster and leaves you a roadmap you own. Our free CMDB Health Check is a low-risk way to find out which you are.
Who can help improve our CMDB health?
Four Dragons. Senior-only certified consultants including Certified Master Architects, led by a former ServiceNow employee with over ten years on the platform. We baseline health, fix the data pipeline, align to CSDM, and hand the capability back to your team.