Change Management handles individual modifications. Release Management groups them into a coordinated deployment. The distinction matters when you ship 12 changes together for a quarterly platform update and need one rollback decision instead of 12.
When releases fit
Use a release when:
- Multiple changes ship together with shared dependencies.
- A coordinated test, deploy, and rollback plan applies.
- The customer (internal or external) sees one event, not 12.
Use individual changes when:
- Each change is independent and can be rolled back without affecting others.
- Different teams own different changes with different timing.
Release types
Set up three release types:
- Major: quarterly platform updates, multi-team coordination, executive visibility.
- Minor: monthly bundled changes, single-team coordination.
- Emergency: hotfix bundles for incidents, fast-track approval.
Each type gets its own approval workflow, change-window default, and notification template. Stop trying to use one workflow for all three; the approval needs differ.
Building a release
Create the release first, then attach changes. The release has its own start date, end date, owner, and rollback plan. Attached changes inherit the release window but keep their own technical detail.
A release without attached changes is meaningless paperwork. Conversely, every customer-impacting change should belong to a release for traceability.
Approval flow
Major releases need CAB approval, not just CR-by-CR approval. The release-level CAB reviews the bundle for risk, conflicts, and rollback feasibility. Individual changes were already technically approved.
Configure the release approval workflow: on submission, route to release manager, then to change advisory board, then to release authority for go/no-go. Each step is logged.
Rollback plan
Every release has a rollback plan field. Make it required. The rollback plan describes how to revert each change, in what order, and the estimated time. Without this, a failed deployment turns into a panic-driven recovery.
For multi-change releases, rollback order is reverse-deploy order. Document this in the plan; the on-call engineer at 3am will not figure it out from the change tickets alone.
Communications
Release notifications go out at three points: pre-release (customer awareness), at-release (start of window), post-release (success or rollback). Build templates for each. Pre-release is sent 7 days out for major releases, 24 hours for minor.
Use the broadcast feature to target affected user groups, not all users. Spam fatigue degrades all future release awareness.
Post-implementation review
Every release closes with a PIR. Capture what went well, what went wrong, action items for next time. Build a custom report: count of releases per quarter with PIR completed. Should be 100 percent.
Without PIR discipline, you repeat mistakes. Failed releases without PIR are how organizations learn nothing.
Linking to incidents
If a release causes incidents, link them to the release. The release record shows blast-radius. After the quarter, run a report of releases with linked incidents to find the riskiest changes and improve testing.
What to do this week
Pick your next bundled deployment and build it as a release, not as a parallel set of changes. Attach the changes, fill in the rollback plan, schedule the PIR. See how it changes the conversation in change advisory.
