Salvage or Rebuild? A Decision Framework for Failing Software

Do not let frustration choose the architecture

Salvage software when its valuable business logic, data model, and working components can be isolated and tested at an acceptable cost. Rebuild when foundational security, data integrity, architecture, or deployability problems make every change disproportionately risky. In many cases, staged replacement is safer than either permanent patching or a big-bang rewrite.

‘Start over’ can sound like relief after months of missed deadlines. ‘Keep fixing it’ can sound responsible because money has already been spent. Neither instinct is a framework. The prior investment is gone; the decision is which path creates the best future system with the least avoidable risk.

The five-factor salvage test

First, inspect business logic. Proven rules and edge cases may contain years of domain learning; contradictory or inseparable rules may be a replacement signal. Second, inspect data integrity. Consistent, recoverable data favors salvage, while recurring corruption or unsafe schema changes can outweigh otherwise healthy code.

Third, inspect architecture risk. Ask whether the dangerous components can be isolated behind stable boundaries. Fourth, prove test and deployment control: the team must be able to reproduce builds, verify changes, release safely, and roll back. Fifth, compare migration risk. Running two systems in stages can protect continuity, but tightly coupled data may make a controlled cutover safer.

Do not reduce these factors to a fake mathematical score. One severe security or data finding can outweigh several healthy components. The framework exists to make the reasoning and tradeoffs visible.

The often-better answer is staged replacement

Salvage does not mean endless patching. It means preserving validated domain rules, clean data, stable integrations, tested workflows, and supported infrastructure while deliberately removing the constraints that prevent safe delivery.

A rebuild is justified when security cannot be remediated within the current architecture, data cannot be changed safely, the platform is unsupported, or every release causes unrelated failures. Even then, new code is only part of the work. Users, historical data, vendors, operations, cutover, and rollback still require a transition plan.

Before approving any path, require an asset-and-risk map, a transition architecture, and staged commercial milestones that reduce uncertainty before the full budget is committed.