Software changes are unavoidable.
The goal of change risk management is not to stop changes.
It is to understand the potential impact of a change and apply the right controls before and during deployment.
What is change risk management?
Change risk management is the process of identifying, evaluating, and managing the potential consequences of a software change.
That can include:
- Code changes
- Configuration changes
- Database changes
- Infrastructure changes
- Dependency upgrades
- API changes
- Deployment changes
Start before deployment
The earlier you identify uncertainty, the more options you have.
Before merge or deployment, look at:
- Change scope
- Dependencies
- Testing
- Production usage
- Incident history
- Runtime signals
- Blast radius
- Rollback conditions
Use evidence rather than intuition
A useful assessment should answer:
What do we know?
What don't we know?
What could this change affect?
What controls are available?
This creates a more explicit basis for the deployment decision.
Match controls to the change
Not every change needs the same process.
Possible controls include:
- Additional code review
- More integration testing
- Staged deployment
- Feature flags
- Increased monitoring
- Rollback preparation
- Additional approval
The appropriate control depends on the change and its context.
Production reliability and change management
Traditional change management often focuses on approvals and process.
Production reliability adds technical evidence around the change itself.
That includes how the code relates to dependencies, production behavior, historical incidents, and potential blast radius.
AI assisted development changes the volume
AI coding tools can increase the number of changes engineers can produce.
That can make change risk management more dependent on automated signals and prioritization.
The goal is not to slow development down.
It is to make it easier to identify which changes need more attention.
A practical framework
Change
↓
Production context
↓
Evidence
↓
Potential impact
↓
Controls
↓
Deployment
↓
Production feedback
The last step matters because deployment creates new evidence that can inform future changes.
Where PRI fits
Tomosu's Production Reliability Index (PRI) provides a summary signal around software changes using multiple reliability indicators.
It can be used as one input into a broader change management process.
Run a PRI assessment:
The main idea
Good change risk management is not about making every change look risky.
It is about distinguishing changes that can move through the normal workflow from changes where additional evidence or controls are useful.
The better the context, the better the decision.
Top comments (0)