Rollback Plan Example: A Filled-In Reverse Sequence for a WMS Release
A rollback plan is the reverse sequence, timed and owned, plus the triggers that start it and the point after which it can no longer be run. The example below is from a fictional warehouse management system release: sixteen steps over four hours, each with a duration, an owner and a stated way of verifying it worked.
The example
A distribution centre replaces its warehouse management system over a Saturday night. The forward cutover starts at 20:00 and the site reopens for picking at 06:00 Sunday. The rollback plan below is written against a clock that starts when rollback is declared, not against the wall clock, because the declaration can happen at several points in the window.
Above the table, the plan carries three things the table cannot hold. The triggers: interfaces not stable by T+04:00 in the forward runbook, stock reconciliation variance above 2% after the opening load, or any severity 1 defect with no workaround by 03:00. The authority: the Cutover Manager declares rollback, with the Operations Director as the only person who can overrule. The point of no return: 06:00, after the first despatch wave posts to the ERP, at which point recovery is forward-only. Everything below is fictional.
| Ref | Start (T+) | Duration | Action | System | Owner | Verification |
|---|---|---|---|---|---|---|
| R01 | 00:00 | 00:05 | Declare rollback on the bridge; timestamp the decision and the reason | — | Cutover Manager | Entry in bridge log |
| R02 | 00:05 | 00:10 | Stop all new system interfaces: ERP, carrier, label print | Integration layer | Integration Lead | Queue depth static for 2 minutes |
| R03 | 00:15 | 00:10 | Set new WMS to read-only; log out all RF devices | New WMS | Application Lead | Zero active sessions on console |
| R04 | 00:25 | 00:20 | Export every transaction posted since cutover start | New WMS | Data Lead | Export row count matches interface log |
| R05 | 00:45 | 00:15 | Restore ERP inventory tables from pre-cutover snapshot | ERP | Database Administrator | Checksum matches snapshot manifest |
| R06 | 01:00 | 00:30 | Re-point interfaces to legacy WMS endpoints | Integration layer | Integration Lead | Config diff reviewed by second engineer |
| R07 | 01:30 | 00:20 | Restart legacy WMS services and job scheduler | Legacy WMS | Infrastructure Lead | All services running, scheduler picked up next job |
| R08 | 01:50 | 00:25 | Replay held ERP messages into legacy WMS | Integration layer | Integration Lead | Queue drained to zero, no dead letters |
| R09 | 02:15 | 00:20 | Re-key transactions from the R04 export by hand | Legacy WMS | Operations Supervisor | Line-by-line tick-off against export |
| R10 | 02:35 | 00:15 | Reconcile stock on hand, legacy against ERP | Legacy WMS / ERP | Data Lead | Variance within 0.5%; exceptions listed by SKU |
| R11 | 02:50 | 00:20 | Re-provision RF handsets to the legacy client | Devices | Field Engineer | 12 of 12 devices pass scan test |
| R12 | 03:10 | 00:15 | Smoke test: receipt, putaway, pick, despatch, label | Legacy WMS | Test Lead | Five scripted transactions complete end to end |
| R13 | 03:25 | 00:10 | Restore carrier label printing and manifest upload | Carrier integration | Integration Lead | Test manifest accepted by carrier |
| R14 | 03:35 | 00:10 | Confirm rollback complete to the Cutover Manager | — | Test Lead | Sign-off recorded in bridge log |
| R15 | 03:45 | 00:15 | Notify site management, service desk and vendor | — | Cutover Manager | Comms issued against distribution list |
| R16 | 04:00 | — | Stand down; book review for 10:00 Monday | — | Cutover Manager | Invitations sent, attendee list confirmed |
Reading the example
Start and duration
Relative times, not clock times. A rollback declared at 23:00 and one declared at 04:30 run the same sequence; only the wall clock differs. The durations here add up to just under four hours, which is the number the go/no-go meeting actually needs — it is what gets subtracted from the window to find the latest safe moment to decide.
Action and system
One action per row, and the system it touches named separately so the plan can be filtered by team. R04 and R09 are the pair that carries most of the risk: transactions posted into the new system after cutover started have to come out, and go back in somewhere. The plan handles them by export and manual re-key, and by writing the word "hand" into the step rather than hiding it behind "restore".
Owner
A role, filled by a named person on the contact sheet, with a deputy for each. Six owners across sixteen steps. The Cutover Manager owns only the four steps that are decisions or communications; every technical step belongs to whoever will be typing.
Verification
This is the column that separates a rollback plan from a list of intentions. Each step states how the team knows it worked — a row count, a checksum, a queue at zero, twelve devices out of twelve. Steps that cannot be verified cheaply during the night, such as R10, carry a stated tolerance instead, so the operator is not left deciding at 03:00 what counts as close enough. The Rollback Plan Template keeps the same column for the same purpose.
Triggers, authority and the point of no return
These sit above the table because they are conditions rather than steps. The triggers are written as observable states with numbers attached. Authority is one named role. The point of no return is a time and an event, and it is the entry that changes the shape of the night: after 06:00 the sequence below is no longer available, and the plan says so instead of leaving the team to work it out. How to write a rollback plan covers the three in more detail.
What this example leaves out
It does not say what happens to work in progress on the floor. Pickers who scanned into the new system before rollback have physical stock in the wrong place, and reconciling that is an operational task with no row here.
It has no forward path. Rollback returns the site to Saturday afternoon; deciding when to attempt the release again, and what has to change first, is a separate conversation that happens on Monday. The plan deliberately stops at stand-down.
It also assumes the rollback has been rehearsed. Durations in a plan that has never been executed are estimates, and the difference between an estimate and a measurement is usually discovered at 02:00. Steps R05 to R08 in particular depend on a snapshot restore whose real duration is only known after a dry run — the same reason the Cutover Runbook and Hypercare Pack records planned and actual timings side by side.
And it is not a decision. The plan records the sequence, the triggers and who may call it. Whether the state of the release on the night meets a trigger is a judgement made in the room, usually against the criteria agreed in the go/no-go meeting days earlier.
Questions
How long should a rollback plan take to execute?
It should fit inside the remaining window with time left to verify. In this example the sequence takes just under four hours against a ten-hour window, which sets the latest sensible decision point at around 02:00.
Does every release need a rollback plan?
Every release where reverting is technically possible. Where it is not — an irreversible data conversion, a decommissioned legacy environment — the plan records that fact and the forward-fix approach instead.
Who decides to roll back?
One named role, with a stated deputy. In this example it is the Cutover Manager, with the Operations Director as the only override. Diffuse authority is what turns a two-minute decision into an hour of discussion.
What is the point of no return?
The moment after which the reverse sequence no longer works, usually because live transactions have posted downstream or the legacy environment has been released. It is recorded as a time and the event that causes it.