Rescue or rewrite?

When a new team opens a repository, studies it for a few days, and says “it is easier to rewrite everything,” the answer can sound convincing. A failing system, missed deadlines, and technical debt make a clean start feel safer.

A rewrite is not a clean slate

Starting again means rebuilding business rules, user roles, permissions, integrations, data behavior, and the rare scenarios that appeared as the product grew.

Some of that knowledge may exist only in the current code. The real question is not whether the code is good or bad.

Ask whether the existing system can be developed further in a safe and predictable way.

If the core journey works, data is stored correctly, and the risk is concentrated in a few modules, throwing away the foundation is usually wasteful.

Stabilize the critical paths first, then replace the parts that genuinely block progress.

When a rescue makes sense

Keep the working base when users can complete the key scenario and the product’s problems are isolated enough to address incrementally.

• Preserve the working user journey
• Stabilize the riskiest modules
• Add visibility, tests, and documentation
• Replace one problematic boundary at a time

A different decision is needed when every change creates new failures. If developers are afraid to touch core modules, a simple feature crosses unrelated parts of the system, and dependencies are unknown, maintenance becomes expensive.

Signs the foundation may need replacing

A full or staged replacement becomes more reasonable when:

• Architecture cannot support the required scale
• Security cannot be addressed locally
• Critical technologies are no longer supported
• Core logic is fundamentally wrong
• Repair costs approach the cost of a new system

Even then, “rewrite” should not mean stopping the business for months while a replacement is built in isolation.

Use a migration path

Keep the current product available, isolate the most problematic module, build its replacement, migrate data, verify the key scenarios, and then move to the next boundary.

This approach preserves learning and reduces the risk of a single all-or-nothing launch.

Compare the real cost

The comparison must include data migration, complete regression testing, rebuilt integrations, support for the old system during development, user risk, and the time the business loses while the new product is being built.

Sometimes a new version is the right investment. Sometimes six months of work only produces the same product on a different technical foundation.

A responsible assessment should give the business more than one path:

• Keep the system and stabilize it
• Preserve the base and replace risky modules
• Rewrite with a migration plan
• Protect current users during transition
• Compare time, cost, and operational risk
• Choose the option the product can sustain

What a good assessment sounds like

A red flag is a rewrite recommendation made before the team has reviewed the code, infrastructure, data, and critical user journeys. It is equally careless to promise the system can be saved without understanding its condition.

The next step

The honest answer starts with: “Let’s see what works, where the critical problems are, and which option is best for the product.”

The right decision is not the most dramatic one. It is the option with clear scope, known risks, and a realistic route to a stable product.

Conclusion

If you inherited a project from another team, assess what can be preserved before paying for a complete rebuild. A careful diagnosis can save months of work and protect the business while the product evolves.