Why decide before, not during
Cutover is a stressful time. People are tired, the clock is running and nobody wants to be the one who calls the project a failure. These are poor conditions for deciding whether to continue or go back. A rollback plan moves that decision to a calmer time, by agreeing in advance what counts as a failure, who decides and what happens next.
Having a rollback plan does not mean expecting failure. It means accepting that the outcome of a complex change is uncertain, and that the cost of being unprepared can be much higher than the cost of the plan.
What “rollback” means
Rolling back means returning to the previous working state, usually by continuing to use the old system and discarding or setting aside the work done in the new one. There are related ideas worth separating:
- Rollback: go back to the old system and try again later.
- Roll forward: keep going and fix problems in the new system, often with extra support, because going back is no longer realistic or is worse.
- Workaround: keep the new system live but use manual or temporary processes for a failing area.
A good plan names these options, because in practice the choice is not always a simple yes or no. Business continuity planning is a close neighbour: it covers how the organization keeps operating during disruption, and the rollback plan should be consistent with it.
Elements of a rollback plan
Triggers
Write down, in measurable terms, the conditions that would lead to a rollback. Examples:
- A critical process cannot be performed, such as taking orders or paying staff.
- Data reconciliation checks fail beyond an agreed tolerance.
- A security issue is found that cannot be fixed within a set time.
- A key integration fails and no workaround is available.
- Performance is so poor that normal work is not possible.
Distinguish between issues that are serious but can be fixed quickly, and issues that need a decision. Thresholds and time limits help, for example “if this cannot be resolved by a stated time, we revert.”
Decision rights
Name who can call a rollback and who must be consulted. A clear single decision maker with a deputy avoids delay. Decision rights in the plan should match the project’s wider governance, so a steering committee is not asked to meet at three in the morning unless that is truly intended.
The point of no return
Some steps cannot be undone, or can only be undone at high cost. Examples include deleting old data, sending notices to customers, or letting a supplier contract lapse. Identify these steps, place them as late as possible and require a deliberate go/no-go before each. After the point of no return, the plan switches from rollback to roll forward.
Data
Data is usually the hardest part. If users create new records in the new system after go-live, reverting to the old one means those records must be carried back, re-entered or consciously discarded. Questions to answer in advance:
- Will the old system be kept intact and unchanged until the plan expires?
- If transactions occur in the new system, how will they be transferred back?
- How long a window is there before going back becomes impractical?
- What backups exist, and have restore procedures been tested?
For short windows, it may be acceptable to reconstruct a few hours of activity manually. For longer ones, the effort can be considerable, which is one reason the shape of the cutover strategy matters. A phased approach limits how much data is at stake at any time.
Technical steps
Document the actual sequence to revert: redirecting users and interfaces, re-enabling the old system, restoring configuration, switching integrations back. Include who performs each step, how long it takes and how to confirm it worked. Check that the old system’s access, licences and support will still be available at that point, since decommissioning too soon removes the option.
Communication
Prepare messages in advance: who needs to be told, by what channel and with what wording. This includes staff, customers, suppliers and senior management. A change communication plan can include rollback messages so that they are not drafted in a hurry.
Test the rollback
A rollback procedure that has never been tried is a hope rather than a plan. Rehearse it during the dress rehearsal for cutover, timing each step and noting what was missing. Testing also reveals questions such as whether the old system still accepts connections after data has been loaded to the new one.
Balancing caution with commitment
There is a trade-off. A very elaborate fallback can consume effort that might be better spent making the primary route succeed, and a project team that believes it can easily revert may take less care. Conversely, no fallback leaves the organization exposed. A proportionate plan matches the effort to the impact of failure: a minor internal tool needs a short note, while a core platform needs a detailed, rehearsed procedure.
After a rollback
If a rollback happens, it is not necessarily a failure of the project. Handled calmly, it protects the business. Afterwards:
- Stabilize the old system and confirm that operations are normal.
- Review what went wrong, without assigning blame.
- Decide what must change before another attempt.
- Communicate honestly to stakeholders.
- Reset the schedule on the basis of evidence rather than the original date.
Checklist summary
- Triggers written in measurable terms.
- Named decision makers and deputies.
- The point of no return identified.
- A data approach for transactions created after go-live.
- Technical revert steps documented and timed.
- Communication drafted.
- The rollback rehearsed.
- Old system preserved until the agreed expiry.