Bij veel Nederlandse bedrijven draait het orderproces op software die ouder is dan de mensen die er nu mee werken. Zolang alles werkt merkt niemand het, tot de enige collega die de code begrijpt met pensioen gaat of een nieuwe koppeling ineens weken blijkt te kosten.
Legacy systemen zijn verouderde applicaties of platformen die nog steeds een bedrijfskritische rol vervullen, terwijl actieve ondersteuning, kennis en doorontwikkeling ontbreken. Ze draaien vaak op een oude programmeertaal, database of server en zijn lastig te koppelen aan moderne software. Het systeem werkt nog, maar aanpassen of vervangen is duur en riskant.
Hieronder staan de zeven signalen waaraan je legacy software herkent, de risico's die het NCSC benoemt, de afweging tussen behouden, moderniseren en vervangen, en een stappenplan dat je businesslogica bewaart.
Zeven signalen dat je met legacy systemen werkt
Ouderdom alleen zegt weinig over wat legacy is. Een applicatie van vijftien jaar oud die goed getest, gedocumenteerd en gekoppeld is, kan prima meedraaien. Legacy wordt een probleem zodra de organisatie afhankelijk is van iets dat niemand meer veilig kan aanpassen. Deze zeven signalen zie je in de praktijk het vaakst:
- De kennis zit bij één persoon. Eén developer of beheerder weet hoe het systeem werkt. Bij ziekte, vertrek of pensioen staat de organisatie stil.
- Er komen geen updates meer. De leverancier heeft de ondersteuning gestopt, of het pakket bestaat alleen nog als oude versie op een oude server.
- Koppelen kost weken. Elke nieuwe koppeling met een webshop, ERP of planningstool vraagt om maatwerk, nachtelijke bestandsexports of handmatig overtypen.
- De taal of database is verouderd. Denk aan Visual Basic 6, oude versies van Delphi of een Access database met tienduizenden regels code.
- Er zijn geen geautomatiseerde tests. Elke wijziging is een gok, omdat niemand kan controleren wat er verderop in het systeem breekt.
- Je betaalt een hoge licentie voor een oude versie. Upgraden lukt alleen met een herbouw, dus je blijft betalen voor software die stil is blijven staan.
- Het systeem is een beveiligingsrisico. Het draait op een besturingssysteem of framework zonder beveiligingsupdates en de auditor stelt er vragen over.
Herken je drie of meer van deze signalen, dan is het tijd om de afhankelijkheid in kaart te brengen. Een verkennende analyse van je legacy applicaties en de opties voor modernisering laat zien waar het risico het grootst is en wat als eerste aandacht verdient.
Ruud en de planningstool uit 2006
Ruud is hoofd ICT bij een producent van verpakkingsmachines met 120 medewerkers. De productieplanning draait op een applicatie die een inmiddels gepensioneerde collega in 2006 bouwde in Visual Basic. Elke nacht exporteert het systeem een CSV bestand naar het ERP, en elke ochtend controleert een planner handmatig of alles goed is overgekomen. Toen het bedrijf een nieuw magazijnsysteem koos, vroeg de leverancier om een koppeling in realtime. De offerte van de enige externe developer die de code nog kende kwam uit op acht weken werk. Ruud herkende in één keer vijf van de zeven signalen.
Wat zijn de risico's van legacy software
Het Nationaal Cyber Security Centrum (NCSC) besteedt op zijn website aandacht aan legacy systemen. In een aparte pagina beschrijft het NCSC de risico's van legacy systemen. De kern daarvan: software zonder beveiligingsupdates bevat bekende kwetsbaarheden, en aanvallers zoeken die gericht op.
Naast beveiliging spelen vier andere risico's:
- Continuïteit. Uitval van een oud systeem duurt langer, omdat kennis, documentatie en soms zelfs de hardware ontbreken.
- Compliance. Auditors voor ISO 27001, de AVG of sectornormen accepteren steeds minder vaak een server zonder updates.
- Stilstand in de organisatie. Nieuwe wensen, zoals een klantportaal of een dashboard, blijven liggen omdat het oude systeem de data niet kan delen.
- Oplopende kosten. Beheer wordt elk jaar duurder, terwijl het aantal mensen dat kan helpen kleiner wordt.
Een legacy applicatie die jarenlang stil zijn werk doet, valt pas op als hij uitvalt. Op dat moment is er geen tijd meer voor een zorgvuldige keuze.
Legacy systemen behouden, moderniseren of vervangen
Legacy software vervangen is zelden de enige route en lang niet altijd de beste. In de praktijk zijn er drie opties, elk met een eigen moment.
Behouden en isoleren
Het systeem blijft draaien en je beperkt de schade die het kan aanrichten. Je zet het in een apart netwerksegment, zorgt voor werkende reservekopieën en documenteert wat het doet. Deze optie past bij een systeem dat weinig verandert, geen verbinding met internet nodig heeft en over twee tot drie jaar toch wordt uitgefaseerd. Het koopt tijd, meer ook niet.
Stap voor stap moderniseren
Je vervangt het systeem in delen, terwijl het oude blijft draaien. Elk deel dat af is neemt een stuk functionaliteit over. Deze optie past bij een systeem met veel unieke businesslogica, zoals prijsregels, planningsregels of berekeningen waar jaren ervaring in zit. Die logica wil je bewaren en de techniek eromheen wil je vernieuwen. Voor bedrijfskritische software is dit de meest gekozen route, omdat het risico per stap klein blijft.
Volledig vervangen
Je bouwt of koopt een nieuw systeem en zet het oude uit. Deze optie past als het proces zelf is veranderd, als een standaardpakket het werk inmiddels dekt, of als de code zo onbegrijpelijk is dat hergebruik meer kost dan opnieuw beginnen. Vervangen vraagt om een strakke datamigratie en een periode waarin beide systemen naast elkaar draaien.
| Situatie | Meest passende optie |
|---|---|
| Systeem verandert zelden en wordt binnen enkele jaren uitgefaseerd | Behouden en isoleren |
| Veel unieke businesslogica, dagelijks in gebruik | Stap voor stap moderniseren |
| Proces is veranderd of een standaardpakket dekt het werk | Vervangen |
| Niemand begrijpt de code meer en er zijn geen tests | Vervangen, met de oude output als referentie |
Twijfel je tussen twee opties, dan helpt een onafhankelijke blik. In een adviesgesprek over je architectuur en technologiekeuzes beoordelen we samen de code, de koppelingen en de mensen eromheen. Soms is ons advies om het systeem voorlopig te laten staan. Na ruim dertig jaar en 100+ projecten hebben we de meeste varianten al eens gezien.
Fatima en de cliëntregistratie op een oude server
Fatima is manager bedrijfsvoering bij een zorgorganisatie met 35 locaties. De cliëntregistratie draait op een applicatie waarvan de leverancier in 2019 is gestopt, op een serverversie die al jaren geen beveiligingsupdates krijgt. Bij de laatste audit kreeg ze een bevinding met een hersteltermijn van twaalf maanden. Vervangen door een standaardpakket viel af, omdat de registratie vol zit met eigen afspraken per locatie en per financier. Ze koos voor isoleren op korte termijn en moderniseren in delen op de langere termijn. Het eerste onderdeel dat werd vernieuwd was het koppelvlak waarmee andere systemen de cliëntgegevens ophalen.
Een legacy systeem moderniseren zonder businesslogica te verliezen
De grootste angst bij modernisering is dat er iets verloren gaat wat niemand had opgeschreven. Een regel in de code die sinds 2011 bepaalt hoe een korting wordt afgerond, bijvoorbeeld. Een goede aanpak bewaart die kennis en vervangt de techniek eromheen in vier stappen.
Stap één: inventariseren
Breng in kaart wat het systeem doet, welke andere systemen erop leunen en welke data erin zit. Praat met de mensen die ermee werken, want zij kennen de uitzonderingen die de documentatie mist. Het resultaat is een lijst van functies, koppelingen en dataobjecten, met per onderdeel een inschatting van belang en risico.
Stap twee: het oude systeem langzaam omgroeien
De techniek achter deze aanpak heet het strangler pattern, genoemd naar de wurgvijg die om een boom heen groeit tot de boom zelf overbodig is. In gewone taal: je zet een nieuwe laag vóór het oude systeem en leidt het verkeer stukje bij beetje om. Als een nieuw onderdeel hapert, schakel je terug naar het oude. Het legacy systeem sterft langzaam af zonder dat er ooit een grote knal is.
Stap drie: eerst de koppelvlakken
Begin met de plekken waar andere systemen data ophalen of aanleveren. Vervang de nachtelijke exports en directe databasekoppelingen door een API of een integratielaag; hoe zo'n laag werkt lees je in ons artikel over middleware en systemen koppelen zonder spaghetti. Zodra de buitenwereld via het nieuwe koppelvlak praat, kun je de binnenkant vervangen zonder dat andere systemen dat merken.
Stap vier: daarna de modules
Vervang vervolgens module voor module, te beginnen bij het onderdeel met het hoogste risico of de meeste wijzigingen. Schrijf voor elke module tests die het oude en het nieuwe gedrag vergelijken, zodat de businesslogica aantoonbaar intact blijft. Elke opgeleverde module gaat in productie voordat de volgende begint.
Voorbeeld uit de luchtvaart
Voor ST Engineering, actief in de luchtvaart, moderniseerden we een bestaand platform in stappen: de backend ging van GoLang naar .NET en de frontend van Vue 2 naar Angular. Traceerbaarheid en compliance stonden voorop, omdat elke wijziging in deze sector herleidbaar moet zijn. Ons team werkte deels op locatie bij de klant. De volledige beschrijving staat in ons artikel over software voor de luchtvaart bij ST Engineering.
Veelgestelde vragen
Wat is een legacy systeem?
Een legacy systeem is een verouderde applicatie of een verouderd platform dat nog steeds een belangrijke rol speelt in de bedrijfsvoering, terwijl actieve ondersteuning, kennis en doorontwikkeling ontbreken. Het draait vaak op een oude programmeertaal, database of server en is moeilijk te koppelen aan moderne software.
Wat zijn de risico's van legacy software?
De belangrijkste risico's zijn beveiligingslekken door ontbrekende updates, uitval die lang duurt omdat kennis en documentatie ontbreken, bevindingen bij audits en stilstand omdat nieuwe wensen niet aansluiten op het oude systeem. Het NCSC beschrijft deze risico's op zijn website.
Moet je legacy software altijd vervangen?
Nee. Een systeem dat weinig verandert en binnen enkele jaren wordt uitgefaseerd kun je vaak beter isoleren en goed beveiligen. Systemen met veel unieke businesslogica moderniseer je meestal stap voor stap. Volledig vervangen past als het proces is veranderd of als een standaardpakket het werk inmiddels dekt.
Hoe lang duurt het moderniseren van een legacy systeem?
Dat hangt af van de omvang, het aantal koppelingen en de hoeveelheid businesslogica die bewaard moet blijven. Door in delen te werken staat het eerste vernieuwde onderdeel, meestal een koppelvlak, vaak binnen enkele maanden in productie. De volledige modernisering van een groot systeem loopt doorgaans over meerdere kwartalen, terwijl het oude systeem intussen blijft draaien.
Kernpunten en volgende stap
Legacy systemen zijn zelden alleen een technisch probleem. Ze raken de continuïteit, de beveiliging en de snelheid waarmee je organisatie kan veranderen. Onthoud:
- Het probleem zit in afhankelijkheid van iets wat niemand meer veilig kan aanpassen; ouderdom op zichzelf zegt weinig.
- Drie of meer van de zeven signalen betekent dat je de afhankelijkheid in kaart moet brengen.
- Behouden, moderniseren en vervangen zijn alle drie legitieme keuzes, elk voor een andere situatie.
- Modernisering begint bij de koppelvlakken en bewaart de businesslogica met tests.
De volgende stap is een inventarisatie: welke systemen, welke koppelingen, welke mensen. Wij doen dat met een team van 30+ engineers in Nijmegen en Sarajevo, ISO 9001 en ISO 27001 gecertificeerd, en met dezelfde mensen die de software daarna draaiend houden. Plan een vrijblijvend gesprek over je legacy systemen en we vertellen eerlijk welke van de drie opties bij jouw situatie past.
