Stork Delivery
Make your next deployment reversible
A rollback plan needs to account for data, background work, and external effects as well as the previous application version.
The problem: restoring old code may leave incompatible new state
A release goes live, and an important operation starts failing. The team can restore the previous application image in minutes. That sounds reassuring until the new version has also changed data that the old version cannot read.
Reversibility needs to be designed before the deployment starts.
A practical approach
Separate code from state
Keep a known previous application version and know how to start it. Then inspect the state the new version changes: database structure, stored records, uploaded files, queues, and configuration.
Where practical, introduce compatible changes in stages. A new field can often be added before older code stops using the existing one. Removing the old representation immediately can close off the return path.
The details depend on the application, but the question is consistent: can the previous version safely operate on the state that will exist after this release?
Include work already in flight
A deployment may interrupt imports, scheduled jobs, or queue workers. Decide whether they finish, pause, or resume under the new version.
Check how repeated execution is handled. A worker that restarts after making an external change may not know that the change succeeded unless the operation was recorded and can be reconciled.
Rolling back code does not unsend an email or undo a supplier order. Keep those effects visible in the recovery procedure.
Choose evidence for the decision
Define the checks that determine whether the release is healthy. Include important business operations as well as a basic server response.
A homepage returning successfully does not prove that orders can be submitted or staff can open their work queue. Use safe verification that avoids creating real transactions unintentionally.
Name who can decide to roll back and what evidence would trigger that decision. An incident is a poor time to discover that responsibility is unclear.
Rehearse the return path
Exercise the procedure in an appropriate environment with representative state. Confirm that the team can locate the previous version, apply the required configuration, and verify the recovered workflow.
Document limitations honestly. Some releases require a forward repair or a more involved data recovery instead of a simple version switch.
A reliable deployment process makes the failure path understandable before it is needed. That gives the business more room to deliver improvements without treating every release as an irreversible event.
The result: a release with a demonstrated recovery path
Before release, record the previous version, state changes, decision owner, verification steps, and known limits of rollback. Exercise that plan with representative data and interrupted background work. Confirm the recovered version can complete the important business operation. If rollback is unsafe, document the forward-repair or data-recovery procedure and its expected impact before the deployment decision.