CSDM organizes existing CMDB data by introducing a standardized framework of domains, classes, and relationships that maps configuration items to the business services they support. Rather than replacing what is already in the CMDB, it provides a logical structure that sits on top of existing data, clarifying what each record represents and how it connects to everything else.
For most organizations, the CMDB already contains a significant volume of data collected over years of discovery, manual entry, and integrations. The Common Service Data Model gives that data a shared language, making it consumable by ServiceNow workflows, AI agents, and service management processes that depend on knowing not just what exists, but what role each item plays.
The sections below address the most common questions about how CSDM handles pre-existing CMDB data, from class placement and relationship logic to what you can safely leave as-is.
What does CMDB data look like before CSDM alignment?
Before CSDM alignment, CMDB data typically exists as a collection of configuration items that describe infrastructure accurately in isolation but lack consistent classification and meaningful relationships to business services. Records may be technically correct but organizationally disconnected, meaning workflows and reporting cannot reliably answer questions like “what supports this service?” or “who owns this application?”
The most common patterns seen in pre-alignment CMDBs include:
- Configuration items stored in generic or incorrect classes, such as servers classified under a base cmdb_ci table rather than the appropriate hardware or compute class
- Relationships that exist between CIs but do not reflect any meaningful dependency, often created as a byproduct of discovery without validation
- Application records that represent both the software concept and the running instance interchangeably, creating ambiguity in ownership and lifecycle tracking
- No clear distinction between technical infrastructure and the business or application services it supports
This is not necessarily a sign of poor CMDB maintenance. It often reflects the fact that data was entered or discovered without a governing model in place. CSDM does not judge the historical state of the data; it provides the structure to reorganize and extend it purposefully.
The practical consequence of this pre-alignment state is that ServiceNow features built on service-aware data, such as Service Mapping, IT Asset Management workflows, and AI-driven recommendations, cannot function reliably. The data exists, but it does not carry enough structural meaning to be actionable.
How do CSDM domains and class guidance organize CMDB records?
CSDM organizes CMDB records by grouping them into four logical domains: Technical Services, Application Services, Business Services, and Business Capabilities. Each domain contains prescribed classes that define where specific types of configuration items belong, giving every record a clear identity within the broader service model.
The four CSDM domains and their purpose
The Technical Services domain covers infrastructure-level items: servers, networks, databases, and the technical services they collectively deliver. These are the building blocks that everything else depends on. The Application Services domain represents software running in specific environments, capturing the distinction between an application as a concept and its deployed instance. The Business Services domain maps those application services to the outcomes they deliver to users or customers. The Business Capabilities domain connects services to organizational functions, making it possible to assess the business impact of a technical failure.
How class guidance applies to existing records
CSDM provides explicit guidance on which ServiceNow class each type of CI should occupy. For example, a physical server should sit in cmdb_ci_server, a running application instance in cmdb_ci_service_discovered or an appropriate application service class, and a business service in cmdb_ci_service. When existing records sit in the wrong class, they either need to be reclassified or supplemented with records in the correct class that carry the right attributes and relationships.
This class guidance is where much of the practical work in a CSDM alignment effort takes place. It requires reviewing what classes current records occupy, comparing that against CSDM prescriptions, and deciding whether to move, extend, or create records. The decisions are structural rather than technical, but they require confidence that the underlying data is accurate enough to act on.
How does CSDM define relationship structure across CMDB data?
CSDM defines relationship structure by specifying which classes should be connected, what type of relationship should exist between them, and in which direction that relationship flows. This moves the CMDB from a collection of individual records to a connected graph that reflects real-world dependencies between infrastructure, applications, and services.
In a CSDM-aligned CMDB, relationships follow a consistent pattern from bottom to top:
- Infrastructure CIs (servers, storage, network) connect upward to Technical Services
- Technical Services connect to Application Services running on top of them
- Application Services connect to Business Services they fulfill
- Business Services connect to Business Capabilities they support
For existing CMDB data, this means auditing current relationships against these expected patterns. Many organizations find that discovery-generated relationships exist between infrastructure items but stop before reaching any service-level record. The CSDM alignment work extends those chains upward rather than rebuilding them from scratch.
Relationship types also matter. CSDM distinguishes between “Depends on” and “Hosted on” relationships, for example, because they carry different meanings for impact analysis. Assigning the correct relationship type to existing connections is part of the alignment process, not just ensuring that connections exist at all.
Getting relationship structure right is what enables ServiceNow’s service impact and root cause analysis features to produce accurate results. Without it, even a well-populated CMDB cannot tell you which business services are affected when a specific server goes down.
What does not need to change when adopting CSDM?
Not everything in an existing CMDB needs to change when adopting the CSDM data model. Records that are already in the correct class, carry accurate attributes, and participate in meaningful relationships can remain as-is. CSDM alignment is additive and structural, not a wholesale replacement of existing data.
Specifically, the following typically do not require significant rework:
- Discovery-populated infrastructure records that are in the correct hardware or network classes and reflect the actual environment accurately
- Existing dependency relationships between infrastructure CIs that reflect real technical dependencies, even if they need type corrections rather than removal
- Attribute data on CIs that is accurate and complete, regardless of whether the surrounding structure is aligned yet
- Custom tables and extensions that capture organization-specific data not covered by standard CSDM classes, provided they are linked correctly into the broader model
The most common misconception about CSDM adoption is that it requires starting over. In practice, the existing CMDB is the foundation. The alignment effort focuses on filling gaps, correcting class placements, and extending relationships upward into the service layers that are typically missing.
What does need attention is the data that sits in the wrong place, lacks relationships to service records, or uses inconsistent attribute values that prevent reliable querying and reporting. Identifying exactly which records fall into those categories, and which do not, is where a structured data quality assessment pays off. We use Data Content Manager to surface those gaps with precision, so teams can focus remediation effort on what actually needs to change rather than reviewing everything manually. If you want to see how that works in practice, book a demo and we can walk through it with your ServiceNow environment in mind.
