Wanneer moet je bestaande software vervangen — en wanneer niet?

Ergens in de organisatie draait een systeem dat er al jaren is. Het is traag, het is lelijk, en niemand weet precies meer hoe het werkt — behalve misschien één medewerker die al drie keer heeft geprobeerd met pensioen te gaan. Maar het systeem draait. De orders komen binnen. De facturen gaan eruit.

De vraag of je dit systeem moet vervangen is een van de moeilijkste beslissingen in IT, omdat zowel te vroeg als te laat handelen geld kost. Bedrijven die te vroeg vervangen, verspillen kapitaal aan een migratie die niet nodig was. Bedrijven die te laat vervangen, betalen jarenlang een verborgen tol in productiviteitsverlies, technische schuld en gemiste kansen.

Hier is een eerlijk kader om de beslissing te maken.

De signalen die zeggen: vervang het

Het systeem schept zijn eigen werklast

Als medewerkers structureel meer dan twee uur per dag bezig zijn met workarounds voor het systeem — handmatige datainvoer tussen systemen, Excel-bestanden als tussenlaag, kopieer-plakwerk dat eigenlijk automatisch zou moeten gaan — dan is het systeem geen faciliterende tool meer. Het is een onderdeel van de workload geworden.

Bereken dit concreet. Vier medewerkers die elk twee uur per dag bezig zijn met workarounds: dat is acht manuur per dag, veertig per week, ruim tweeduizend per jaar. Tegen een gemiddeld kostenniveau van €40 per uur is dat €80.000 per jaar aan verborgen systeemkosten — vóór de kosten van fouten die door handmatig werk ontstaan.

Integratie met moderne tools is niet meer mogelijk

Vrijwel elk bedrijfsproces raakt tegenwoordig aan meerdere systemen: CRM, boekhoudpakket, e-commerce platform, logistiek, communicatietools. Als je legacy-systeem geen API heeft, of alleen een verouderd protocol spreekt dat moderne tools niet ondersteunen, betaal je integratiekosten die onevenredig hoog zijn — of je accepteert informatiesilo's die betere besluitvorming in de weg staan.

Dit punt is bijzonder kritisch als je groeit. Een bedrijf van twintig mensen kan misschien leven met handmatige synchronisatie. Een bedrijf van honderd mensen kan dat niet.

De leverancier heeft het systeem verlaten

End-of-life software is een onderschat risico. Als de leverancier geen beveiligingsupdates meer uitbrengt, draai je een systeem met bekende kwetsbaarheden die niet worden gedicht. Voor systemen die klantdata verwerken is dit ook een AVG-risico. Verzekeraars beginnen vragen te stellen over end-of-life software in hun cyberpolis.

Een systeem zonder actieve leveranciersondersteuning is technisch gesproken op sterven na dood. De vraag is alleen hoe lang het nog functioneel blijft voordat iets onverwachts het neerhaalt.

Één persoon is de enige die het begrijpt

Dit wordt in de wandelgangen "bus factor één" genoemd: als die ene persoon onder een bus komt, is het systeem onbegrijpelijk. Dit is geen hypothetisch risico — het is een continuïteitsrisico dat bij due diligence door kopers en investeerders wordt gesignaleerd.

Systemen zonder documentatie, met code die alleen nog door de oorspronkelijke bouwer te lezen is, worden met elk jaar moeilijker en duurder te onderhouden. Elke aanpassing kost meer dan de vorige.

Beveiligingsproblemen zijn structureel niet oplosbaar

Soms zijn kwetsbaarheden geen softwarebugs maar architecturele problemen. Een systeem dat is ontworpen zonder authenticatielaag, dat plain text passwords opslaat, of dat draait op een verouderde serveromgeving die geen moderne beveiligingstandaarden ondersteunt: dat zijn geen problemen die je met een patch oplost. Dat zijn problemen die vragen om een nieuw ontwerp.

De signalen die zeggen: wacht

Het systeem werkt — alleen niet mooi

Er is een verschil tussen een systeem dat problemen veroorzaakt en een systeem dat oud is maar functioneert. Een lelijk dashboard is geen reden om een systeem te vervangen. Een langzame maar betrouwbare workflow is geen reden om een systeem te vervangen. De vraag is altijd: wat kost het systeem in zijn huidige staat, en wat kost het om het te vervangen? Als de kosten van het systeem lager zijn dan de kosten van migratie plus de risico's van een transitie, is wachten de verstandige keuze.

De terugverdientijd overschrijdt drie jaar

Een softwaremigratie kost tijd, geld en operationele verstoring. Als de jaarlijkse besparing van een nieuw systeem kleiner is dan een derde van de migratiekosten, is de business case zwak. Drie jaar is een vuistregel — voor snelgroeiende bedrijven kan twee jaar acceptabel zijn, voor stabiele organisaties kan vier jaar nog verantwoord zijn. Maar als de terugverdientijd vijf jaar of langer is, is de kans groot dat de organisatie voor die tijd alweer veranderd is.

Er is geen interne capaciteit voor de transitie

Een migratie is niet alleen een IT-project. Het vraagt om betrokkenheid van de mensen die het systeem dagelijks gebruiken, voor het definiëren van requirements, het testen van de nieuwe oplossing en het doorstaan van de initiële ongemakken. Als de organisatie momenteel door een andere grote transitie gaat, als sleutelmedewerkers overbelast zijn, of als er geen intern eigenaarschap te organiseren valt, is de kans op een succesvolle migratie laag — ongeacht hoe goed het nieuwe systeem is.

De middenweg: het legacy systeem inpakken

Er is een derde optie die vaak over het hoofd wordt gezien: het bestaande systeem niet vervangen, maar er een moderne laag omheen bouwen.

Dit heet in de software-architectuurwereld een "strangler fig" benadering — naar de vijgenboom die een andere boom langzaam omgroeit en overneemt. Je bouwt nieuwe functionaliteit in een modern systeem, en zorgt dat dat systeem via een API communiceert met het legacy-systeem. Over tijd verplaatsen steeds meer functies naar de nieuwe laag, totdat het oude systeem zo weinig doet dat het veilig kan worden uitgezet.

Dit is bijzonder nuttig als:

• Het legacy-systeem stabiele kerndatamodellen heeft die de moeite waard zijn om te behouden
• Volledige vervanging operationeel te risicovol is
• Je stap voor stap wilt moderniseren zonder een "big bang" migratie

De keerzijde: een API-laag over een slecht ontworpen legacy-systeem is tijdelijk lood om oud ijzer. Het geeft lucht, maar lost de onderliggende architectuurproblemen niet op.

Twee migratiestrateg­ieën vergeleken

Big bang: alles tegelijk

Je bouwt een compleet nieuw systeem, migreert alle data op een vastgestelde datum, en zet het oude systeem uit. Voordeel: je betaalt niet jarenlang voor twee systemen naast elkaar. Nadeel: het risico is hoog. Als het nieuwe systeem op lanceringsdatum niet goed werkt, heb je geen terugvaloptie.

Big bang-migraties werken het best bij kleinere systemen, goed gedocumenteerde processen en organisaties die de operationele verstoring kunnen opvangen.

Strangler fig: gefaseerde vervanging

Je vervangt het systeem module voor module, waarbij het nieuwe systeem geleidelijk de functies overneemt van het oude. Voordeel: lager risico per fase, continue leercurve, eerder rendement op deelsystemen. Nadeel: hogere totaalkosten, langere doorlooptijd, complexiteit van het draaien van twee systemen naast elkaar.

Voor grote, bedrijfskritische systemen is de strangler fig-aanpak vrijwel altijd de verstandigere keuze — zelfs als de totale kosten hoger uitvallen.

De beslissing

Vervanging is de juiste keuze als twee of meer van de "vervang het"-signalen aanwezig zijn én de business case over drie jaar positief is. Wachten is de juiste keuze als de operationele pijn beheersbaar is en de organisatie de migratiecapaciteit nu niet heeft.

Wat nooit de juiste keuze is: niets besluiten omdat de beslissing moeilijk is. Elk jaar dat een problematisch legacy-systeem blijft draaien, accumuleren de kosten van technische schuld. Die schuld wordt ooit betaald — de vraag is alleen wanneer, en onder welke omstandigheden.