CMDB course: ten lessons on keeping a configuration record accurate

Lesson 1 of 10

A CMDB is the record IT work runs on: which configuration items exist, how they connect and what changed. It is not automatically a complete inventory, and treating it as one is where most data quality trouble starts.

3 min read

Lesson 2 of 10

CMDB records rarely go wrong in one dramatic failure. They drift through five ordinary patterns: missing assets, ghosts, duplicates, stale fields and lost owners. Each one needs a different fix.

3 min read

Lesson 3 of 10

IT asset management counts what you own and pay for; configuration management records what you run and how it connects. The two lists overlap but never match exactly, and confusing them is a common source of CMDB disputes.

3 min read

Lesson 4 of 10

There are three automatic routes into a configuration record: the CMDB's own discovery, network discovery tools that feed it, and platforms that reconcile data from tools you already run. Most mature setups combine two of them.

3 min read

Lesson 5 of 10

No single tool is right about everything. A trustworthy record picks a source of truth for each field, not for each tool: the MDM for the serial number, the directory for the user, the EDR for agent health.

3 min read

Lesson 6 of 10

Duplicates appear when two sources describe one device with different keys. Matching on stable hardware identifiers, with hostnames and IP addresses as supporting evidence only, removes most of them.

3 min read

Lesson 7 of 10

A record with no owner stays wrong. The reliable way to assign owners is to pull them from systems that already know, such as identity directories, HR systems and the service catalog, rather than asking people to fill in a field.

3 min read

Lesson 8 of 10

A corrected record that never reaches the CMDB changes nothing. Writing back automatically is powerful, so start with creating missing records, add updates field by field, and leave retirement for last with a review step.

3 min read

Lesson 9 of 10

Accuracy needs a few simple, repeatable measures: coverage against trusted outside lists, a sampled correctness rate, duplicate and ghost counts, owner coverage and record age. Track them monthly and publish them to the teams who use the record.

3 min read

Lesson 10 of 10

A pilot should test one option against your own estate and your own measures, not against a demo. Thirty days is enough to see coverage, matching, owners and sync, if you prepare the sources and the baseline first.

3 min read