CMDB Best Practices for Enterprise IT
The CMDB is the foundation of every ITSM practice. When it's accurate, Incident resolution is faster, Change risk is lower, and Problem management has reliable data. When it's wrong, everything built on top of it fails.
Most CMDBs are accurate at go-live and degraded within 6 months. This guide explains why — and how to prevent it.
The #1 CMDB anti-pattern: Populating it manually from spreadsheets, with no automated discovery. Manual data is stale before the migration is finished.
Design Principles
1. Scope before you populate
Define which CI classes you need for your top 5 critical services. Start there. A CMDB with 200 well-maintained CIs beats one with 50,000 stale records.
2. Discovery first, manual second
Use automated discovery (ServiceNow Discovery, Device42, Lansweeper) to build the baseline. Manual data entry is only for CIs that cannot be discovered — physical infrastructure in locked DC, network devices with non-standard SNMP.
3. Align to the CSDM
The ServiceNow Common Service Data Model defines the relationship hierarchy:
Business Application
└── Application Service
└── Technical Service
└── Infrastructure CI (Server, Network Device, Storage)Build your CI relationships to reflect this hierarchy, not flat lists.
Maintaining Accuracy
Run discovery on a schedule
Weekly for servers, daily for network devices, monthly for storage. Discovery cadence should match the rate of change.
Implement CI lifecycle states
Use states: In Use, Maintenance, Decommissioning, Retired. A CI in Retired state with no relationships is a candidate for archiving.
Tie Change Management to CMDB
Every approved change that affects infrastructure must update the relevant CIs. Make this a mandatory step in your Change closure workflow.
Quarterly CMDB health reviews
Run automated reconciliation reports. Flag CIs not updated in 90 days. Assign ownership. CIs without owners degrade fastest.
Written by Digital Kimya — Book a CMDB architecture review → (opens in a new tab)