A Rollback Plan Must Account for the Data Already Changed

Reversing a release is a proposed recovery action, not proof of recovery. The plan must explain what happens to records the newer version has already written.

The comforting button needs a defined destination

A team planning a software release may say that it can roll back if anything goes wrong. That statement should invite a concrete question: roll back which parts of the system, to which state, and with what treatment of work completed after the release? A previous application version is not necessarily a previous business state.

This is an architectural opinion, not an incident report or a claim about a particular software platform. The argument is that a rollback plan should describe the relationship between application behaviour and persistent records. Calling the recovery action simple does not make the consequences simple. The plan becomes credible when it explains what the older version will encounter after it returns.

Define the work that must survive

Consider a hypothetical appointment service. A release adds a new booking status and begins recording it for customers. The team then notices an unrelated display problem and restores the older application. If that application has no defined treatment for the new status, the service needs a decision about those bookings, not merely a successful restart.

Before release, the team should identify which business work must remain understandable across the transition. A customer’s confirmed appointment should not become an unexplained record because a deployment was reversed. This requirement does not dictate one technical architecture. It sets a standard for the recovery argument: explain how the system will preserve the meaning of legitimate work.

Separate code restoration from record repair

A sound plan should distinguish restoring an executable version from repairing or translating data. These actions may have different owners, prerequisites and consequences. They should not be collapsed into a single word that prevents anyone from seeing where judgment is required.

For the hypothetical booking service, restoring code could be one step. Deciding whether to translate a status, temporarily support both representations or pause affected operations could be another. Those options need evaluation in the actual system. The important principle is to avoid pretending that returning code automatically resolves every state that code might read. A recovery procedure should make its assumptions available for challenge before an incident supplies the challenge unexpectedly.

Choose a reversible path deliberately

A release can be designed around a transition period rather than an abrupt replacement. The team might propose retaining an older interpretation while introducing a new one, provided that this arrangement is appropriate for its real constraints. It should specify when the temporary compatibility ends and what evidence permits that decision.

Otherwise, a transitional arrangement risks becoming an indefinite ambiguity. Two representations of the same business fact need a clear relationship. If they disagree, which one governs the customer’s next action? Reversibility should be treated as a design property with a duration and an owner. It should not become a vague promise that every past version will remain usable forever.

Rehearse the state after real work

A recovery exercise should include work performed under the new version. An empty test environment can answer whether old code starts. It cannot answer the more important hypothetical question of whether old code can safely continue a service after new code has changed its records.

The exercise should therefore identify representative transitions: an item created, edited, cancelled or completed after release. The exact set depends on the product. Reviewers should state what they have not covered. A successful rehearsal is evidence about the conditions exercised, not permission to assume that every possible record has been handled. This keeps recovery confidence connected to an observable result rather than a general feeling of preparedness.

Make the decision to pause respectable

A rollback plan can become dangerous as an organisational promise if everyone assumes that choosing it will immediately restore normal service. A responsible operator may need to pause a specific function while preserving records and examining a discrepancy. That decision should have an authorised route.

Suppose the booking service can still show existing appointments but cannot yet interpret one newly introduced cancellation state. Temporarily limiting that action could be more intelligible than silently guessing. This example does not establish a universal operational rule. It shows why the plan should define who can choose a restricted mode, what customers will be told and which evidence is needed before normal operation resumes.

Count the reconciliation work

Recovery may leave questions that require reconciliation: which actions completed, which responses reached users and which retries remain safe? The plan should explain how these questions will be investigated. A restarted service should not automatically close the incident record while unresolved customer consequences remain.

Ownership matters here. If engineering restores the application and support receives the resulting confusion, the organisation still has one recovery problem. A named owner should connect the technical outcome to the business records affected. The objective is not administrative ceremony. It is a traceable answer to each consequential action that occurred during the transition and might otherwise fall between teams.

Judge recovery by restored meaning

The useful test of a rollback is whether the service can again make reliable decisions from the state it actually has. That includes the ability to explain unresolved exceptions honestly. A recovery plan should be reviewed against that outcome, rather than against the mere existence of an earlier software package.

Reversing a deployment can be a valuable option. Its value depends on the surrounding design and the evidence that the transition is understood. The standard proposed here is straightforward: show what happens to the data already changed, preserve legitimate work and identify the decisions that still need a human owner. That is a stronger promise than saying the old version is available.

Gabriel Nicolaev — CyGuru

Editorial photograph for illustration.

FOLLOW THE CONNECTION

Another angle on this subject

Continue through related ideas, decisions and consequences.

Technology & AI

Passkeys Need an Exit Plan as Well as an Enrolment Screen

A passkey rollout should explain device loss, provider changes and account recovery with the same clarity as its first successful sign-in.

Technology & AI

An AI Supplier Update Is an Operating Change, Not Just a New Feature

Procurement needs a plan for changed model behaviour, revised integrations and rollback before an AI service becomes embedded in essential work.

Money & Business

A Business Succession Plan Must Transfer Judgment, Not Just a Title

An operating essay on succession, concentrated knowledge and the decisions a business needs to make when its most experienced person steps away.