Release Management vs Change Management: What's the Difference

These two get treated as the same activity with different names, or as a hierarchy where one contains the other. They're neither. They manage different objects, and conflating them removes your ability to ship one thing.

Aldermoor Health had a one-line fix for a scheduling bug that was affecting one site. Ready on Tuesday morning, tested, reversible.

It shipped eleven days later, with the fortnightly release.

Nothing had blocked it. There was no rule saying single fixes couldn't ship. But the approval, the testing sign-off, the notification and the schedule were all attached to the release, and there was no path for a change that wasn't part of one. To ship the fix alone, someone would have had to invent a process on the spot, on a Tuesday, for a bug affecting one site. So it waited.

That is what conflating the two costs: not delay in general, but the loss of the ability to move a single thing.

Different objects, different questions

	Change management	Release management
The object	One alteration to one thing	A bundle of alterations
The question	Is this safe, and who's affected?	What ships together, when, and to whom?
The decision	Proceed or don't	Go or hold — for the whole bundle
Fails by	Something breaks that nobody predicted	Half the bundle ships, or the wrong version does
Cadence	Per change, continuous	Per release, scheduled
Owner	Whoever holds change authority	Whoever coordinates the bundle

Read the failure row, because it's the clearest separator. A change-management failure is an unpredicted break — the auth config that took down the mobile app. A release-management failure is a coordination failure: the API shipped and the client didn't, the migration ran against the old schema, one region got a version another didn't.

Neither process catches the other's failure. A flawless release process would not have caught Aldermoor's auth outage, because every individual change was approved and the bundle assembled correctly. And a flawless change process wouldn't catch shipping a client without its API.

The test you can run: take your last two incidents and classify each as unpredicted-break or coordination. If they're both the second kind and you've been strengthening change approval, you've been reinforcing the wrong process.

The symptom that tells you they've merged

One question separates a healthy setup from a merged one:

Can you ship a single change without a release?

If the answer needs qualification — "well, there's the hotfix path, but you need a director" — the release has become the unit of approval, and every change now inherits the release's cadence whether it needs it or not.

Three other symptoms of the same merge:

• Change records are created per release rather than per change. The record then describes a bundle, so it can't answer "what altered, and what depends on it" for any individual item.

• The change board's agenda is releases. The board is now approving schedules rather than assessing alterations, and the questions it asks stop matching the object in front of it.

• Rollback means rolling back the release. So an unrelated feature disappears when one thing breaks — which makes people reluctant to roll back at all, and that reluctance is the expensive part.

The test: ask your team what would happen if a one-line fix needed to ship this afternoon. The length of the answer is the measure of how merged the two have become.

Continuous delivery doesn't remove one — it collapses the bundle

The common reading is that continuous delivery makes release management obsolete. It doesn't. It shrinks the release to one change, so the two processes coincide.

That coincidence is what makes CD feel simple: the bundle is the change, so there's nothing to coordinate. And it's why the classification question gets easier — a pipeline with tests, a canary and automatic rollback is the pre-approval, applied per change.

But release management reappears the moment a bundle does, and bundles reappear constantly:

• A schema migration that must land before the code that uses it.

• A mobile app release, gated by an app store, with a server change it depends on.

• A vendor's API cutover with a fixed date.

• A change requiring customer notice.

In each case there's a bundle with an order and a date, and that's release management whether or not anyone uses the phrase. The teams that suffer here are the ones who declared release management obsolete and then meet a mobile release — with no coordination artifact, because the process was retired rather than scoped.

The test: name the last time you had two changes that had to ship in a specific order. Who tracked the order, and where was it written down? If the answer is a Slack thread, you have release management without an owner.

When they genuinely should combine

There are cases where keeping them separate is the overhead, not the safeguard:

• The bundle is always one change — high-frequency CD with independent deploys. Separate processes for a bundle of one is ceremony.

• One team owns the whole path, with nothing downstream depending on the ordering. Coordination that involves nobody else can be a conversation.

• The release has no external constraint — no date, no announcement, no partner. Then the release is a container of convenience, and the change is the real unit.

What should never combine is the record. Even when the processes merge, keep the change record per alteration, because that's what the dependency question and the post-implementation review both need. A record describing a bundle can't tell you what altered.

The test: if the two processes are merged in your team, check whether you can still answer "what changed about this service in March?" without reading release notes for a bundle.

What to change this week

Answer the shipping question honestly: can a single change go out today, without a release, with an approval path that already exists?

If not, build that path before you need it — because you will need it during an incident, and inventing a process under pressure is how the wrong thing gets shipped. It doesn't need to be elaborate: a change class that permits single-change deploys, a named authority, and the same record you'd write anyway.

Aldermoor now has one. The scheduling fix that took eleven days would take about forty minutes. Nothing about their release process changed — they still ship fortnightly bundles, still coordinate them, still hold a go/no-go. What changed is that the release stopped being the only way out.