Health Check vs. Healthy
Is your CMDB health dashboard telling the truth? A mid-sized pharmaceutical company's CMDB scored well on the dashboard's default completeness and duplicate rules. Reconciled against its discovery tools, half the estate was not what the scores said it was.
- 154 → 9
- Duplicate groups in production
- 1,180
- Retired devices still marked Installed, invisible to any dashboard
- 1,405 of 2,835
- Devices seen by no discovery tool
- 1,550
- Records through one governed import path in the first cycle
What the health scores could not see
The customer runs ServiceNow ITSM and CMDB with CSDM on the roadmap. Four discovery tools fed it, and a legacy configuration-manager connector wrote straight into production. Pomeroy Technologies, the ServiceNow implementation partner, was asked to make the CMDB something the business could trust for CSDM, incident routing and licence counts.
ServiceMatch was deployed as one virtual machine inside the customer's own cloud subscription. SwipeLeft holds no connection to it. The production CMDB extract was loaded beside the four discovery exports and reconciled. After the first cycle, scored on three of the CMDB Health dashboard's rules at their default configuration, the estate looked fine. Reconciled against the tools, it did not.
| Measure | Scored the way a dashboard scores | What the reconciliation found |
|---|---|---|
| Completeness | Required fields filled on 100% of records. The default scores one field, name. Declare the six fields the business needs and the same dashboard reads 55%. | Of 111,020 CIs, 97% are adapters, disks and software. Real devices: 2,835, so the score only means something per class. Half the devices have no location. The dashboard shows the gap the moment it is told which fields matter. Nobody had told it. |
| Correctness | 0.3% duplicate records. | 1,278 devices say Retired in one lifecycle field and Installed in the other. Seven servers exist twice, retired with a serial and live without one, so a serial-based duplicate rule never pairs them. Half the estate is retired or live depending on which report you open. |
| Staleness | Recently updated, almost all of them. With no ServiceNow Discovery in the estate, fresh means a connector wrote the row. | 1,405 of 2,835 devices are seen by no tool. 1,180 were retired by the connector, which kept refreshing the record until the feed was cut, so they never looked stale. 32 marked Retired are live and monitored. Patching, licences and refresh are budgeted for 1,405 machines that are not there. |
The dashboard scores were never wrong. A health dashboard measures the CMDB against itself. Two limits are structural: it cannot score records that are not there, such as the 208 devices the tools see and the CMDB lacks, and it measures freshness by writes, not by whether the device exists. The rest are configuration: which fields it scores, which identifiers its duplicate rule compares, whether any audit checks a record against itself. Nobody configures those until a second source shows the gap. Meanwhile every number reported about the estate is off by about a thousand machines: 1,210 of 1,211 Windows 10 records have been seen by no tool in months.
Nor could the tools have agreed among themselves. Each had a defect in the one field it uses to identify a device: infrastructure monitoring had no usable serial on 642 of 778 rows, the digital-experience agent put a motherboard UUID in the serial column on 623 of 625, and the asset register put the hostname there on 140. Two tools wrote hypervisor serials two ways, so the same VM never paired.
What changed
One governed writer into ServiceNow. The first production extract showed the legacy connector still writing beside the governed imports. The customer retired the feed. Every record now passes through ingest, normalise, identity scoring, classification and CSDM cascade, and lands in a decision ledger before it lands in ServiceNow. The first governed import carried 1,550 rows. Cycle one shipped 977 of 1,132 candidates, every exclusion ledgered.
The cause of the duplicates, not the duplicates. The 209 duplicate pairs were earlier update rows that ServiceNow's transform had inserted as new records beside the originals. The pipeline traced the writer and delivered a keep/delete recommendation per pair, gated on a test batch before any full load. Duplicate groups went from 154 to 9. The nine that remain are retired pairs already on the retire list.
A fix file on every finding. The first review ranked five fixes Critical, each with a count, a consequence, an action and an owner: 1,180 retired records to set Retired, 32 live servers to set Operational, 7 VM pairs to merge, 238 unclassified network devices to classify, 225 unseen live devices to confirm and retire. Each ships in import-set shape: sys_id, current value, proposed value, reason. The 1,180 were listed for the CMDB owner. The 32 servers were corrected. The ledger records who decided what, and why.
The remediation stays with the partner. Pomeroy led the engagement, owned the customer relationship, and owned the remediation labour: adjudicating pairs, executing retirements, loading each cycle into Test before Production. SwipeLeft owned the platform. Every finding above is billable partner work with the evidence already attached.
"This CMDB would have passed any health check we ran against it. What no dashboard could tell us was that 1,180 retired machines were still marked Installed, or that the duplicates were coming from the import itself. ServiceMatch gave us that as fix files my team could load, not a list of findings to go and investigate."
Rene Head, SVP, Pomeroy Technologies
Results
- Writers into the CMDB: two to one, governed
- Duplicate groups in production: 154 to 9
- 1,550 rows in the first governed import; cycle one 977 of 1,132, every exclusion ledgered
- 1,180 retired-but-installed devices listed by sys_id; 32 retired-but-live servers corrected
- One identity-field defect documented per discovery tool, with the fix in the mapping
- A recorded rationale on every import, exclusion and rule decision
Bring us a health report. Bring a customer's ServiceNow health report, a CMDB extract and two or more discovery exports. We reconcile them inside a server the customer owns and hand back the findings with real counts and the fix files. The report either survives contact with the evidence or it doesn't. Write to info@swipeleft.ai, or download this case study as a PDF.
Customer: a mid-sized pharmaceutical company, United States, 2,835 devices under management. Counts are from the live engagement, pseudonymised. Dashboard-style scores are SwipeLeft's measurement of three CMDB Health rules (required fields, recommended fields, serial-based duplicates) at default configuration on the customer's September production extract; no customer health report was run. Series: One Import Path.