A Configuration Management Database (CMDB) implementation is the project of building a central record of the components that deliver your IT services and the relationships between them. IT teams look for a CMDB implementation plan when they need to move from a scattered inventory to a map they can use for changes, incidents, and audits.
In this guide, you'll find how to build a CMDB in six phases, the steps to do it in InvGate Asset Management, an example of one business service mapped end to end, and the practices that keep the data accurate once it's live. Answers to the most common questions close the article.
How to Build a CMDB And Map Your Entire IT Infrastructure
What is a CMDB and what is it used for?
A CMDB is a centralized repository that stores information about the Configuration Items (CIs) that make up an organization's IT environment, such as hardware, software, applications, services, and users, along with the relationships between them. Teams use it to understand how services are built and what a change or a failure will affect.
An asset inventory tracks what the organization owns and where it is, with data such as owner, location, status, and cost. A CMDB adds how those components connect and depend on each other, which is the key difference between a CMDB and asset management and the reason a CMDB can support impact analysis.
How to build a CMDB: Implementation project plan
Creating a CMDB implementation plan doesn't have to be complicated. The six phases below take you from a first scope decision to a CMDB that grows service by service, and the steps after them show how to run phases three to five in InvGate Asset Management:
- Define goals and scope. Decide which processes the CMDB must support first, such as Change Enablement or Incident Management, and pick one critical, well-known service to model. Everything outside that service waits for the next iteration.
- Assign owners. Every CI type needs a person responsible for its data, and every service needs an owner accountable for its map. Without named owners, records drift as soon as the project team moves on.
- Build the inventory. Populate the CIs from the sources you already have: discovery, agents, integrations, and existing spreadsheets. Track only the attributes the processes from phase one will actually use.
- Model the service. Group the CIs that deliver the service under one record, with its own name, owner, and location. This record is what teams will look for when something breaks.
- Map the relationships. Connect each CI to what it runs on, where it stores data, and who depends on it. This is the step that turns an inventory into a CMDB.
- Tie it to change and expand. Make CMDB updates part of how changes and incidents are closed, then repeat the process for the next service. Each new service reuses the CIs and relationships already mapped.
What are the steps to build a CMDB?
In InvGate Asset Management, building a CMDB comes down to three steps: creating the inventory, creating a Business Application, and organizing its diagram. The first one covers phase three of the plan, and the other two cover phases four and five.
#1. Create an inventory
Every CMDB is built with existing assets, so the first step is getting them into a unified inventory. That inventory is the base of any IT Asset Management (ITAM) program, so the effort pays off well beyond the CMDB.
InvGate Asset Management populates the inventory in four ways: by installing an Agent, through network discovery, through integrations with tools such as Intune, Jamf, and cloud providers, and with manual entry or CSV import. The method you choose depends on where the assets' data already lives and whether you want devices reporting on their own, and most teams combine several.
#2. Create a Business Application
A Business Application is the CI that groups the components behind one business service, such as a CRM, Active Directory, or an office network. You can create it from the CMDB by starting a new diagram and choosing the CI it starts from.
You can also create it directly from an asset, from the three-dot menu in the Asset Explorer or the gear icon on the asset profile. The Business Application is created with the asset's name, owner, and location already filled in, and all three stay editable.
#3. Organize the CMDB visualization
The diagram is where the service takes shape. Select a CI and turn on suggestions: InvGate Asset Management shows the CIs that could be related to it, based on what the Agent detected on the device, what network discovery found, cloud, virtualization, and database discovery, and properties such as owner or location. You can also add CIs manually and arrange them to reflect how the service works.
You accept or discard each suggestion individually, so nothing enters the diagram without your confirmation, and when you accept a CI that isn't directly connected to the one you started from, the CIs along the path are added too. Once the diagram is saved, you can export it as PNG or SVG for audits, documentation, and internal reporting.
Recommended reading
Read Article
The 10 Best CMDB Tools For 2025
CMDB implementation example: mapping one business service
Take a company CRM as the first service to map. On paper it's one application, but it depends on several CIs owned by different teams, and the diagram puts all of them in one view:
- Business Application: the CRM, with a business owner in Sales Operations and a technical owner in IT.
- Application services: the CRM web service and its API, hosted on two application servers.
- Servers: the two application servers, both virtual machines running on one ESXi host managed by vCenter.
- Database: the database instance that stores customer records, running on a dedicated server.
- Network: the load balancer in front of the application servers and the switch they connect to.
- People: the business owner, the technical owner, and the sales team that uses the CRM every day.
Read as a map, the diagram answers the questions a CMDB exists for. If the ESXi host needs a patch, you see that both application servers and the CRM go down with it, and if the database server fails, you know which service and which users are affected. In InvGate Asset Management, you can start this map from the database server itself: CMDB auto-mapping suggests the database instance, the application services, and the virtualization host, and you confirm each one.
How to keep a CMDB accurate over time
Building a CMDB is only the first step, and the real challenge is keeping it accurate as the IT environment evolves. A CMDB must be treated as a living system: every CI type has an owner responsible for its data, CMDB updates are part of everyday operational workflows, and manual maintenance is kept to a minimum. In InvGate Asset Management, owners are connected to CIs from the Related CIs tab, with types such as Commercial Owner or Security Auditor, or with custom types that match your own roles.
CMDB auto-mapping reduces the manual part of that upkeep. It suggests relationships between CIs from the data the inventory already has, and it's most useful during the initial setup, after infrastructure changes, and in environments that change often.
What are CMDB best practices for scope, CI lifecycle, and data quality?
The wider the possibilities of using a CMDB, the easier it is to get lost in the process. These CMDB implementation best practices, which build on expert advice on optimizing a CMDB, will keep you on track.
1. Set your scope
This is the first thing you need to do before creating the Business Application. Use the ITIL principle of keeping it simple, and remember that the more CI attributes you add now, the more details you'll have to maintain in the future. So pick a single business service and build it in your CMDB.
An achievable way of doing this is to start with your most well-known service and map it out from end to end. This gets you used to the process, CI mapping, and capturing all the attributes, and related information. By starting with an easy service, you'll build confidence and the next service won't seem so daunting.
2. Work smart
Another ITIL principle is to start where you are. Maybe you don't have a readymade, perfect CMDB already in place, but what you probably have is asset information or databases, spreadsheets with technical data, or support information in your IT Service Management (ITSM) tool. You can also try to design a CMDB implementation checklist so you don't miss any key step in the way. So, start with that, and build up over time or add things as you go along.
3. It's all about the data
Build checkpoints into your process to ensure your CMDB is up to date and accurately reflects your live environment. The quickest and easiest way to check if the data is correct is to have people use it. Here are some examples:
- Ask your service desk analysts to try and categorize incidents and service requests using the CMDB.
- Ask support teams to raise changes with impacted services flagged into the CMDB.
- Ask your Change Enablement teams to impact and assess change against the service information in the CMDB.
- Ask Problem Management to use the CMDB to support problem and known error analysis.
Once colleagues start using the CMDB, build in some process steps to protect data integrity, for example:
- Have the service desk update incorrect CI data at the moment, when logging incidents or requests.
- Work with your Change Enablement practice and agree to some success criteria that supports Configuration Management. An example could be a change that can only be closed off as successful when the CI or service information is updated.
- Work with your security teams so that any security incidents are automatically linked to a service so they can be managed more effectively.
4. Track CIs over their lifecycle
Every CI has a lifespan so when maintaining your CMDB, you'll need a process for recording and reporting the lifecycle of each CI. By building status accounting into your CMDB working practices, you're ensuring that all CIs that make up the service baseline have been captured and that all changes have been captured by and reflected in the CMDB.
5. Keep moving forward
Build up your CMDB over time. Use that first service as a prototype. Once you have that service, you've got an approach that works, so repeat the process again for the next service and the next, and so on. Keep going until you've captured all your most critical systems, and before you know it, you'll have an effective CMDB.
Key CMDB use cases in ITIL practices
The CMDB concept is closely tied to ITIL, where it was formalized as part of Service Configuration Management, which is why the term ITIL CMDB describes a CMDB that supports IT Service Management processes. Several ITIL practices depend on accurate CI and relationship data, and three of them show its value most clearly:
- Change Enablement: the CMDB shows which CIs and services a change touches before it's implemented. Changes are assessed against real dependencies, which makes them more controlled and predictable.
- Incident Management: agents see the affected CIs and their dependencies. That context helps them find root causes faster and restore services sooner.
- Problem Management: recurring incidents, underlying causes, and past changes are linked to the same CIs. Patterns become easier to identify.
In InvGate Asset Management, this data also reaches the service desk. InvGate Service Management shows the service requests linked to each asset and the connections between CIs, so agents work incidents and changes with the same context IT uses to maintain the CMDB.
Final thoughts: turn your CMDB into a practical asset
A CMDB implementation works when it starts with one service, gives every CI type an owner, and stays tied to how teams handle changes and incidents. To build yours in InvGate Asset Management, start a free trial or talk to Sales to review your environment.
Frequently Asked Questions
These are the questions that come up most often when IT teams plan a CMDB implementation. Each answer sums up what the sections above cover in more detail.
What should be included in a CMDB?
The CIs that deliver the services in scope (hardware, software, applications, cloud resources, databases, and the people who own them) plus the relationships between them. Start with the attributes your Change Enablement and Incident Management processes actually use.
How long does a CMDB implementation take?
It depends on the scope and on how much inventory data you already have. Starting with one critical service and expanding service by service keeps each iteration short and shows value early.
Who owns the CMDB?
The Configuration Management or IT Asset Management team usually owns the CMDB as a whole, while each CI type and each service has its own data owner. Without named owners, CMDB data goes stale quickly.
What is a CI in a CMDB?
A Configuration Item (CI) is any component that needs to be managed to deliver an IT service, such as a server, an application, a database, or a license. Each CI has its own record and relationships in the CMDB.