The replacement question often appears when every change takes too long, incidents return and knowledge of the solution is held by a few people. This does not automatically mean that everything should be rewritten. Product, architecture, data and delivery problems first need to be separated.
Modernisation makes sense when the core still creates value
If the system supports the right process, contains important business rules and allows its most problematic parts to be isolated, gradual modernisation usually limits risk. Tests, interfaces, security and architecture can improve while continuity is preserved.
A new solution is justified when the problem has changed
A rebuild becomes reasonable when the current system preserves an obsolete operating model, cannot meet security requirements or makes every subsequent change more expensive despite local repairs. It should still not be a single large leap. The organisation needs a plan for migrating data, functions and users, and a clear point at which the old solution can be retired safely.
A sound decision identifies the first scope rather than merely choosing between “old” and “new”. It may isolate one process, secure the highest-risk area or prototype a new part of the solution using real data.