The default answer is not yes.
Legacy is not a synonym for bad. A system that has run a business for twenty years has survived every edge case the business could throw at it. The rules encoded in it were paid for once, in production, by people who found the exceptions the hard way. That is expensive knowledge, and it is the single thing a rewrite is most likely to lose.
Age alone is not a reason to act. Neither is the discomfort of the people who maintain it. The question is not whether the technology is old. The question is whether the technology is now preventing the business from doing something it needs to do.
If you cannot finish the sentence “once this is done, we will be able to …”, the project does not have a business case yet. It has a preference.
Five signals to leave it alone.
None of these are absolute. Two or three together is usually enough to stop a project that was about to start for the wrong reasons.
- The system is stable and nobody is asking it to change
- If the change request queue has been quiet for two years and support runs to a few hours a month, the software is not your constraint. Modernizing produces a newer system that does exactly what the old one did, at considerable cost and risk.
- The platform is still supported
- Supported is not the same as fashionable. .NET Framework 4.8 ships as a component of Windows and has no announced end-of-life. The VB6 runtime has been carried forward onto current Windows releases even though the IDE lost support in 2008. If the vendor is still shipping what you run on, the risk you are worried about may be theoretical.
- Nobody can articulate the after state
- When the strongest argument is “it is old” or “we cannot hire for it”, dig further. Both can be true without justifying a rewrite, and hiring problems are often solved more cheaply by documenting a system than by replacing it.
- The real problem is process, not software
- A lot of what gets blamed on a legacy system is actually a manual handoff, an approval step, or a spreadsheet living beside the application. Replacing the application removes none of those. Map the process first and you will sometimes find the software was never the bottleneck.
- You are about to lose the people who understand it
- This is a signal to act, but not to rewrite. If the two people who know the domain retire next year, the urgent work is capturing what they know, not replacing the code they wrote. Do that first. You may then decide the code can stay.
What to do instead.
Deciding not to rewrite is not deciding to do nothing. There is a middle path that costs a fraction of a modernization project and removes most of the risk people are actually worried about.
- Take the hardware risk off the table
- Most “we must replace this” urgency traces back to a physical machine nobody can buy a replacement for. Virtualizing the environment separates the software’s lifespan from the hardware’s and buys years of runway for a fraction of a rewrite.
- Capture the domain knowledge while you still can
- An Event Storming workshop with the people who actually run the process produces a documented model of the business rules, independent of the code. That artifact holds its value whether you modernize in two years or never.
- Freeze and inventory the dependency surface
- List the third-party controls, drivers, and integrations. Those, not the language, are usually what eventually forces your hand. Knowing which are unsupported tells you how much runway you really have.
- Write down the exit conditions
- Agree in advance on what would change the decision: a specific compliance date, a vendor end-of-life notice, an integration you know is coming. Then revisit on a schedule instead of relitigating it every budget cycle.
The signals that do justify it.
For balance, the other side. These are the conditions under which we tell people to move, and mean it.
- Hardware or an operating system you can no longer run
- When the last supported host is gone and virtualization has run out of road, the clock is real rather than rhetorical.
- A compliance requirement the architecture cannot meet
- Encryption at rest, access logging, data residency, and retention rules are often impossible to retrofit into a design that predates them.
- An integration you cannot build
- If the business needs the data in another system and there is no supported way to get it out, the legacy platform has become the constraint.
- Data that exists but cannot be used
- Systems that record everything and expose nothing are the most common honest case for modernization. The value is not a nicer interface; it is the analytics and machine learning that become possible once events are visible.
- A hiring wall you have actually hit
- Not “it would be hard to hire”. Actually hit: a role open for months, or one person who cannot take a holiday without the business holding its breath.
Modernize, contain, or leave alone.
| Situation | Our recommendation | Why |
|---|---|---|
| Stable system, quiet change queue, supported platform | Leave alone | No business outcome changes. The risk is all downside. |
| Stable system, unsupported hardware | Contain first | Virtualization removes the deadline without a rewrite. |
| Domain experts leaving within a year | Capture knowledge now | Event Storming preserves the rules whether or not you rewrite. |
| Compliance requirement the design cannot meet | Modernize | Retrofitting audit and encryption into a pre-compliance architecture rarely works. |
| Data trapped, analytics or AI blocked | Modernize | The business case is the new capability, not the new stack. |
| Nobody can name what changes afterwards | Do not start | There is no way to tell whether the project succeeded. |
Common questions
Is old software a security risk by itself?
Not automatically. Risk comes from unpatched components, network exposure, and missing access controls, not from the age of the language. A twenty-year-old application on a patched, supported operating system behind proper access control can carry less risk than a new application built carelessly. Assess the actual exposure before treating age as the finding.
Our developers say the system is unmaintainable. Is that enough?
It is evidence, not a verdict. Ask how many changes were requested in the past year and how long each one took. If the answer is almost none, maintainability is not costing you much today. If routine changes take months, you have a real number to build a case on.
What does it cost to decide not to modernize?
Very little, if you do the containment work: virtualize the environment, document the domain, inventory the dependencies. That is a small engagement next to a modernization project, and it leaves you better informed when you revisit the decision.
Would you really tell us not to hire you?
Yes, and we have. The free one-hour consultation ends in a written preliminary recommendation. Sometimes that recommendation is to contain the system and look again in two years.