What should the plan actually contain?

The trigger that would start it, the process people would return to and who still knows it, who is authorised to make the call, and an honest list of what cannot be reversed at all. Four short sections, written before anything is signed.

Why does the old process stop working?

Because it stops being practised. Documentation ages, the steps are no longer in anybody's hands, and people who did it from memory leave. A fallback assumed to be sitting there is usually a fallback nobody has attempted in a year.

Glossary

Rollback plan

What you will do if a change has to be undone, written while everyone is calm rather than worked out while something is going wrong.

In plain terms

How you get back to how things were. The uncomfortable discovery is that switching the tool off does not do it, because by then the old way of working has faded, information has gone places you cannot recall it from, and the people who remembered the manual process have moved on.

Why it matters

Because the assumption that you can simply stop is what makes an adoption feel low risk, and it is usually wrong. Recognising that early changes what you agree to at the start, which is the only point at which the terms are still negotiable.

How it works

Turning it off is a step, not a plan. The system stopping is straightforward and the state it leaves behind is the difficult part, so a plan consisting of the switch has addressed the easiest element and none of the others.

The old process decays while nobody is watching. Documentation goes stale, the sequence of steps stops being practised, and the people who could do it from memory move on, so a manual fallback assumed to be waiting has quietly stopped existing.

Data that has gone outward does not come back. Material sent to a service can be deleted on request and cannot be un-received, so the exposure created by an adoption survives the decision to reverse it and belongs in the assessment made beforehand.

Contractual reversal is a separate question from technical reversal. Notice periods, minimum terms and what happens to your material on termination all decide how quickly you can actually stop, and they are settled at signature rather than at the moment you want out.

Habits are the slowest thing to reverse. People adapt their working day around a tool within weeks, and removing it returns them to a process they now find slower than the one they had learned, which is a change-management problem rather than a technical one.

The plan is worth most where it is cheapest to write, which is before anything is signed. Naming the trigger, the fallback, who decides and what cannot be undone takes an hour at the start and is unwritable at the moment it is needed.

What reverses, and what does not

The practical consequence is that a rollback plan is worth writing at the moment it feels least necessary, which is before anything is signed. At that point every item in the right-hand column is still cheap: the old process is still being practised by people who are still employed, nothing has left the building yet, and the notice period is a line in a draft rather than a term you are bound by. Every week that passes makes each of those harder and none of them easier. The version that fits on a page is enough, and it answers four questions: what would make us stop, what would we go back to and who still knows how, who is allowed to decide, and what would we not be able to undo. The fourth is the one that changes decisions, because writing it down before adoption occasionally reveals that the answer is more than anybody was prepared to accept, and that discovery is worth far more than the plan itself.

Seen in the wild

An automation switched off, leaving records half-processed in two systems.
Zapier
A workflow nobody can run manually any more because nobody has for a year.
Make
A search deployment removed, and staff returning to a process they now find slow.
Glean

Common misconceptions

People assume

We can just stop using it.

In fact

Stopping is easy and returning to the previous state is not. The old process has decayed, material has already gone outward, and people have reorganised their work around the tool, none of which reverses when the switch does.

People assume

A rollback plan is a technical document.

In fact

Most of what makes rollback hard is not technical. The fallback process, who is allowed to decide, the notice period and what genuinely cannot be undone are the substance, and none of them is a system operation.

Questions

What should the plan actually contain?: The trigger that would start it, the process people would return to and who still knows it, who is authorised to make the call, and an honest list of what cannot be reversed at all. Four short sections, written before anything is signed.
Why does the old process stop working?: Because it stops being practised. Documentation ages, the steps are no longer in anybody's hands, and people who did it from memory leave. A fallback assumed to be sitting there is usually a fallback nobody has attempted in a year.
What genuinely cannot be undone?: Anything that left your systems. Material sent to a service can be deleted on request and cannot be un-received, so that exposure outlives the decision to reverse it and belongs in the assessment made before adoption rather than in the plan for undoing it afterwards.