“We should rebuild it” often describes frustration, not a decision. A legacy system may be untidy but stable in the workflows that matter. A rebuild can also reproduce the same unclear rules in a newer stack.
Start with the business constraint
Name the outcome that is currently failing: slow releases, unreliable payments, unsafe permissions, untraceable data changes or an operating cost that blocks growth. The technical option should serve that outcome.
Stabilise when risk is immediate
Choose stabilisation when critical workflows fail, deployment is unsafe, monitoring is absent or access is fragile. Restore backups, reproducible builds, logs and high-risk workflow tests before changing architecture.
Refactor when the boundary is understood
Refactoring works when a module has clear behaviour, useful tests or fixtures, and an identifiable owner. Replace one boundary at a time while keeping the existing system as the source of truth.
Rebuild when the current boundary cannot support the business
A rebuild may be justified when the data model, security boundary or deployment architecture prevents the required product direction. It still needs staged migration, parallel verification and a plan for historical data.
Questions that prevent a costly guess
- Which workflows already work and must remain stable?
- What evidence proves the current problem?
- Can a smaller boundary solve the business constraint first?
- Who will operate the new system after release?
Common failure mode
Do not treat a new framework as a business case. A rewrite without stable requirements, migration ownership and acceptance evidence can delay recovery while increasing uncertainty.
Related services
For evidence-based recovery and architectural decisions, see Existing Project Rescue & Stabilisation.