Code recovery should preserve records and uploads created after the release unless a separately approved data recovery requires otherwise. Treat application files and persistent data as different recovery scopes.
IN THIS ARTICLE
What you need before you begin
Identify the last known-good artifact, current schema and new data written since deployment. Decide whether the old code can operate on the current database.
01 Roll back application files without losing new user data
Stop further deployments and assess whether writes need to pause briefly. Record the failure evidence before replacing the active release.
Check compatibility between the recovery code and the current schema. If incompatible, choose a forward fix or a coordinated recovery plan rather than blindly restoring yesterday’s database.
Restore or reactivate the reviewed application artifact through the supported deployment path. Retain current persistent upload and configuration locations.
Reload web and worker processes and rebuild only the necessary release-specific caches. Reconcile jobs whose external outcome is uncertain.
Test existing and newly created customer data, then document the recovery decision and follow-up repair.
02 Example: recover code while preserving a new order
Suppose release 18 becomes active at 09:00. A customer creates order TEST-1042 at 09:05 and uploads a file at 09:07. A display defect is found at 09:10.
If release 17 is compatible with the current database, a reviewed code rollback can restore that application version while retaining the current database and upload store. The acceptance test must include the 09:05 order and 09:07 upload as well as an older record.
Restoring the entire 08:00 backup would instead risk removing both newer items. If the database schema is incompatible with release 17, stop and choose a forward fix or a coordinated data-recovery plan. A backup timestamp alone does not tell you which new customer activity would be lost or how it can be reconciled.
Confirm the expected result
Confirm recent accounts, orders and uploads remain intact and the recovered application can use them. Check both public and administrative workflows.
Troubleshoot unexpected results
If a full database restore becomes necessary, understand the recovery point and how post-backup changes will be preserved or reconciled. A code rollback is not proof that a data restore is harmless.
A common question
Can I restore the entire hosting backup to undo a small code defect?
That can replace much more than the broken code, including newer customer data and mail. Prefer the narrowest recovery that resolves the actual failure.