Legacysoftwaremodernization
The question is not whether. It is what waiting costs.
Almost every company runs software that still works but that nobody dares touch any more. Waiting feels free and is not: 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.
NotusingAIyet?Yourcustomersare.Soareattackers.
Two things changed at once, and they point the same way.
Standing still got riskier. A known hole in an outdated framework is easier to find and exploit with AI than it was a few years ago. Software without updates is no longer exposed "for a while" — it is exposed faster, and not only to people who know what they are doing.
And renewing got cheaper. Reading code nobody knows any more, reconstructing behaviour, writing tests for something that never had any: exactly the work AI is good at, and exactly where most of the money used to go. Projects that did not add up a few years ago can add up now.
What does not change: every line passes a senior engineer before it goes live. The accountability sits with us, not with a model.
Howyouknowitistime
It rarely starts with the technology. It starts because something hurts:
-
The builder is gone — the supplier no longer exists, or the people who wrote it have left.
-
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 those you have would rather work on something else.
-
Somebody asks questions you cannot answer — an audit, an insurer, a customer asking for a certification.
Twokindsofageingsoftware
Almost every ageing system falls into one of two buckets, and which one it is decides the bill.
The language itself is the problem. Visual Basic 6, old Delphi, twenty-year-old Perl. It is rarely the language that hurts but what fell away around it: the builders have left, the libraries underneath are no longer maintained, and a vacancy gets no answers. Then you rebuild.
Or only the version lags behind. Python, Java, Go and Node.js are very much alive, but a version that falls out of support stops getting security fixes. Then you upgrade, in steps, with tests that prove nothing falls over on the way.
That second case is far cheaper — and it is more common than people think.
Wherethelinesaredrawntoday
Whether something is still supported is in the language’s own release calendar, not in a supplier’s quote:
-
Java — 8 and 11 are out of premier support; 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.
-
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.
-
Go — only the two most recent releases get fixes.
-
Visual Basic 6 — support ended in 2008.
Your language not on the list? The question is the same for all of them: does it still get security updates, and can you still find people for it?
Howwegoaboutit
-
Understand what is there first. Including the behaviour that is documented nowhere, because that is usually what 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
Lookingforsomethingelse?
-
Custom software development — software that follows your process, built and run by the same engineers.
-
AI solutions — where AI actually pays off, and where it does not.
-
What we do — the full range: building, modernising, cloud and team reinforcement.
-
Our work — what we built for others, with what it delivered.
Frequently asked questions about modernization
Do we have to move everything across at once?
No. The new version grows alongside the old and you 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, and it is exactly the work AI has made cheaper. We reconstruct what the system actually does — from the code, the data and the people who work with it — and capture that behaviour in tests. Those tests are later the proof that the new version does the same thing.
Is outdated software really a security risk?
+
Yes, and that risk has grown in recent years. Known holes in old frameworks are easier to find and exploit with AI than they used to be. Software that no longer gets updates is not exposed "for a while" any more. A scan starts by mapping which known vulnerabilities are open on your side.
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 sits with us. No handover moment, no second supplier to bring up to speed.
Our software runs on something you do not mention here. Can you still help?
+
Probably. The question is the same for every language: does it still get security updates, and can you still find people for it? That answer decides whether you rebuild or upgrade — not the label the language happens to carry.
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 once somebody has looked. So we start small: one concrete piece, solved quickly, and build out from there. The first half hour 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" — and what is open right now.