I earn my living making old systems changeable again. And in a share of first conversations I end up saying: do not do that. Not because the system is too far gone, but because modernization is the answer to a question that, in this case, was never asked.
The debate about legacy systems almost always runs between two camps. One wants to modernize, step by step, while the business keeps running. The other wants to rebuild. Both sides argue about how the system lives on. That it perhaps should not live on at all rarely makes it onto the table.
This article is about the cases where exactly that is the right answer. It comes from somebody who earns money on the opposite, and you should keep that in mind while reading. I have tried to turn it to my advantage: the criteria below are the ones I use myself to decide whether to take on a project.
Four outcomes, not two
A legacy system somebody is thinking about has four possible outcomes, and only one of them is my business.
Modernize. The system stays, but is brought piece by piece into a state where changes are plannable again. It is the right answer when the system does something you need, that no off-the-shelf product does, and that you will still need in five years.
Freeze. The system stays but gets no new features. It is secured, isolated and given an end date. That is the right answer when the remaining lifetime is foreseeable and shorter than any modernization.
Replace with standard software. The system is retired in favour of a product a vendor runs for a thousand other companies. Right when what the system does is not what sets you apart from your competitors.
Retire. The system ceases to exist and its data moves into an archive. Right when nobody depends on it any more, which happens more often than the people involved believe.
The rebuild does not appear in this list, and that is deliberate. A rebuild is not a separate answer to the question of what should become of the system. It is one way of modernizing, and the riskiest; why is covered in its own article. Anyone asking "modernize or rebuild" has already made the real decision without noticing: that the system should live on.
The question that comes before all others
Before the technology, before the budget, before the question of the team, there is a single question: what does this system do for your business that no other system could do the same way?
The answer sorts everything else. A system that writes invoices, counts holiday days or passes orders to a warehouse does something a hundred thousand other companies also do. That function distinguishes you from nobody. It has to run, it should cost nothing, and it is no reason to maintain a system of your own.
A system that encodes your pricing model, which no competitor has, your delivery logic that makes you faster than the market, or an editorial platform a publisher has built its way of working around for twenty years, does something else. It is the reason customers buy from you. Systems like that are worth modernizing, because their value is not in the code but in what the code knows.
A test that holds up surprisingly well in practice: if this system were replaced by an off-the-shelf product tomorrow, which of your customers would notice? If no customer comes to mind, only colleagues who would have to get used to something new, you have a commodity system. Then the question is not how to modernize it, but why you are still running it at all.
The uncomfortable truth here: most systems described as "business-critical" are critical in the sense of "must not fail", not in the sense of "sets us apart". From the inside both feel the same. From the outside it is the difference between modernizing and replacing.
Freezing: when the system runs out before it gets dangerous
There are systems whose end is already fixed. The product line they bill for is being discontinued. The contract they administer ends in three years. The company is being acquired and the buyer brings its own platform. In cases like these, every modernization is money flowing into something on its way out.
The alternative is freezing, and it is regularly misunderstood. Freezing does not mean doing nothing any more. It means doing a very specific set of things and refraining from everything else:
- No new features. That is the core and the hardest part to sustain, because the wish for "just one small change" does not stop simply because the system has an end date.
- Security updates, yes. A frozen system is still on the network. The runtime is maintained, known vulnerabilities are closed. Whatever can no longer be maintained because the version has reached its end of life gets isolated. Zend Framework 1 is such a case: without support since 2016 and still in production in many companies.
- Isolate. The system gets as little network access as possible, as few accounts as possible, and it no longer hangs off other systems that are meant to live on. A frozen system must not take anything down with it when it fails.
- A date and a person. When will it be switched off, and who carries responsibility until then. Without both it is not frozen, just abandoned.
That last point is where freezing differs from neglect, and in practice the difference is often no more than a claim. A system nobody has looked after for years is happily described in hindsight as "frozen". It is not. Freezing is a decision with a date. Neglect is the absence of a decision, and it comes without a date, without isolation and without security updates.
If you freeze a system, write the date into a calendar that belongs to somebody. Not into a document.
Standard software: the price is not the licence
If the question from the second section shows that your system does nothing that sets you apart, a product from the market is usually the cheaper answer. A vendor who runs the same function for a thousand customers does it cheaper, more securely and with fewer outages than any single company could for itself.
Where this route fails is almost always the same place: the twenty per cent the old system was once built for. The standard product can do eighty per cent of what yours does. The remaining twenty are the quirks, the special cases, the exception for that one major customer. Those are exactly what led somebody fifteen years ago to build a system instead of buying one.
At this point there are two routes, and only one of them is a replacement.
The first: you adapt your process to the product. That is cheap, it hurts, and it is the only route where you really end up running standard software. The twenty per cent are partly given up, partly solved outside the system, and partly turn out to be things nobody needs any more.
The second: you adapt the product to your process. Extensions, customizations, modules of your own, a partner who "tailors" the product to you. That is expensive, it does not hurt at first, and in three years you have a legacy system again. Only one that does not belong to you: every vendor update becomes a question of whether your customizations survive, and the person who built them may well be gone by then.
The rule I draw from this: whatever you customize on the product is your next legacy system. Buying standard software means changing your own process. Anyone not prepared to do that should not buy, but ask the first question again: perhaps the twenty per cent really are what sets you apart. Then the system belongs in modernization, not replacement.
Retirement: the outcome nobody proposes
Of the four outcomes, retirement is the one that comes up least in conversations, and there are three reasons for that, none of which has anything to do with the system.
First, nobody earns anything from it. Not the service provider, not the software vendor, not the internal team. Second, the team is afraid: it knows the system, its work hangs on it, and retirement sounds like a verdict on the years before. Third, nobody knows exactly what still depends on it, and the worry about switching off something unknown weighs more than the known cost of keeping it running.
The third reason is the only technical one, and it can be resolved. The question "does anyone still need this" does not have to be guessed. It can be measured:
- Access logs for the last ninety days. Who logs in, how often, and what they do then. On systems considered indispensable, that list is in my experience shorter than everyone expects. Sometimes the only name on it is the one colleague who exports a report every month.
- What accesses it from outside. Interfaces, scheduled queries, scripts feeding another system. Those are the dependencies that really hurt at retirement, and they are in the logs as well.
- Which reports get read. A system whose sole purpose is a report nobody has opened in two years has lost its purpose. That is not a guess, it is in the report's own access log.
If the measurement suggests nobody depends on it any more, what follows is not a plug being pulled but a sequence. First the system is set to read-only: anyone who wants to change something gets a message and a contact. Then it stays that way for a few weeks, and during that time whoever really needs it speaks up. Only then is it switched off, and the data goes where it belongs.
That last point matters more than it sounds. Retention obligations, for business records for instance, are a common argument against retirement. They are almost always an argument for an archive, not for an operation. That data has to remain readable does not mean the application that once produced it has to keep running. An export into a format somebody can still open in ten years serves that purpose better than a server nobody can start in ten years. Which retention periods apply to you and what exactly has to be kept is a matter for your tax adviser; this is not legal advice, only the observation that "is it still running" and "is it still there" are two different questions.
When modernization is the right answer after all
So that this article is not read as "switch everything off": there is a clear set of cases in which modernization is the only sensible answer, and it is not small.
The system does something that sets you apart, and you will still need it in five years. It cannot be bought, because no vendor knows your logic. And it is alive: there are people working with it, customers depending on it, a business that is growing. The editorial platform a publisher built around its way of working over twenty years is such a case, and it was modernized, not replaced; it is on the legacy modernization page.
That a system is old is no argument against it, incidentally. Old legacy code that has earned money every day for fifteen years has fifteen years of contact with reality behind it. That is an asset, not a burden. What turns it into a burden is not its age but the state in which nobody dares touch it any more. And that state can be fixed without throwing it away: piece by piece, each one going live on its own, the old system shrinking while the new one grows. The pattern is called strangler fig, and it is the difference between a modernization and a rebuild that calls itself one.
What modernization is not: the default. It is one of four outcomes, and it should be chosen because the questions below lead there. Not because it was the only one somebody offered.
Four questions that carry the decision
When I look at a system, the criteria from the sections above come down to four questions. They can be answered in an hour if the people who know are in the room.
First: does it set us apart? Would a customer notice if it were replaced by an off-the-shelf product? No: buy or retire. Yes: modernize or freeze.
Second: how long do we still need it? Is there a fixed end that is nearer than any modernization? Yes: freeze, with a date. No: the other three.
Third: who uses it, measured? Not who supposedly needs it, but who has logged in over the last ninety days and what accesses it from outside. Almost nobody: retire, in the sequence above. Many: the other three.
Fourth: do we know what it does? Are there people who can explain its behaviour, tests, documentation, anything besides the code itself? This question does not decide the outcome, but it decides the price of every outcome. A system nobody understands is expensive to modernize, risky to replace and dangerous to retire, because nobody knows what goes with it. If the answer is no, an assessment comes before any decision, whichever decision follows.
Those four questions are, incidentally, exactly what is answered at the end of an assessment. That is why I offer one as a fixed-price entry point, explicitly with the sentence that you can decide against me afterwards. A share of assessments does not end in a modernization by me, and that is not a failure of the tool. It is the point.
The most expensive outcome is not deciding
There is a fifth state that appears on no list, because it is not an outcome. It is the state most legacy systems are in: nobody ever decided about them.
They keep running because they run. They keep costing because nobody adds up the cost. They are not modernized because that would need a budget, not frozen because that would need a date, not replaced because that would change a process, and not retired because nobody knows what hangs on them. Each of the four decisions would be cheaper than this state, and none gets made, because the state has no date on which it hurts.
Until it gets one. The developer leaves, the version falls out of security support, the server dies, an auditor asks. Then the decision gets made, under time pressure, with whatever options are still left at that moment, and that is never all four. What to do in that week is its own article, but the real mistake lies years earlier.
If you take one thing from this article, let it be this: every legacy system in your company should have one of the four outcomes attached to it, with a reason and with a date. Which one matters less than that there is one. And if the outcome is modernization, then please because the questions led there, not because I happened to be the one in the room.
