How to rescue a failing software project (before you rewrite it)

The instinct when a project is failing is to rewrite it from scratch. Sometimes that's right — but more often the rewrite takes longer than expected, loses business logic nobody documented, and lands in the same place eighteen months later. The rescue sequence we use starts with an audit, not a rebuild.

Week one: get the code, the database and every credential under your ownership. We've seen rescues stall for weeks because the old vendor held the deployment access. Ownership first, always — and it should have been yours from day one.

Weeks two and three: a written audit. What the system actually does, which parts are load-bearing, where the tests are (usually: nowhere), and which three changes would stabilise it most. The output is a ranked list, not a 60-page report nobody reads.

Then stabilise before you extend: automated backups you've actually restored, monitoring with alerts, a deploy process that doesn't require heroics, and regression tests on the flows that make you money. New features come only after the floor stops moving.

The rewrite question gets re-asked after stabilisation, with real information. Roughly a third of the time the answer is still yes — but now it's a planned rewrite with a migration path, not an escape from a fire. The other two-thirds of systems turn out to be worth keeping.