When software stops being trustworthy, the reflex is to start again. Sometimes that is right. Often it is the expensive answer to a question nobody has finished asking.
Assess before recommending
A rebuild takes longer than it looks, repeats the same design decisions under time pressure, and creates a cutover risk the current system does not have. Meanwhile a system that fails weekly may have one root cause in one component, and an application everyone calls legacy may have a sound data model behind a bad interface.
So the work starts by looking: tracing the actual failures, reading the code that matters, and establishing what the business genuinely depends on — then setting out repair, replace and rebuild with the cost and risk of each, rather than leading with a conclusion.
Where the engineering effort concentrates
Assessment and root-cause analysis; an evidence-based recommendation on what to retain, redesign, connect or rebuild; incremental restructuring that keeps the existing system running throughout; and the monitoring, tests and documentation that stop the same class of problem returning quietly.