Restoring an earlier application image is only one part of a recovery decision. The running system also includes stored records, queued messages, schemas, configuration and external consumers. Once a new version has written data, an earlier version may encounter inputs it has never supported. Review that transition before choosing a recovery command.
Map readers and writers separately
List each component that can create or consume persistent data and messages. Include background jobs, scheduled exports and delayed consumers rather than limiting the map to the web application. Record the old and new versions and the formats each supports. Unknown compatibility should remain an open question with an owner.
Amazon's engineering account of rollback safety describes how protocol changes can make a backward transition unsafe. Its staged approach separates support for reading a new format from the point at which writers begin producing it. This is a useful precedent to examine, rather than a universal guarantee for other systems.
Test the transition that may actually happen
A test of the new version against newly created fixtures does not cover every recovery path. Build a small set of authorized, representative fixtures for old data, new data and a mixed-version period. Check what an older reader does after a newer writer has run. Include delayed messages and retries where the application uses them.
Choose fixtures that expose the intended change: an added field, a changed meaning, a removed value or a different encoding. Make expected behavior explicit. Successful parsing alone may still produce the wrong business action. Review whether retries repeat a payment, duplicate a notification or advance a workflow twice. Those are questions for the actual system owner, not assumptions a deployment tool can resolve.
