Advanced guide
When an application becomes painful to change, a clean restart is tempting. Without identifying the real causes, the rewrite may simply move the same risk into new code.
A full rewrite can make sense, but only when the current system is truly blocking operations or future delivery so badly that targeted improvement no longer works.
A stronger decision does not come from the feeling that the code is old or unpleasant. It comes from the business impact, release risk, delivery drag, and cost of further intervention.
The important signs are not aesthetic complaints about the code. They are repeated situations where architecture or data structure makes safe operation and change unreasonably hard.
If the application still supports important operations and the worst issues are concentrated in a smaller set of areas, stabilisation and targeted refactoring are often safer and cheaper.
A practical decision needs an audit of dependencies, data shape, release path, operational constraints, and the company's ability to absorb parallel rebuild work.
The weakest reason for a rewrite is fatigue with inherited code. The strongest reason is a repeatedly confirmed operational, security, or delivery impact that can no longer be handled incrementally.
No. What matters is the concrete effect on operation, security, and delivery speed.
Yes. Selective rewrite or extraction of the most problematic areas is often more practical than a full restart.
For a running business application, yes. Without that, it is hard to separate genuine need from strong frustration.
Next step
Share the context and I will tell you whether the project is a fit.