What is the difference between rolling back and rolling forward?

Reverting to the previous version versus fixing forward with a new release — and which is appropriate depends on factors that are worth deciding before an incident rather than during one.

Rollback. Return to the last known good version.

Its advantages: the previous version is known to work, so the outcome is predictable; it is usually fast; and it does not require understanding the problem, which matters when you are under pressure and do not yet know what went wrong. This is the decisive advantage — you can restore service and investigate afterwards.

When it is not possible, which is the part that catches teams out:

Database migrations. If the deployment changed the schema, the previous version may not work against it. This is the most common reason rollback is unavailable, and it is why migrations should be designed to be backward compatible — applying schema changes separately and ahead of the code that requires them, so that both versions can run against the same database.

Data written in a new format that the old version cannot read.

External state changed — messages published, third-party systems notified, payments taken.

Clients already updated, particularly mobile applications that cannot be recalled.

Roll forward. Deploy a new version containing a fix.

Its advantages: it is sometimes the only option; it avoids reverting other changes bundled in the same deployment; and with a fast, reliable pipeline it can be quicker than it sounds.

Its risk: you are deploying untested code, under pressure, while the system is broken — which is precisely the situation in which mistakes are made. A rushed fix that makes things worse is a familiar outcome.

What makes either work:

Small, frequent deployments. A deployment containing one change is easy to reverse and easy to reason about. A release containing three weeks of work is neither.

Backward-compatible migrations, applied separately from code.

Feature flags, which allow disabling a specific change without deploying anything — frequently the fastest and safest option, and the reason they are so widely used.

A tested rollback procedure. A rollback mechanism that has never been exercised is unlikely to work when first attempted.

Deciding in advance which is the default, so the decision is not made during an outage.