Old software has an image problem. People see an application built ten years ago and assume the responsible thing is to replace it.
Sometimes it is. Sometimes rewriting it is the most expensive possible way to rediscover why the old system looks strange.
Age is not a defect
Software does not wear out like a bearing. A stable application can keep doing useful work for decades, provided its platform is still supported, its security is maintained and the business still needs what it does.
The fact that the interface looks dated is not, by itself, a technical emergency. It may be a commercial one, which is a different conversation with different economics.
Look for constraints
A rewrite becomes interesting when the existing system prevents necessary change.
Perhaps the runtime is unsupported. Perhaps the architecture makes every modification dangerous. Perhaps nobody can deploy it reproducibly. Perhaps critical integrations depend on obsolete protocols, or the data model simply cannot represent the business anymore.
Those are constraints, and constraints have costs you can put a number against. "Written in 2014" is not a constraint.
Rewrites throw away accumulated knowledge
Old systems contain years of decisions. Some are ugly. Some encode obscure business rules nobody remembered to write in the requirements document.
A clean rewrite can remove those rules by accident, because everybody assumed they were accidental complexity. Then production teaches the team, at some length, why they existed.
Modernisation can be incremental
There is a large space between leaving it forever and rewriting everything.
Upgrade the runtime. Replace one integration. Put an API around a stable core. Move the database. Rebuild the worst screen. Add tests around the behaviour before changing it.
Incremental work is less exciting than a greenfield rewrite. It is also much easier to stop once the business has had enough value out of it, which is a property worth more than it sounds.
Rewrite when the economics say so
Eventually, maintaining the old structure may cost more than replacing it. That decision should rest on future change, risk and operating cost — not on embarrassment about a framework version.
Old software that works is an asset. Old software that stops the business moving is a liability. Know which one you have before reaching for an empty repository.