Rewrite or stabilize? How to decide what to do with failing software

Why a full rewrite is rarely the right first move

A rewrite feels like a clean break. The old code is confusing, the old team is gone, and starting over promises a product you finally understand. The problem is that the business keeps running on the old system while the new one is being built.

A rewrite delays value. Customers and internal users get nothing new until the replacement is ready, and the old system still needs fixes the whole time. It also repeats risk. Existing software holds many decisions about edge cases, integrations, and business rules, and most of them are not written down anywhere. A team rewriting from the outside will miss some of them, and often recreates the same problems with new code.

There is also a quieter issue. If the original problems came from missing technical leadership, unclear ownership, or no reliable release process, a rewrite does not fix any of that. The same conditions tend to produce the same results.

Warning signs your software project is failing

These are the signs we look for when a company tells us its software is in trouble. Any one of them deserves attention. Several together usually mean the product needs a deliberate recovery, not more feature work on top of a weak base.

• Releases are slow or risky, and deployments break things customers rely on.
• Small changes take far longer than they should, or fixing one bug creates another.
• Nobody can clearly explain the architecture, the infrastructure, or who owns what.
• Access to code repositories, hosting, or third-party accounts is incomplete or still sits with a previous vendor.
• There are no automated tests, or the tests that exist are not trusted.
• Customers find incidents before the team does.
• The roadmap keeps waiting on foundation fixes that never get scheduled.
• Business workflows depend on brittle scripts, spreadsheets, or manual workarounds around the product.

None of these signs proves the code must be thrown away. Most of them describe problems with ownership, process, and visibility. Those can be fixed without replacing the product.

When does rewriting software from scratch make sense?

A rewrite is the right call when the existing foundation cannot support the product's next stage. Some situations where that can be true:

• The core data model does not fit the business, and every important feature has to work around it.
• The technology the product depends on is no longer supported and cannot be upgraded in steps.
• Security or data handling problems are built so deeply into the design that patching them is not realistic.
• The product needs to move somewhere the current architecture cannot reach, such as a new platform or a very different way of working.
• The system is small enough, and its behavior well enough understood, that replacing it costs less than repairing it.

Even then, a rewrite is usually safer in stages than as one big switch. Replace one part at a time, keep the old system running until each new part is proven, and move users over gradually.

A decision checklist: stabilize, rebuild in parts, or rewrite

Before deciding, answer these questions honestly. If you cannot answer them, that is the first problem to solve.

• Does the business depend on this software today? If so, stability comes before any rebuild.
• Can the team deploy a change safely and roll it back if something goes wrong?
• Does the business control every system the product runs on, including repositories, hosting, and domains?
• Which specific parts block the roadmap, and which parts work well enough?
• Are the problems in the code itself, or in the process and ownership around it?
• Could the parts that block the roadmap be replaced one at a time while the rest keeps running?
• Who will own the product technically after the decision is made?

If most answers point to process, access, and a few problem areas, stabilize and rebuild selectively. If the answers show that the foundation itself cannot carry the next stage, plan a staged rewrite.

How to stabilize a failing software project, step by step

This is the approach we use in a software project rescue. The same order works whether the recovery is led by your own team or by a partner.

1. Understand before changing. Review the code, infrastructure, release process, and open issues. Talk with the people who know the product and the business goal.
2. Secure access and ownership. Make sure the business controls the repositories, hosting accounts, domains, and third-party services. Gaps here are common after a vendor handoff.
3. Stabilize what matters. Fix the failures that put customers, revenue, or data at risk first. Cosmetic problems can wait.
4. Restore delivery rhythm. Put reliable builds, testing, deployment, and monitoring in place so changes can ship with confidence.
5. Make a practical recovery plan. Decide what to keep, what to refactor, what to rebuild, and where automation or AI can remove manual work. Base it on what you learned, not on first impressions.
6. Rebuild selectively. Replace the parts that block the roadmap. Keep the parts that work.
7. Plan long-term ownership. Keep a committed team on the product, or document it well enough that an internal team can own it.

Stabilization is also what makes an honest rewrite decision possible. Once the system is observable and releases are safe, the team can see which parts are actually weak and which only looked weak from the outside.

What comes after the product is stable

Once the product is stable, the work shifts from recovery to growth. Architecture, infrastructure, CI/CD, and observability need to mature so the roadmap can move faster without new risk. That is the focus of platform scaling and modernization, which strengthens foundations alongside feature work instead of stopping the business.

The product also needs a team that stays with it, so it does not drift back into the same condition. A dedicated development team with technical leadership owns architecture, quality, and delivery, rather than adding individual engineers who wait for direction. You can see how rescue, scaling, and team extension fit together on our use cases page.

Rewrite or stabilize FAQ

Is refactoring the same as rewriting?

No. Refactoring improves the structure of existing code without changing what it does, one part at a time. A rewrite replaces the system, which means rebuilding behavior the business already relies on.

Can we keep shipping features while the software is being stabilized?

Usually some, yes. Fixing what puts customers, revenue, or data at risk comes first, so feature work may slow at the start and then pick up as releases become safer.

What if the previous vendor left little or no documentation?

That is common and is not a reason to rewrite on its own. The code, the infrastructure, and the people who use the product are enough to rebuild an accurate picture, and documentation gets written as the system is stabilized.

How can we tell if a rewrite recommendation is sound?

Ask what specifically in the current foundation blocks the product's next stage, and why it cannot be replaced in parts. A sound recommendation names concrete limits in the system, not just frustration with old code.

If you are weighing a rewrite against stabilizing what you have, we can review the situation with you and give a plain recommendation. Talk through your software challenge.