Change Management
Ship changes safely with minimal approvals, clear ownership, and fast rollback.
Change Management
Change Management in ITSMote exists to reduce the risk of breaking production, not to slow delivery.
If your change process adds meetings, paperwork, or waiting time without reducing incidents, it is broken.
ITSMote Change Management is lightweight by design: plan just enough, approve only when needed, and always be ready to roll back.
Definition
A change is any planned modification to a live or production-adjacent system that can impact availability, performance, data integrity, security, or user experience.
This includes:
- releases and deployments
- configuration changes
- infrastructure changes
- feature flags and experiments
- data migrations
- dependency upgrades
If it can break prod, it is a change.
Goal
- Reduce change-related incidents
- Make changes predictable and reversible
- Keep delivery fast without gambling reliability
Change types
Standard Change
Low-risk, repeatable, well-understood change.
Criteria:
- proven pattern
- documented rollback
- minimal blast radius
- historically low failure rate
Examples:
- routine releases
- config tweaks behind flags
- scaling operations
- dependency patch updates
Approval:
- pre-approved (no per-change approval)
Normal Change
Change with non-trivial risk, unclear impact, or limited history.
Examples:
- new feature release
- infrastructure reconfiguration
- schema change
- architectural refactor
Approval:
- single approver (tech lead / service owner)
Emergency Change
Change required to mitigate or resolve an active incident.
Rules:
- speed over formality
- document after, not before
- must be linked to an incident
Approval:
- verbal or implicit (Incident Lead)
Non-goals
Change Management is not:
- a release calendar for everything
- a CAB theater
- a compliance exercise
Roles
Change Owner (mandatory, single person)
Accountable for the change end-to-end:
- plans the change
- assesses risk
- coordinates execution
- ensures testing and rollback readiness
- validates outcome
- closes the change
Never assign “the team”.
Approver (only when required)
- reviews risk and readiness
- blocks unsafe changes
- does not micro-manage implementation
One approver is enough.
Change lifecycle (ITSMote)
1) Plan
Goal: think before touching production.
Minimum required:
- what will change
- which services are affected
- expected user impact
- risk level
- rollback plan
- verification method
Rules:
- If rollback is unclear, the plan is incomplete.
- If you cannot explain impact, assume higher risk.
Status:
- Planned
2) Approve (if needed)
Required only for:
- Normal changes
- Any change touching data integrity or security
Rules:
- one approver
- async by default
- approval checks readiness, not code style
Approval criteria:
- plan is clear
- rollback exists and is realistic
- blast radius understood
Status:
- Approved / Rejected
3) Execute (deploy the change)
Goal: ship the change safely.
Rules:
- follow the plan
- avoid untracked last-minute scope changes
- keep execution window clear
Do:
- deploy / apply change
- record start time
- monitor primary signals immediately
Status:
- In Progress
4) Verify (test in production)
Goal: confirm the change did not break anything.
Verify using:
- SLO signals (errors, latency, availability)
- synthetic checks
- functional validation
- user confirmation if applicable
Rules:
- no verification, no success
- optimism is not a signal
Status:
- Verifying
5) Rollback (if needed)
Rollback if:
- verification fails
- impact exceeds expectations
- signals degrade
Rules:
- rollback is a success, not a failure
- document why it was needed
Status:
- Rolled Back
6) Close
Close only when:
- change is verified as successful
- or rollback is completed and stability confirmed
Do:
- record outcome
- link incidents (if any)
- create follow-ups if the change revealed risks
Final status:
- Closed
Metrics (minimum viable)
If changes keep breaking prod, the process is not working.
Track monthly:
- Change failure rate
- % changes with rollback
- Incidents caused by changes
- Mean time to rollback
Documentation standard
Write for execution, not compliance.
Minimum change record fields:
- Change summary
- Change type
- Affected services
- Risk level
- Rollback plan
- Verification steps
- Execution window
- Outcome
Rule:
If rollback and verification are not documented, the change is unsafe.
Minimal template
Change header (copy/paste)
- Title:
- Change type:
- Change Owner:
- Affected services:
- Risk level:
- Planned execution time:
- Rollback plan:
- Verification plan:
- Approval (if required):
- Outcome: