Most building advice sounds obvious when it is written as a heading. It becomes valuable only when it helps reduce a real idea, choose the next piece of work or decide what evidence would change the plan.
The question behind improve it or rebuild it? is what changes in practice. The useful answer is usually found between separate frustration from constraint and rebuild in slices when possible: the point where a broad idea becomes a choice that can be made, observed and revised.
A messy code path, dated interface or awkward deployment can be annoying without blocking the next useful change. List the concrete constraints first: reliability, security, performance, cost, ownership or an architecture that makes required work impossible.
A replacement includes data migration, parallel operation, missing edge cases, training, rollback and the period where two systems must be understood. The greenfield estimate is usually the smallest part of the decision.
Create a repair option
Define the smallest set of changes that would make the current system acceptable. If that plan is credible and materially cheaper, improve it. If every repair depends on another repair and the core boundaries are wrong, replacement becomes easier to justify.
A controlled replacement moves one boundary at a time and keeps evidence about behaviour. The aim is not to recreate every historical accident. It is to preserve what users rely on while retiring the constraints deliberately.
The aim is not to remove ambition. It is to turn ambition into a finished piece of work that can be used, judged and changed. Smaller honest steps create better information than a large plan that never reaches reality.
That is the standard I would use when returning to improve it or rebuild it?: keep the reason visible, make the next decision small enough to understand, and leave enough evidence to know whether the approach is still helping.