Comparisons
Repair the system or start again?
Repair is usually worth testing when useful behaviour can be preserved behind a clear boundary. Replacement deserves consideration when the constraint cannot be removed safely within the current system.
Separate frustration from the constraint
A troubled system produces understandable frustration. Slow releases, unreliable tests and recurring incidents make a clean start attractive. But a new implementation still has to reproduce the business rules, handle existing records and support the people doing the work.
Start by describing the actual constraint. Is a particular integration unreliable? Can the team release a change without manual steps? Is a platform reaching the end of support? A specific failure makes options comparable.
What a repair must prove
A repair should restore useful behaviour and make the next change safer. That might mean introducing a repeatable build, protecting a critical journey with tests or replacing one failing integration. Software rescue starts by checking those possibilities.
The experiment needs a boundary. Name the journey that will work, the evidence to collect and the time available. If the repair keeps expanding without bringing a release closer, stop and revisit the decision.
What a rewrite must account for
A rewrite includes discovery, implementation and migration. It may also require a period of running two systems, reconciling data and supporting users through a changed workflow. Those costs belong in the proposal from the start.
Existing behaviour is often poorly documented. Observe real work and record exceptions before treating the current code as disposable. A cleaner architecture is useful only if the replacement still does the job.
Compare complete options
| Consideration | Bounded repair | Replacement |
|---|---|---|
| Existing behaviour | Preserved and checked around the change | Must be discovered and reproduced or deliberately retired |
| Data movement | Often limited to the affected boundary | Requires explicit migration and reconciliation |
| First useful evidence | A critical journey works or releases become repeatable | A replacement path works with representative records |
| Recovery | Back out the repair or contain its effect | Restore the old path and handle records changed since cutover |
Prefer staged replacement where it helps
Repair and rewrite are not the only two end states. A system can keep useful components while replacing the part that creates the constraint. This is often the practical route for legacy modernisation.
Staging only helps if the boundaries are real. Agree where records are written, how the parts communicate and when the old component can be retired. Otherwise two systems can double the operating work without reducing the original problem.
Record the decision and its limits
Write down why the chosen path is better, what remains uncertain and what would change the decision. Include the cost of keeping the business running while the work happens. Revisit those assumptions when evidence changes, rather than defending a technical direction because delivery has already started.
Questions
Is difficult code enough reason to rewrite?
No. Difficult code creates cost, but a rewrite also requires rediscovering behaviour and moving users and data. Compare a bounded repair with the full replacement work.
What if the current platform is unsupported?
That creates a concrete reason to change, especially where security or recovery is affected. It still does not determine whether the safest path is gradual replacement or a single cutover.
How do we avoid an endless rescue?
Define a stopping point and budget for the investigation. Agree what evidence would justify repair, replacement or pausing the work before more delivery begins.
Talk through your situation
Bring the work that is getting stuck. We will help identify what needs attention first.
Book a diagnosis call