Rescue Your Software Project or Start Over? How to Decide

When a project is in trouble, there are two camps. The first camp says rewrite everything - the code is beyond saving, it is faster to start fresh. The second camp says rescue it - a rewrite will just recreate the same problems in new code.

Both camps are right sometimes. The problem is that most people decide which camp they are in before they have done the work to actually know.

Here is how we approach it.

The question that matters most

Not "is this code good?" The code is almost always bad in a failing project. That is not the diagnostic question.

The question is: is the business logic documented anywhere other than the code?

In most projects that have been running for a year or more, the code is the only place where the actual business logic lives. How the pricing engine works. What the edge cases are in the user flow. Which validations exist for compliance reasons that nobody wrote down. This knowledge is embedded in thousands of lines of code that people are afraid to touch.

A rewrite means throwing all of that away and reconstructing it from scratch. Some of it will get reconstructed correctly. Some of it will get missed. The misses will surface six months after launch as bugs that nobody can explain.

That is the real cost of a rewrite - not the engineering time, but the business logic that does not survive the translation.

When rescue is the right call

Most of the time, rescue is right. I say 80% and I think that is conservative.

Rescue makes sense when the core architecture is not fundamentally broken - just messy. When there is real business logic embedded in the existing code that is not documented elsewhere. When the problems are mostly about code quality, test coverage, and accumulated shortcuts rather than a design that cannot do what the business needs.

A lot of projects that feel unfixable are actually just undertested and under-documented. The code is scary because nobody has cleaned it up and nobody has confidence in changing it. Those are real problems, but they are fixable without starting over.

The rescue approach: spend two to three weeks in diagnosis before touching anything. Read the code. Map the data model. Run whatever tests exist (if any). Talk to the people who built it. Then triage - what needs to work in the next 30 days, what can wait, what can be cleaned up as you go. Surgical improvements, not wholesale replacement.

When a rewrite is the right call

Rewrites are right when the architecture is fighting the business at a fundamental level.

The clearest signal: every new feature requires changes to a core piece of the system that was never designed to be changed. Every sprint, the same fragile part breaks. The team has stopped even trying to fix it and instead routes around it.

The other clear signal: the technology stack is so outdated that it cannot be maintained. Not old - old is fine, most old code runs perfectly well. But unsupported frameworks, unmaintained dependencies, security vulnerabilities with no patches, PHP 5 on a server that cannot be upgraded. When the environment itself is the problem, rescue becomes very hard.

The third signal, and the one people underestimate: the team has completely lost trust in the codebase. When developers are afraid to make changes because they cannot predict what will break, velocity does not just slow down - it stops. You can sometimes recover trust through testing and documentation. Sometimes the damage is too deep and a rewrite is genuinely faster.

The question nobody asks early enough

Before rescue vs. rewrite, there is a more uncomfortable question: why did the project get to this state?

Bad architecture and missing tests are symptoms. The causes are almost always organizational. No single accountable owner. Scope that kept growing without anyone saying no. A team that was moving too fast and did not have the mandate to slow down and do things properly.

If you do a rescue or a rewrite without addressing the cause, you will end up in the same place again in 18 months. I have seen this happen. The rewrite that was supposed to fix everything becomes the new legacy system everyone is afraid to touch.

The process has to change alongside the code.

The honest outside view

If you are inside a failing project, it is almost impossible to see it clearly. You are either too close to the code to evaluate it objectively, or too invested in the decisions that created the mess to admit how bad things are.

That is the main value of an outside assessment. Not a magic solution - just an honest read on what you actually have and what the real options are.

We do this regularly at SimplyShip. Send us a message and we will tell you what we think, without a sales pitch attached.