CMDB Best Practices

What Is a CMDB and Why It Matters

A Configuration Management Database (CMDB) is a repository that stores information about the significant components of your IT environment—hardware, software, services, people, documents—and, critically, the relationships between them.

You probably already know this. You're here because you know you need one, or you have one that isn't working. The short version of why it matters:

• Incident response: "This server is down—what business services are affected?" A CMDB answers that in seconds instead of hours.
• Change management: "If we patch this database, what breaks?" Without a CMDB, you find out in production.
• Cost visibility: "What do we actually own, and who's using it?" The alternative is discovering forgotten assets at audit time.
• Compliance: ISO 20000 and ITIL both expect you to maintain a configuration management system. Regulators expect you to know what you have.

The CMDB isn't a project. It's a practice. The database is just where the data lives. The value comes from the processes and habits built around it.

Start Small, Iterate

The single most common CMDB failure mode is trying to model everything on day one. Gartner has repeatedly noted that organisations that attempt a "big bang" CMDB rollout have failure rates above 70%. The ones that succeed start narrow and expand based on demonstrated value.

The Phased Approach

Each phase should deliver value before the next one starts. If Phase 1 doesn't help anyone do their job better, there's no point adding more data.

Deciding What to Track (CI Scope)

Not everything needs to be a configuration item (CI). The ITIL framework defines a CI as any component that needs to be managed in order to deliver an IT service. The key word is managed—if nobody is going to maintain the data, don't track it.

The Scope Decision Framework

Business Services vs. Infrastructure

A common debate: should you start top-down (business services) or bottom-up (infrastructure)?

Top-down wins almost every time. Here's why:

• Business services are what leadership and customers care about
• Starting with services forces you to identify what actually matters
• You can add infrastructure details later as dependencies
• Bottom-up often produces a detailed inventory that nobody uses for service management

Start here:
  Business Service: "Customer Portal"
  ├── Application: "Portal Frontend"
  ├── Application: "API Gateway"
  └── Application: "Auth Service"

Then add infrastructure as needed:
  Application: "Portal Frontend"
  ├── Runs On: Server PROD-WEB-01
  ├── Runs On: Server PROD-WEB-02
  └── Uses Database: PROD-DB-PORTAL

Object Type Design Principles

Object types define the categories of things you track. Getting them right is foundational. We've written a detailed guide on this: Understanding Object Types in JSM Assets. Here are the strategic principles:

Design for the Question, Not the Asset

Before creating an object type, ask: "What question will this help us answer?"

If an object type doesn't contribute to answering a real question, you probably don't need it yet.

Keep It Flat Until You Can't

Start with flat object types. Add hierarchy (parent-child) only when you have clear inheritance needs. Hierarchy adds complexity, and in JSM Assets, attribute inheritance must be enabled at creation time. It's easier to add hierarchy later than to remove it.

Attribute Hygiene—Less Is More

Attributes are where CMDB bloat happens. Every field you add is a field someone has to fill in and keep current. Our Attribute Best Practices guide covers the mechanics. Here's the strategic view:

The 80/20 Rule for Attributes

In most CMDBs, 20% of attributes provide 80% of the value. The rest are either empty, stale, or never queried.

Relationships and Dependencies

The relationships between CIs are more valuable than the CIs themselves. A list of servers is an inventory. A map of which servers support which business services is a CMDB. See our Reference Types & Relationships guide for implementation details.

The Relationships That Matter Most

Don't try to map every possible relationship. Start with the two or three that directly support your primary use case.

Data Quality Over Quantity

A CMDB with 100 well-maintained records is infinitely more useful than one with 10,000 records where half are outdated. Data quality is the make-or-break factor, and it doesn't happen by accident.

Governance Basics

The Freshness Test

Run this quick check periodically:

1. Pick 10 random CIs from your CMDB
2. Verify each one against reality (is the server still running? Is the owner still in that role? Is the status correct?)
3. If more than 2 out of 10 are wrong, you have a data quality problem that needs addressing before you add more data

Common Anti-Patterns

These are the failure modes we see over and over. If any of these sound familiar, you're not alone—but you should fix them.

Anti-Pattern 1: The Spreadsheet Dump

What happens: Someone exports a spreadsheet of all assets from procurement, HR, or a network scanner and imports the whole thing into the CMDB.

Why it fails:

• The data was collected for a different purpose, with different definitions
• Columns become attributes that nobody understands
• No relationships—just flat records with no connections
• Duplicate and conflicting entries from different sources
• Nobody owns the imported data, so it goes stale immediately

What to do instead: Design your schema first. Then selectively import the data you actually need, mapping it to your defined object types and attributes. Clean the data before it goes in, not after.

Anti-Pattern 2: Model Everything

What happens: The CMDB project tries to capture every asset, every attribute, every relationship across the entire organisation before going live.

Why it fails:

• Takes months or years before anyone sees value
• Scope creep kills momentum and budget
• Data is stale by the time the model is "complete"
• The team burns out before Phase 1 delivers anything useful

What to do instead: Pick one use case. Build the minimum schema to support it. Demonstrate value. Expand. This is the phased approach described above.

Anti-Pattern 3: Build and Forget

What happens: A CMDB is built, populated once, and then never updated. Six months later, nobody trusts the data.

Why it fails:

• IT environments change constantly—servers are added, applications are retired, teams are restructured
• Without ongoing maintenance, data drift is inevitable
• Once trust is lost, people stop using the CMDB and build their own shadow spreadsheets

What to do instead: Integrate CMDB updates into your existing processes. New server deployment? Update the CMDB. Application decommissioned? Archive the CI. Team restructured? Update ownership. The CMDB is a living system, not a one-time project.

Anti-Pattern 4: The God Schema

What happens: One object type called "Asset" or "CI" with 80+ attributes to cover servers, laptops, software, contracts, and anything else.

Why it fails:

• Most attributes are empty for most records
• Forms are overwhelming and confusing
• You can't enforce meaningful validation
• Reporting becomes a mess of filters and exceptions

What to do instead: Create distinct object types for distinct things. A Server and a Software License have almost nothing in common—don't force them into the same type. See Understanding Object Types for the full guidance.

Anti-Pattern 5: Ignoring Relationships

What happens: A CMDB full of well-maintained records, but no relationships between them.

Why it fails: Without relationships, you have an asset inventory, not a CMDB. You can answer "what do we have?" but not "what happens if this fails?" or "who is responsible?" The relationships are where the real value lives.

What to do instead: Model ownership and service dependencies from day one. See Reference Types & Relationships.

Federation—You Don't Need Everything in One Place

One of the most liberating ideas in modern configuration management is federation: the CMDB doesn't have to contain every detail about every asset. It can point to authoritative sources.

What Federation Looks Like

CMDB (your source of truth for relationships and ownership):
  Application: "Customer Portal"
  ├── Owner: Engineering Team
  ├── Depends On: Auth Service, API Gateway
  ├── Status: Active
  └── Monitoring Dashboard: [URL to Datadog]

Cloud Console (source of truth for infrastructure details):
  EC2 instances, networking, storage configs

HR System (source of truth for people):
  Employee records, reporting structure, departments

Monitoring Tool (source of truth for runtime state):
  Uptime, performance metrics, alerts

Federated vs. Centralised

What to Keep in the CMDB

• Relationships between CIs—this is what no other system provides
• Ownership—who is accountable for each CI
• Status and lifecycle—is this CI active, planned, or retired?
• Classification—type, criticality, environment
• Links to external systems—monitoring URLs, wiki pages, cloud console links

What to Leave in Specialised Systems

• Real-time metrics—keep in your monitoring tool
• Detailed cloud configs—keep in the cloud console
• Code and deployment details—keep in your CI/CD pipeline
• Employee personal data—keep in HR systems
• Financial transactions—keep in finance/procurement systems

Measuring Success—How to Know Your CMDB Is Working

A CMDB that nobody can prove is valuable will eventually lose funding. Measure it. Here are metrics that actually mean something:

Leading Indicators (is the data any good?)

Lagging Indicators (is it delivering value?)

Review these metrics quarterly. If accuracy is falling, investigate why. If usage is low, find out what people are using instead—and either integrate that or improve the CMDB to meet their needs.

Summary: The Principles That Work

The CMDB that works is the one people trust. Trust comes from accuracy. Accuracy comes from scope discipline, data governance, and making updates part of how your team already works—not an extra chore.

Sources / Further Reading

• Atlassian — Configuration Management Database Guide — Atlassian's overview of CMDB concepts and their role in ITSM
• ITIL (Information Technology Infrastructure Library) — The de facto standard for IT service management, including CI definitions and the CMS concept
• IT Process Maps — Service Asset & Configuration Management — Community reference for ITIL configuration management processes
• Virima — CMDB Best Practices — Industry perspectives on data quality and phased rollout
• InvGate — CMDB Best Practices & Expert Advice — Practical CMDB optimisation advice focusing on starting small and prioritising accuracy
• Beyond20 — Maximizing CMDB ROI — Analysis of CMDB implementation strategies and finding return on investment
• Navvia — Configuration Management Best Practices — Process design and data governance guidance
• CloudAware — CMDB Best Practices — Cloud-focused implementation guidance for hybrid infrastructure
• SMC Consulting — CMDB Implementation — Consulting perspective on implementation methodology and common pitfalls
• ITSM.tools — CMDBs for IT Services — The evolving role of configuration management in modern IT service delivery
• ISO/IEC 19770 — IT Asset Management — International standard for IT asset management
• Atlassian — Managing Assets in JSM Cloud — Official support docs for configuring Assets in JSM

For a complete list of sources used across this site, see Sources & Attribution.