Legacysoftwaremodernization
It starts with the need, not with the technology
Almost every company runs software that still works but that nobody dares touch any more. The question is rarely whether it will have to be replaced. The question is what it costs you to leave it standing: holes that no longer get closed, a small change that takes weeks, and every year fewer people who know the system. We build the new version alongside the old and move across step by step — no big bang, no standstill.
Howyouknowitistime
Nobody starts a modernisation project because the technology is old. It starts because something hurts:
-
The builder is gone — the supplier no longer exists or the people who wrote it have left, and the knowledge went with them.
-
Security updates have stopped — whatever holes are found stay open on your side.
-
A small change takes weeks — not because the work is big, but because nobody dares touch what is there.
-
You cannot hire for it any more — and the people you do have would rather work on something else.
-
Somebody asks questions you cannot answer — an audit, an insurer, or a customer who wants to know how your security holds up.
One of these is annoying. Three at once means the decision has already been made; only the timing has not.
Twokindsofageingsoftware
Almost every ageing system falls into one of two buckets, and which one it is decides the bill.
Sometimes the language itself is the problem: no updates are coming and there is hardly anyone left to work on it. Then you rebuild.
More often the system runs in a language that is very much alive — Python, Java, Go, Node.js — and only the version is years behind. Then you do not have to rebuild anything: you bring it up to date within the stack that is already there. That second case is considerably cheaper, and it is where we have seen the most.
Whenthelanguageistheproblem
Perl, Visual Basic, Delphi, PHP two major versions back. What hurts here is usually not the language itself but what has fallen away around it: the builders have left, the libraries underneath are no longer maintained, and a vacancy gets no answers.
Perl shows that well, with a nuance we would rather be honest about: Perl itself is still maintained. The risk sits in code that is twenty years old and in modules nobody looks after any more. Visual Basic 6 and old Delphi versions are a different story — there, support itself stopped long ago.
What we do then: first establish what the system actually does, including the behaviour that is written down nowhere. Then build the new version alongside it, and only move across once it is demonstrable that it does the same.
Whenthelanguageisfinebutthesystemlagsbehind
This is the case that gets underestimated most. Python, Java, Go and Node.js have been around for decades and are under active development — but a version that falls out of support stops getting security fixes, even though the language still goes by the same name.
An application on an old Java version is not simply "a Java application" the way one on the current LTS is: the frameworks around it have moved on, so has the tooling, and the security updates have either stopped or are only available commercially. The same goes for a Node version that went out of maintenance last year, or for Python 2, which has stood still since 2020.
Here you do not have to rebuild anything. You upgrade, in steps, with tests that prove nothing falls over on the way. That is the kind of work we are good at — and the reason a modernisation project turns out to be far less painful than people expect.
Wherethelinesaredrawntoday
Whether something is still supported is not a matter of opinion; it is in the language's own release calendar:
-
Java — 8 and 11 are out of premier support (2022 and 2023); 17 drops out on 30 September 2026. 21 and 25 run on.
-
Python — 2.7 stopped in January 2020, 3.8 and 3.9 have since followed; 3.10 drops out on 31 October 2026.
-
Go — only the two most recent releases get fixes: 1.26 and 1.27.
-
Node.js — 18 stopped in April 2025, 20 in April 2026. 22, 24 and 26 run on.
-
PHP — 7.4 and 8.0 have been out for years, 8.1 since the end of 2025. 8.2 runs out at the end of 2026.
-
Visual Basic 6 — support ended in 2008.
-
Perl — still maintained; the risk sits in the codebase and in the people.
Checked on 7 September 2026 against endoflife.date. These dates keep moving; if your system sits just outside one, just ask.
WhatAIhaschangedaboutthis
Two things at once, and they point the same way.
The risk has grown. A known hole in an outdated framework is easier to find and exploit with AI than it was a few years ago. Software that no longer gets updates is therefore not exposed for as long as it used to be — it is exposed faster.
And the other side has become cheaper. The hard part of modernising has always been the same: reading code nobody knows any more, reconstructing behaviour, writing tests for something that never had any. That is exactly the work AI is good at. Projects that did not add up a few years ago can add up now.
What does not change: every line passes an experienced engineer, and the accountability sits with us — not with a model.
Howwegoaboutit
-
Understand what is there first. Including the behaviour that is documented nowhere, because that is usually the part users rely on.
-
The new version grows alongside the old. Both run, until you can switch over safely.
-
Tests come first, not afterwards. They are the proof that the new one does what the old one did.
-
Migrate in pieces you can roll back. No single weekend on which everything has to go right.
-
Your data and your code stay yours. EU cloud, no lock-in.
Whatthatlookedlikeinpractice
-
ANWB — from their own data centre to AWS, with Kubernetes underneath and the teams who have to work with it brought along. Read the case
-
Filogic — from WordPress to a headless platform on Google Cloud, with a near-perfect Lighthouse score as the result. Read the case
-
Keana — the product belongs to the client, the engineering team is ZEN. No handover moment, no knowledge walking out of the building at the end of a project. Read the case
-
Rabobank — the same move at scale: cloud strategy, landing zones and patterns for around thirty development teams. Read the case
Frequently asked questions about modernization
Do we have to move everything across at once?
No. We build the new version alongside the old and move across step by step, in pieces you can roll back. A big bang is not only riskier, it is also more expensive: you pay for a period in which nobody can change anything about the system.
What if nobody knows how the system works any more?
+
That is the rule rather than the exception. We start by reconstructing what the system actually does — from the code, from the data and from the people who work with it. We capture that behaviour in tests, and those tests are later the proof that the new version does the same.
Can you also take our system over and keep it running?
+
Yes. At Keana we are the entire engineering team: the product belongs to the client, and building, running and developing it further sits with us. There is no handover moment and no second supplier who has to be brought up to speed first.
Our software runs on something you do not mention here. Can you still help?
+
Probably. The question we ask is the same for every language: does this still get security updates, and can you still find people for it? The answer decides whether you rebuild or upgrade — not which language happens to be on the label.
What does a modernization project cost?
+
That depends entirely on what is there. The difference between "the language is the problem" and "only the version lags behind" is large, and you only know which one you have once somebody has looked. So we start small: one concrete piece, solved quickly, and take it from there. The first half-hour conversation costs nothing.
Want us to look at what you have?
Tell us what runs and where it hurts. Half an hour is enough to know whether it is "rebuild" or "upgrade".