1. Preserve the current state
Secure the source repository, deployment configuration, database schema, files, credentials inventory, design artifacts, issue history, and vendor accounts. Do not begin cleanup before a recoverable copy exists.
2. Establish whether it runs
Reproduce the development build and, if appropriate, the deployed application. Record exact failures. A system that does not build is a different recovery problem from one that builds but does not satisfy the business workflow.
3. Trace one complete user outcome
Choose the most valuable end-to-end path and follow it across interface, API, data, integrations, permissions, and deployment. This exposes structural gaps faster than counting screens or tickets.
4. Separate assets from liabilities
Classify components as usable, repairable, replaceable, or unknown. Existing code is neither automatically valuable nor automatically disposable. The decision should follow evidence about correctness, maintainability, security, and delivery cost.
5. Define a bounded recovery release
Specify users, outcome, supported path, exclusions, data migration, integrations, controls, test evidence, deployment, documentation, and acceptance. Avoid a vague commitment to “finish everything.”
When should you rebuild?
A selective or complete rebuild becomes reasonable when the current system cannot be made safe, the architecture prevents the required outcome, critical source is unavailable, or repair costs exceed replacement. That conclusion should be an assessment result, not a sales premise.