The fix-versus-rewrite question is rarely only technical. It depends on users, data, hidden business rules, deadlines, integrations, and the cost of breaking a workflow that still keeps the business moving.

A rewrite can be the correct answer when the current system blocks change, cannot be secured, or depends on obsolete foundations. But a rewrite is expensive because the old system often contains behavior nobody documented: pricing rules, import exceptions, report formats, admin workarounds, and integration timing.

Symptoms this is your situation

  • The team keeps saying "we should just rebuild this" without a written risk map.
  • New estimates vary wildly because nobody understands the current system.
  • Users still depend on the old workflow even though everyone dislikes the code.
  • Integrations, reports, imports, or admin steps are fragile but business-critical.
  • The system is hard to change, but a full rebuild feels too expensive to approve.

1. Start with current behavior, not code aesthetics

Bad-looking code can still encode valuable business behavior. Clean code can still solve the wrong problem. Before deciding, list the workflows that users depend on and classify which behavior is essential, optional, broken, or obsolete.

2. Separate technical debt from product risk

Technical debt matters when it blocks delivery, increases security risk, slows changes, or makes incidents more likely. It matters less when it is ugly but contained. A rescue review should connect each technical issue to a business consequence.

3. Check whether the system can be stabilized first

Sometimes the safest first step is not a rewrite. It may be a small stabilization sprint: pin dependencies, document deployment, add smoke tests, repair one integration, or isolate a risky component. That can buy enough clarity to make a better rebuild decision.

4. Look for a strangler path

If the system is too risky to replace at once, a gradual replacement path may work better. One workflow, API, report, or admin function can be moved into a new component while the old system keeps running. This reduces the blast radius of modernization.

5. Define migration and rollback before building

Rewrites often fail at the boundary: data migration, user training, operational cutover, and rollback. If the team cannot describe how data will move and how the business can recover from a bad release, the rewrite plan is not ready.

What not to do

  • Do not approve a rewrite only because the code looks old.
  • Do not ask for a fixed build estimate before the current behavior is mapped.
  • Do not ignore data migration, user training, rollback, and support handoff.
  • Do not let a new vendor discover business rules only after implementation starts.
  • Do not treat AI-generated rewrite speed as a substitute for acceptance criteria.

Questions to ask before rewriting

  • Which parts still create business value?
  • Which workflows are painful but stable enough to keep temporarily?
  • Which data must migrate safely?
  • Which integrations are fragile but essential?
  • Which risks can be reduced in one or two weeks?
  • Which behavior must be preserved exactly?
  • What would make a rewrite fail in production?

Fix, rewrite, or replace?

A practical decision usually lands in one of four paths:

  • Repair: the system still works, but needs documentation, tests, deployment clarity, or small fixes.
  • Refactor: valuable behavior should stay, but the code needs safer structure.
  • Replace gradually: one risky area can move out of the old system first.
  • Rewrite: the current foundation is too risky, expensive, or limiting to keep.

Quick checklist

  • Map current workflows before estimating a rewrite.
  • List hidden rules, integrations, reports, and manual workarounds.
  • Identify what must keep running during any migration.
  • Check whether a stabilization sprint can reduce risk first.
  • Define acceptance criteria for the new or repaired system.
  • Plan data migration, cutover, and rollback before build work.

When to request triage

Request triage when the decision is expensive enough that guessing is dangerous. If the next step might be a rewrite, a new vendor, a migration, or a multi-week build sprint, first produce the evidence map: what works, what breaks, what must be preserved, and what can be safely replaced.

Considering a rewrite?

If you are not sure whether the project should be repaired, rewritten, or archived, start with a fixed-scope project rescue triage.

Request Triage

References

  1. Martin Fowler, Strangler Fig Application .
  2. ISO/IEC/IEEE 29148:2018, Systems and software engineering - Life cycle processes - Requirements engineering .
  3. IEEE Computer Society, Guide to the Software Engineering Body of Knowledge (SWEBOK Guide), Version 4.0 .
  4. NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 .