Why the registry is needed

The benefits become concrete in three scenarios.

When something is down. You immediately see which services are affected and which users are impacted, instead of relying on someone remembering how the systems are connected.

When something needs to change. A planned change can be risk-assessed against actual dependencies rather than guesses. This is also why change management without a CMDB becomes a formality rather than a risk assessment.

When someone asks what you have. During audits, procurement, insurance matters, or license reviews, an up-to-date registry is the difference between an immediate answer and a week of work.

What should be in the registry?

A configuration item is anything that can change and affect a service. The question is not what can be registered, but what is worth keeping up to date.

A useful test: would you need to know this exists when something breaks at two in the morning? If the answer is no, the object belongs in the inventory list, not the CMDB.

Start from the top: define the services the business actually uses, and work your way down to what they depend on. Doing the reverse—starting by inventorying all hardware—just gives you a long list without any context.

Dependencies are the whole point

A list of servers is just an inventory. What makes a CMDB worth the effort is the connections between the objects.

Three relationships provide most of the value: what a service runs on, what it depends on to function, and which users or customers are affected if it stops responding.

With those three in place, you can both assess risk before a change and pivot quickly during an outage. Without them, you just have a spreadsheet with more columns.

The most common trap

Most CMDB projects fail for the same reason: the ambition to document everything.

A register that tries to describe every component in detail is never finished, and eventually, people stop trusting it. A register that cannot be trusted isn't used, and then it becomes obsolete even faster.

Start with the services that would bring the business to a halt if they stopped working. Expand only when there is a concrete need.

Keep it alive automatically

What determines whether a CMDB survives is not how it is built, but how it is maintained.

Connect it to the monitoring tool, the directory service, and the documentation system so that the baseline data updates itself. Anything that requires manual entry will become outdated—it is only a matter of how quickly.

Automatic discovery only solves half the problem, however. The tools find what exists, but not what it is used for or who depends on it. That part requires a human decision, which is why the register needs an owner even when the input is automated.

The lifecycle

Asset management follows equipment from purchase to decommissioning: inventory, warranty periods, license renewals, and decommissioning with documented data erasure.

The final step is the one most often forgotten, and the one that becomes most expensive when it is. A decommissioned server left in the register provides a false sense of security; one decommissioned without documented erasure creates a problem during the next audit.

Renewal dates are the second item that usually catches people out. Licenses and support agreements that auto-renew for systems no longer in use are a recurring and completely unnecessary expense.

Two numbers that tell you if it works

What percentage of your changes can be risk-assessed against the registry? If the answer is low, the CMDB isn't being used in practice, regardless of how complete it looks.

How often is it accurate during spot checks? Check ten randomly selected items per quarter. It takes half an hour and provides a more honest answer than any report.

For MSPs

With many customer environments, the requirements change. The registry must keep customers separate, handle the fact that the same vendor product looks different for different customers, and be able to answer which customers are affected when a shared service goes down.

Baseline data should be pulled from PSA and RMM, which already know which customers and devices exist. Building the registry manually for each customer is a task that is never finished.