Legacysoftwaremoderniseren
Het begint bij de noodzaak, niet bij de techniek
Bij bijna elk bedrijf draait software die nog werkt, maar die niemand meer durft aan te raken. De vraag is zelden of het ooit vervangen moet. De vraag is wat het je nú kost om het te laten staan: gaten die niet meer gedicht worden, een kleine wijziging die weken duurt, en elk jaar minder mensen die het systeem nog kennen. Wij bouwen de nieuwe versie ernaast en zetten stap voor stap over — geen big bang, geen stilstand.
Waaraanjemerktdathetmoet
Niemand begint aan een moderniseertraject omdat de techniek oud is. Het begint omdat er iets knelt:
-
De bouwer is weg — de leverancier bestaat niet meer of de mensen die het schreven zijn vertrokken, en de kennis is met ze meegegaan.
-
Er komen geen security-updates meer — wat er aan lekken gevonden wordt, blijft bij jou gewoon openstaan.
-
Een kleine wijziging duurt weken — niet omdat het werk groot is, maar omdat niemand durft te raken wat er staat.
-
Je vindt er geen mensen meer voor — en de mensen die je hebt, willen liever aan iets anders werken.
-
Iemand stelt vragen die je niet kunt beantwoorden — een audit, een verzekeraar, of een klant die wil weten hoe het met je beveiliging zit.
Eén van deze punten is vervelend. Drie tegelijk betekent dat de beslissing eigenlijk al genomen is; alleen het moment nog niet.
Tweesoortenverouderdesoftware
Bijna elk verouderd systeem valt in een van twee bakken, en welke dat is bepaalt de rekening.
Soms is de taal zelf het probleem: er komen geen updates meer en er zijn nauwelijks nog mensen voor te vinden. Dan bouw je opnieuw.
Maar vaker draait het systeem in een taal die springlevend is — Python, Java, Go, Node.js — en is alleen de versie jaren achtergebleven. Dan hoef je niets opnieuw te bouwen: je haalt het bij de tijd binnen de stack die er al staat. Dat tweede geval is aanzienlijk goedkoper, en het is precies waar wij het meeste van hebben gezien.
Alsdetaalhetprobleemis
Perl, Visual Basic, Delphi, PHP van twee hoofdversies terug. Wat hier wringt is meestal niet de taal zelf, maar wat eromheen is weggevallen: de bouwers zijn vertrokken, de bibliotheken eronder worden niet meer onderhouden, en een vacature levert niets op.
Perl is daar een goed voorbeeld van, en meteen een nuance die we eerlijk willen maken: Perl zelf wordt nog gewoon onderhouden en er komen nieuwe versies uit. Het risico zit in code van vijftien tot twintig jaar oud, in modules eronder waar niemand meer naar omkijkt, en in het feit dat je er geen mensen meer voor vindt. Bij Visual Basic 6 en oude Delphi-versies ligt het anders — daar is de ondersteuning zelf allang gestopt.
Wat we dan doen: eerst vastleggen wat het bestaande systeem werkelijk doet, inclusief het gedrag dat nergens beschreven staat. Daarna de nieuwe versie ernaast bouwen. Pas overzetten als aantoonbaar is dat het nieuwe hetzelfde doet als het oude.
Alsdetaalprimais,maarhetsysteemachterloopt
Dit is het geval dat het vaakst wordt onderschat. Python, Java, Go en Node.js bestaan al decennia en zijn volop in ontwikkeling — maar een versie die uit support loopt krijgt geen securityfixes meer, ook al heet de taal nog hetzelfde.
Een applicatie op een oude Java-versie is niet zomaar "een Java-applicatie" zoals eentje die op de huidige LTS draait: de frameworks eromheen zijn verder, de tooling ook, en de beveiligingsupdates zijn opgehouden of alleen nog tegen betaling te krijgen. Hetzelfde geldt voor een Node-versie die vorig jaar uit onderhoud liep, of voor Python 2 dat al sinds 2020 stil staat.
Hier hoef je niets opnieuw te bouwen. Je upgradet, in stappen, met tests die aantonen dat er onderweg niets omvalt. Dat is het soort werk waar wij goed in zijn — en het is de reden dat een moderniseertraject veel vaker meevalt dan mensen verwachten.
Waardegrenzenvandaagliggen
Of iets nog ondersteund wordt is geen mening, het staat in de releasekalender van de taal zelf:
-
Java — 8 en 11 zijn uit premier support (sinds 2022 en 2023); 17 valt op 30 september 2026 af. 21 en 25 lopen door.
-
Python — 2.7 stopte in januari 2020, 3.8 en 3.9 inmiddels ook; 3.10 valt op 31 oktober 2026 af.
-
Go — alleen de twee laatste releases krijgen fixes: 1.26 en 1.27. Alles daaronder niet meer.
-
Node.js — 18 stopte in april 2025, 20 in april 2026. 22, 24 en 26 lopen door.
-
PHP — 7.4 en 8.0 zijn er al jaren uit, 8.1 sinds eind 2025. 8.2 loopt eind 2026 af.
-
Visual Basic 6 — ondersteuning gestopt in 2008.
-
Perl — wordt nog onderhouden; het risico zit in de codebase en in de beschikbaarheid van mensen.
Gecontroleerd op 7 september 2026 tegen endoflife.date. Deze data schuiven door — draait jouw systeem op iets wat er net naast zit, vraag het ons dan gewoon even.
WatAIhieraanveranderdheeft
Twee dingen tegelijk, en ze wijzen dezelfde kant op.
Het risico is gegroeid. Een bekend lek in een verouderd framework is met AI sneller te vinden en te misbruiken dan een paar jaar geleden; veel van het handwerk dat een aanvaller vroeger moest doen, is inmiddels geautomatiseerd. Software die geen updates meer krijgt staat daardoor niet even lang open als vroeger — hij staat sneller open.
En de andere kant is goedkoper geworden. Het taaie deel van een moderniseertraject is altijd hetzelfde geweest: code lezen die niemand meer kent, gedrag reconstrueren, tests schrijven voor iets wat nooit tests had, een framework overzetten. Dat is precies het werk waar AI goed in is. Het verschuift de rekening: trajecten die een paar jaar geleden niet uit konden, kunnen nu wel uit.
Wat niet verandert: elke regel passeert een ervaren engineer voordat hij live gaat, en de verantwoordelijkheid ligt bij ons — niet bij een model.
Hoewehetaanpakken
-
Eerst begrijpen wat er staat. Inclusief het gedrag dat nergens gedocumenteerd is, want dat is meestal het deel waar gebruikers op rekenen.
-
De nieuwe versie groeit naast de oude. Beide draaien, tot je veilig kunt overstappen.
-
Tests komen eerst, niet achteraf. Ze zijn het bewijs dat het nieuwe hetzelfde doet als het oude.
-
Migreren in stukken die je kunt terugdraaien. Geen weekend waarin alles in één keer moet lukken.
-
Je data en je code blijven van jou. EU-cloud, geen lock-in.
Watdatindepraktijkwas
-
ANWB — van een eigen datacenter naar AWS, met Kubernetes eronder en de teams die ermee moeten werken erbij. Lees de case
-
Filogic — van WordPress naar een headless platform op Google Cloud, met een bijna perfecte Lighthouse-score als resultaat. Lees de case
-
Keana — het product is van de klant, het engineeringteam is ZEN. Geen overdrachtsmoment, geen kennis die bij een projectafsluiting het pand verlaat. Lees de case
-
Rabobank — dezelfde beweging op schaal: cloudstrategie, landing zones en patronen voor circa dertig ontwikkelteams. Lees de case
Veelgestelde vragen over moderniseren
Moeten we alles in één keer omzetten?
Nee. We bouwen de nieuwe versie naast de oude en zetten stap voor stap over, in stukken die je kunt terugdraaien. Een big bang is niet alleen risicovoller, het is ook duurder: je betaalt dan voor een periode waarin niemand iets aan het systeem kan veranderen.
Wat als niemand meer weet hoe het systeem werkt?
+
Dat is eerder regel dan uitzondering. We beginnen dan met reconstrueren wat het systeem werkelijk doet — uit de code, uit de data en uit de mensen die ermee werken. Dat gedrag leggen we vast in tests, en die tests zijn later het bewijs dat de nieuwe versie hetzelfde doet.
Kunnen jullie ons systeem ook overnemen en draaiend houden?
+
Ja. Bij Keana zijn wij het voltallige engineeringteam: het product is van de klant, het bouwen, draaien en doorontwikkelen ligt bij ons. Er is dan geen overdrachtsmoment en geen tweede leverancier die eerst ingewerkt moet worden.
Onze software draait op iets wat jullie hier niet noemen. Kunnen jullie dan iets?
+
Waarschijnlijk wel. De vraag die we stellen is voor elke taal dezelfde: krijgt dit nog security-updates, en zijn er nog mensen voor te vinden? Het antwoord daarop bepaalt of je opnieuw bouwt of upgradet — niet welke taal er toevallig op het etiket staat.
Wat kost een moderniseertraject?
+
Dat hangt volledig af van wat er staat. Het verschil tussen "de taal is het probleem" en "alleen de versie loopt achter" is groot, en dat weet je pas als iemand ernaar gekeken heeft. We beginnen daarom klein: één concreet stuk, snel opgelost, en van daaruit verder. Het eerste gesprek van een half uur kost niets.
Even kijken wat er staat?
Stuur ons wat er draait en waar het knelt. In een half uur weet je of het "opnieuw bouwen" of "upgraden" is.