Configuration Management vs Change Management
Configuration management maintains accurate records of the components that make up services, their settings, and their relationships. Change management controls modifications to those components, assessing risk, approving, scheduling, and reviewing changes. Change management depends on configuration data to judge impact, and configuration records depend on change management to stay current.
What each discipline does
Configuration management identifies configuration items, such as servers, applications, network devices, and services, records their attributes and relationships, and keeps those records accurate. In ITSM this lives in a configuration management database. In engineering practice the term also covers tools that enforce desired configuration on systems.
Change management ensures changes are assessed, authorised, and implemented in a controlled way to reduce the risk of disruption. It covers standard pre-approved changes, normal changes that need review, and emergency changes.
Why they depend on each other
To assess a change, you need to know what it affects: which services depend on the component, who owns them, and what else changed recently. That is configuration data. Without it, risk assessment becomes guesswork based on the change description.
In the other direction, configuration records only stay accurate if changes update them. Every change made outside the process, a manual fix during an incident or a console tweak, creates drift between the records and reality. Over time, a configuration database fed by poor change discipline becomes untrustworthy, and people stop using it.
How modern teams combine them
Infrastructure as code merges the two. The repository holds the desired configuration, the pull request is the change record, review is the approval, and the deployment pipeline both applies and records the change. Drift detection compares reality with code and flags manual changes. Automated discovery fills in what code does not describe, and deliberate modelling captures relationships to business services that neither tool can infer.
Practical steps to connect them
- Require every change record to reference the configuration items it affects, selected from the CMDB rather than typed as text.
- Update configuration records as part of completing a change, not as a separate task.
- Run drift detection and treat unexplained differences as unrecorded changes to investigate.
- Review configuration accuracy for critical services periodically, with named owners signing off.
- Use relationship data in change risk assessment automatically, so reviewers see dependent services without searching.
| Aspect | Configuration management | Change management |
|---|---|---|
| Question answered | What exists, how is it set up and connected? | Should this change happen, and how? |
| Main artefact | Configuration records, CMDB, desired state | Change records, approvals, schedules |
| Main risk if weak | Stale data, unknown dependencies | Uncontrolled changes, outages |
| Depends on the other for | Updates that keep records current | Impact assessment |
| Code-based equivalent | Infrastructure as code, drift detection | Pull requests, review, pipelines |
Frequently asked questions
- What is the difference between configuration management and change management?
- Configuration management records and maintains the components of your services, their settings, and relationships. Change management controls how those components are modified, through risk assessment, approval, scheduling, and review. One describes the current state; the other governs transitions between states.
- Why do CMDBs become inaccurate?
- Mainly because changes happen without updating records: manual fixes during incidents, console changes, and systems added outside normal processes. Automated discovery reduces the gap but misses intent and business relationships. Accurate configuration data depends on disciplined change management and clear ownership of records.
- Does infrastructure as code replace change management?
- It changes how change management is done rather than removing it. Pull requests, reviews, automated tests, and pipelines provide assessment, approval, and records. Many organisations treat well-tested pipeline changes as standard pre-approved changes and reserve manual review for higher-risk changes.
- What is configuration drift?
- Configuration drift is the gap that develops between a system's recorded or intended configuration and its actual state, usually through manual changes, emergency fixes, or processes that bypass change control. Drift makes behaviour unpredictable, undermines impact assessment, and often surfaces during incidents or when rebuilding systems from records.
- Who owns the CMDB?
- Ownership works best when it is distributed: each team owns the configuration records for the services and components it runs, and a platform or ITSM team owns the database, data model, and quality processes. A CMDB owned only by a central team tends to go stale, because that team cannot know about every change.