IT Change Management
IT change management (called change enablement in ITIL 4) controls modifications that could affect a service: software deployments, infrastructure and network changes, identity policy updates, firmware upgrades, and vendor configuration. It makes the purpose, scope, risk, authority, implementation plan, and recovery decision visible so teams can change systems quickly and reliably.
It's distinct from organizational change management, which focuses on people adopting new ways of working. And it's not the same as bureaucracy: the research behind DORA metrics found that heavyweight external approval boards correlate with worse stability, while lightweight peer review plus automated testing correlates with better outcomes. Good change management matches scrutiny to risk.
TL;DR
- Classify changes as standard (preapproved), normal (assessed), or emergency (expedited).
- Assess risk from impact, uncertainty, and recoverability — not from size alone.
- Prefer peer review and automated evidence over blanket committee approval for routine changes.
- Define validation gates, stop conditions, and rollback or forward-recovery before you start.
- Close the loop: validate the user-visible service and update baselines and runbooks.
- Measure change failure rate and lead time to know whether the process is helping.
Quick Example
A normal-change record for a planned infrastructure change:
Core Concepts
Change Types
Risk Assessment
Useful risk questions:
- Impact — which services and users are affected if it goes wrong?
- Uncertainty — has this exact change been done before? Is it tested in a production-like environment?
- Recoverability — how quickly and cleanly can it be undone? Is there a point of no return?
- Timing and concurrency — what else is changing, and is it a busy business period?
Release, Deployment, and Change
A deployment installs something; a release makes functionality available to users; a change is any modification that could affect a service. Feature flags let teams deploy without releasing, which reduces change risk. Operational changes — firewall rules, IAM policies, DNS records — often don't pass through a software pipeline and still need control.
Reversal Has Limits
Some changes can't be undone after new data is written: schema migrations, data transformations, encryption key rotations, or third-party contract changes. Define the point beyond which forward recovery, migration, or restore is required rather than promising a universal rollback. Expand-and-contract migrations keep more changes reversible.
Change Advisory Boards and Peer Review
A change advisory board (CAB) is a forum that reviews changes. Used for everything, it becomes a bottleneck that adds days of delay without adding much safety — reviewers rarely have enough context. Modern practice keeps CABs for genuinely high-risk, cross-team changes and uses peer review, automated testing, and progressive delivery for everything else.
Automated Change Evidence
When changes flow through CI/CD, the pipeline can generate the change record automatically: linked ticket, reviewed pull request, passing tests, approver, deployment time, and rollback artifact. Tools like ServiceNow DevOps or Jira Service Management integrations do this, turning compliance into a by-product of delivery.
Best Practices
Match Review Depth to Risk
A routine scoped patch shouldn't require the same forum as a one-way data migration. Publish clear criteria for each risk level.
Grow the Standard Change Catalog
Convert frequent, successful normal changes into standard changes with documented procedures. This shifts effort from approval to improvement.
Make Gates Observable
Replace "check that it works" with a specific transaction, signal, and acceptable result, and name who can stop or authorize continuation.
Use Progressive Delivery
Canary releases, blue-green deployments, and feature flags limit blast radius and make rollback fast. See Deployment Strategies.
Keep a Change Calendar
A shared view of planned changes prevents conflicting work in the same failure domain and helps incident responders ask "what changed?"
Review Failed Changes Blamelessly
Treat failures as information about the process and system. Update procedures, tests, and standard-change status accordingly.
Common Mistakes
Calling Novel Work "Standard"
An untested first-time migration isn't a standard change just because it's small. Assess novelty, data impact, dependencies, and reversibility.
Closing on Command Success
A command returning success doesn't mean the service works. Validate the user-facing outcome and record the resulting state.
Blanket CAB Approval
Requiring committee approval for every change slows delivery, encourages batching (which increases risk), and pushes teams to route around the process.
Emergency Changes as a Loophole
If a large share of changes are "emergencies," the process is too slow or being bypassed. Track the ratio.
Unrecorded Console Changes
Manual changes that bypass the process create drift that surprises the next person. Reconcile them into code and records immediately.
Comparison
FAQ
What is IT change management?
It's the process of planning, assessing, authorizing, implementing, and reviewing changes to IT services so they're made quickly while controlling risk to availability, security, and data.
What's the difference between standard, normal, and emergency changes?
Standard changes are low-risk and preapproved procedures. Normal changes need assessment and authorization proportional to risk. Emergency changes are expedited to restore service or address urgent risk, with review afterward.
Does every change need a change advisory board?
No. Reserve CAB review for high-risk or cross-team changes. Most changes are better served by peer review, automated testing, and preapproved standard procedures.
Is an emergency change exempt from review?
No. It uses a faster decision path, but the decision owner, actions, and outcomes are recorded, and a follow-up review happens while the evidence is fresh.
What if rollback is impossible?
Document that constraint and agree before execution on a forward-recovery, restore, or controlled migration plan, with a clear point of no return.
Related Topics
- Incident Management — Where failed changes often end up
- Deployment Strategies — Canary, blue-green, and rollback
- CI/CD — Automating change evidence
- DORA & Delivery Metrics — Change failure rate and lead time
- IT Asset Management — Keeping configuration records current