Elk MKB-bedrijf dat lang genoeg meedraait, heeft minstens één systeem waar niemand aan wil komen: de ordertool gebouwd door een ontwikkelaar die jaren geleden vertrok, de Access-database die nog maar drie mensen op kantoor begrijpen, de CRM-versie zo oud dat de leverancier er geen facturen meer voor stuurt. Het werkt nog, grotendeels — en dat is precies wat het laat doordraaien tot ver voorbij het punt waarop vervangen al de goedkopere keuze was geweest. Deze gids laat zien hoe u herkent wanneer legacy software die grens is gepasseerd, wat het NCSC zelf zegt over het risico van software voorbij haar ondersteuningsdatum, en hoe een vervangingstraject er in de praktijk uitziet: moderniseren versus volledig opnieuw bouwen, en hoe u risico beheerst terwijl oud en nieuw naast elkaar draaien.
De signalen dat het tijd is om te vervangen, niet te patchen
Niet elk oud systeem is een probleem. Software die nog gewoon doet wat hij moet doen, nog wordt bijgewerkt en nog overal mee kan koppelen wat nodig is, is geen "legacy" in de zin die ertoe doet. De signalen waar u wél op moet reageren zijn specifieker:
- Niemand die begrijpt waarom het zo werkt, werkt hier nog — degene die de eigenaardige bedrijfsregels erin configureerde, is jaren geleden vertrokken, en elke wijziging gebeurt nu via trial-and-error in plaats van met zeker begrip.
- Er is niemand meer om te bellen — de leverancier zette het product end-of-life, of de freelance ontwikkelaar die het bouwde is onvindbaar, waardoor een bug geen weg naar een oplossing heeft behalve dat uw eigen team gaat gokken.
- Kleine wijzigingen kosten onevenredig veel tijd, omdat het systeem al zo lang om zijn eigen beperkingen heen is gepatcht dat niets meer eenvoudig aan te raken is.
- Het kan niet meer wat de rest van uw bedrijf inmiddels verwacht — geen bruikbare export, geen koppeling met uw boekhoudpakket of CRM, geen mobiele toegang.
Zijn twee of meer van deze punten waar, dan is nóg een patch niet meer het goedkopere antwoord.
Het echte risico van software voorbij haar end-of-life
Het NCSC, het Nationaal Cyber Security Centrum, definieert "end-of-life" als het moment waarop een fabrikant heeft aangegeven dat een product niet meer wordt ondersteund of onderhouden, en is expliciet dat dit veel verder reikt dan een oud besturingssysteem: het noemt laptops, printers, access points, smartphones, Windows, Office, macOS en CRM- of CMS-pakketten als producten die allemaal een end-of-life-datum hebben, of iemand in het bedrijf dat nu bijhoudt of niet.
Voorbij die datum noemt het NCSC drie concrete risico's. Kwetsbaarheden: een nieuwe zwakte in end-of-life-software wordt niet meer verholpen met een update, een bijzonder risico voor alles wat met internet verbonden is. Compatibiliteit: een nieuwere applicatie kan simpelweg niet, of onstabiel, werken bovenop een end-of-life-product. Functionaliteit: end-of-life-producten krijgen geen updates meer die ze laten meegroeien met nieuwe mogelijkheden elders — een nieuwere dienst waarmee u wilt koppelen, kan het product mogelijk niet meer herkennen. Het NCSC noemt ook een punt dat makkelijk over het hoofd wordt gezien: een end-of-life-product vormt ook een risico voor uw ándere systemen, omdat één ongepatcht, internet-toegankelijk zwak punt de ingang kan worden naar alles wat ermee verbonden is.
Het eigen advies van het NCSC is om een product te vervangen vóórdat het end-of-life gaat, zodat die beslissing niet onder druk wordt genomen. Is dat niet haalbaar, dan is het advies om de internettoegang van het product te beperken of uit te schakelen in plaats van het volledig blootgesteld te laten terwijl de vervanger wordt gebouwd. Goed om te weten bij aanschaf van de vervanger: het NCSC merkt op dat op bedrijven gerichte producten doorgaans hoger geprijsd zijn dan consumentenversies, specifiek omdat ze een langere ondersteuningsperiode kennen, en dat sommige leveranciers een Long Term Support-versie (LTS) aanbieden die de nieuwste functies inruilt voor meer tijd voordat u hier weer staat.
Moderniseren, of volledig vervangen?
Moderniseren is zinvol wanneer de onderliggende logica nog klopt — de bedrijfsregels die de software vastlegt, weerspiegelen nog hoe u werkt — en de pijn specifiek in de technologie eromheen zit: een verouderde interface, een databasemotor die niemand meer ondersteunt, geen manier om data aan andere tools bloot te stellen. Het doel is smal: vervang de laag die daadwerkelijk faalt, behoud de logica die nog werkt.
Volledig vervangen is juist wanneer het bedrijf voorbij is gegaan aan waar de software voor gebouwd werd, of nieuwe eisen (meer vestigingen, meer koppelingen, mobiele medewerkers) niet zonder ingrijpende verbouwing in de bestaande structuur passen. Het is ook juist wanneer de technologie zelf de beperkende factor is: een platform zo oud dat het elk jaar moeilijker en duurder wordt om ontwikkelaars te vinden die er nog mee werken.
De valkuil die u in beide gevallen wilt vermijden, is beslissen op basis van hoe de software eruitziet in plaats van op basis van deze twee vragen. Een gedateerde interface op een systeem waarvan de logica en het datamodel nog solide zijn, is een moderniseringsproject; een gelikt systeem gebouwd op bedrijfsregels die niet meer kloppen met hoe u werkt, wordt niet opgelost met een nieuw jasje.
Twee manieren om er te komen: big bang of gefaseerd
Een enkele overstap — het oude systeem uitzetten en iedereen op één datum laten overstappen — is op papier de snelste manier om klaar te zijn, en de risicovolste manier om er te komen. Elk probleem van het nieuwe systeem komt in één keer naar boven, bij elke gebruiker tegelijk, zonder terugvaloptie behalve onder druk terugdraaien.
Een gefaseerde aanpak — de vervanger functie voor functie of afdeling voor afdeling bouwen, naast het oude systeem laten draaien, en het oude onderdeel pas uitzetten zodra het nieuwe zich onder echt gebruik heeft bewezen — kost meer kalendertijd, maar faalt veilig. Een probleem in een net gebouwd onderdeel raakt de groep die het gebruikt, niet het hele bedrijf, en het oude systeem blijft een terugvaloptie terwijl het wordt opgelost. Voor een systeem met jaren aan ongedocumenteerde bedrijfslogica is fasering vaak het verschil tussen een project dat wordt afgerond en een project dat halverwege vastloopt.
Welk pad u ook kiest: bepaal vooraf wat "klaar" betekent voor elk onderdeel, en wie moet goedkeuren voordat de oude versie wordt uitgezet — niet nadat er al iets is misgegaan met de nieuwe.
Risico beheersen terwijl oud en nieuw naast elkaar draaien
Een vervangingstraject betekent meestal dat het legacy-systeem nog maanden blijft draaien terwijl de vervanger eromheen wordt gebouwd, en de eigen kwetsbaarhedenbeheer-richtlijn van het NCSC beschrijft precies de discipline die die periode nodig heeft: een doorlopende cyclus van beoordelen (inventariseren wat u heeft, scannen op bekende zwakke plekken), prioriteren (blootstelling, kriticiteit, dreigingslandschap en impact tegen elkaar afwegen), behandelen, evalueren en verbeteren.
De behandelfase telt hier het zwaarst. Het NCSC stelt expliciet dat updaten altijd de beste optie is wanneer die beschikbaar is — maar voor een legacy-systeem richting vervanging is er vaak geen update meer. Voor dat geval noemt het NCSC de twee overige opties: mitigeren (het systeem isoleren, beperken welke netwerken het kunnen bereiken, de configuratie aanpassen) en accepteren, alleen wanneer dat past binnen de daadwerkelijke risicobereidheid van de organisatie. Het eigen voorbeeld van het NCSC van redelijke acceptatie is een systeem dat bijna end-of-life is, met een vervanger die al wordt gebouwd — een bekende zwakte tolereren voor de korte resterende tijd dat het nog in gebruik is, mits die acceptatie een houdbaarheidsdatum krijgt in plaats van stilzwijgend te worden verlengd.
Wordt dit werk uitbesteed, dan is het advies van het NCSC om dit expliciet in het contract vast te leggen: weet precies waarvoor de leverancier verantwoordelijk is qua updaten en wat bij u ligt, zodat een kwetsbaarheid in het systeem dat wordt vervangen niet onbehandeld blijft omdat beide partijen dachten dat de ander het dekte. Ons team Cybersecurity & Identity kan precies deze beoordeling uitvoeren op een legacy-systeem middenin een overgang — wat daadwerkelijk blootgesteld is, wat geïsoleerd kan worden, en wat echt moet wachten tot de vervanger er is.
Data migreren: het onderdeel dat het vaakst wordt onderschat
Niet de software is meestal het lastigste onderdeel van een legacy-vervanging, maar de data die het heeft opgebouwd. Jaren aan handmatige correcties, eenmalige uitzonderingen en velden hergebruikt voor iets anders dan hun oorspronkelijke doel, passen zelden netjes op het datamodel van een nieuw systeem. Reserveer echte tijd om in kaart te brengen welke velden daadwerkelijk betekenen wat uw team denkt, te bepalen welke historie volledig doorzoekbaar moet blijven versus wat naar een alleen-lezen archief kan, en de migratie te testen tegen een echte kopie van productiedata in plaats van een schone steekproef — juist de uitzonderingen zitten niet in een schone steekproef.
Reconcilieer vóór de overstap, niet erna: laat oud en nieuw een bepaalde periode op dezelfde data draaien en vergelijk de uitkomsten, zodat een afwijking naar voren komt als testresultaat en niet als klantklacht. Is de data van het legacy-systeem nooit fatsoenlijk gemodelleerd, behandel dat dan als apart stuk werk vóórdat het vervangingsproject begint — ons team Data & Databases kan beoordelen wat er daadwerkelijk in een oud systeem zit voordat iemand zich vastlegt op een tijdlijn gebaseerd op een gok.
Wat u voorbereidt voordat u een ontwikkelaar belt
- Een echte lijst van wie de bedrijfsregels van het huidige systeem nog begrijpt — degene die weet waarom een uitzonderingsgeval zo wordt afgehandeld, niet het organogram.
- Een volledige inventarisatie van elke koppeling die het oude systeem raakt, inclusief koppelingen die informeel zijn toegevoegd en nergens zijn vastgelegd.
- Een beslissing over welke datahistorie daadwerkelijk actief moet blijven, genomen vóórdat er geprijsd wordt, want dit verandert de scope aanzienlijk.
- Realistische verwachtingen over parallel draaien gedurende een vastgestelde periode, in plaats van één overstapweekend dat perfect moet verlopen.
Veelgestelde vragen
Wanneer moet ik legacy software vervangen in plaats van patchen? Wanneer minstens twee punten waar zijn: niemand begrijpt meer waarom het zo werkt, er is geen leverancier of ontwikkelaar meer om te bellen, kleine wijzigingen kosten onevenredig veel tijd, of het kan niet koppelen met tools die de rest van uw bedrijf inmiddels als standaard beschouwt. Eén op zichzelf is een waarschuwing; twee of meer betekent dat patchen niet meer de goedkopere optie is.
Wat is het verschil tussen legacy software moderniseren en volledig vervangen? Moderniseren behoudt bedrijfslogica die nog klopt met hoe u werkt, en vervangt de technologie eromheen — bijvoorbeeld een verouderde interface of een niet meer ondersteunde databasemotor. Volledig vervangen is juist wanneer het proces zelf is veranderd, of het platform zo oud is dat het elk jaar moeilijker wordt om ontwikkelaars te vinden.
Kunnen we software blijven gebruiken nadat die end-of-life is? Soms, maar het NCSC is duidelijk dat dit een reëel risico met zich meebrengt: nieuwe kwetsbaarheden worden niet meer verholpen, compatibiliteit met nieuwere tools neemt af, en een end-of-life-product kan het zwakke punt worden dat alles blootstelt wat ermee verbonden is. Is een tijdige vervanging niet haalbaar, dan is het advies van het NCSC om de internettoegang van het product te beperken of uit te schakelen in plaats van het volledig blootgesteld te laten.
Hoe lang duurt een legacy-vervangingstraject? Dat hangt af van hoeveel ongedocumenteerde bedrijfslogica en data het oude systeem heeft opgebouwd, en of u kiest voor een gefaseerde uitrol of een enkele overstap. Fasering duurt langer in kalendertijd maar faalt veilig, stuk voor stuk; een enkele overstap kan op papier sneller klaar zijn, maar legt het volledige risico op één datum.
Wat gebeurt er met onze data tijdens de overstap? Die hoort in kaart gebracht, getest tegen een echte kopie van productiedata, en gereconcilieerd te worden door oud en nieuw naast elkaar te laten draaien voordat het oude wordt uitgezet — niet één keer gemigreerd en als correct aangenomen. Dit is meestal het meest onderschatte onderdeel van het project, niet de software zelf.
De volgorde in één keer goed krijgen
Legacy software vervangen loopt vaker mis door een overgeslagen beslissing hierboven dan door de nieuwe technologie zelf: te lang doordraaien op end-of-life-software, kiezen voor een enkele overstap voor een systeem dat niemand meer volledig doorgrondt, of data migreren zonder die eerst te reconciliëren. Ons team Web & Software Development doorloopt de beoordeling, de gefaseerde bouw en de overstap als één samenhangend proces, zodat uw team de ongedocumenteerde regels van het oude systeem niet middenin de migratie ontdekt.