Legacy Software Moderniseren: De Tikkende Tijdbom?

Het is de nachtmerrie van elke ondernemer: de software waar je hele bedrijf op draait, is verouderd. Het werkt… soort van. Maar aanpassingen doen? Dat durft niemand meer aan. Dit artikel legt uit wanneer software echt "legacy" is, welke risico's je precies loopt, en welke drie routes je hebt — inclusief wat elke route ongeveer kost.

---

Het korte antwoord

Software is legacy zodra ze draait op techniek die geen beveiligingsupdates meer krijgt, of zodra niemand meer durft aan te passen wat erin staat. Je hebt dan drie routes: technisch bijwerken (goedkoopst, lost alleen het veiligheidsprobleem op), geleidelijk vervangen (meestal de beste balans) of opnieuw bouwen (duurst en risicovolst). Wachten tot het systeem echt omvalt is vrijwel altijd de duurste optie, omdat je dan onder tijdsdruk moet beslissen.

---

Wanneer is software eigenlijk "legacy"?

Leeftijd zegt weinig. Een goed onderhouden systeem van acht jaar oud kan prima meekunnen, terwijl een applicatie van drie jaar oud al legacy is zodra de bouwer vertrokken is. Dit zijn de signalen die er wél toe doen:

• De onderliggende taal of het framework krijgt geen beveiligingsupdates meer.
• Er zijn geen geautomatiseerde tests, waardoor elke wijziging een gok is.
• Nieuwe functies duren steeds langer — wat vroeger een dag was, is nu een week.
• De kennis zit in één hoofd, en dat hoofd is niet meer in dienst.
• Er kan niet gekoppeld worden met moderne systemen, omdat er geen API is.
• Niemand durft de server te updaten, uit angst dat de applicatie het niet overleeft.

---

De verborgen risico's van oude software

Beveiliging: patches die niet meer komen

Dit is het meest concrete risico, en het makkelijkst te controleren. PHP — de taal waarin de meeste Nederlandse bedrijfsapplicaties draaien — geeft elke versie twee jaar actieve ondersteuning en daarna nog twee jaar alleen beveiligingsupdates. Daarna stopt het volledig.

Weet je niet op welke versie je draait? Vraag het je hostingpartij of developer — het is een vraag van twee minuten. Draai je op 8.1 of ouder, dan blijven bekende kwetsbaarheden in jouw omgeving permanent openstaan.

Continuïteit: kennis die vertrekt

Zolang de oorspronkelijke bouwer beschikbaar is, valt het mee. Zodra die stopt, blijkt hoeveel er nooit is opgeschreven. Zonder tests en documentatie moet een nieuwe developer eerst maanden reverse-engineeren voordat er iets veranderd kan worden — en dat betaal je.

Groeirem: alles duurt langer

Het duurste effect is het minst zichtbare. Als elke aanpassing weken kost, ga je aanpassingen vermijden. Je proces past zich aan de software aan in plaats van andersom, en concurrenten die wel snel kunnen schakelen lopen langzaam op je in.

Compliance

Verwerk je persoonsgegevens in een systeem dat geen beveiligingsupdates meer krijgt, dan wordt "passende technische maatregelen" onder de AVG lastig te onderbouwen. Bij een datalek is een end-of-life platform een moeilijk verhaal richting de toezichthouder én je klanten.

---

Drie routes — en wanneer welke past

Route 1: technisch bijwerken

Je laat de functionaliteit met rust en brengt alleen het fundament op orde: de taalversie omhoog, dependencies bijwerken, de server actualiseren. Dit lost het beveiligingsprobleem op en verder niets. Verstandig als het systeem functioneel prima voldoet en je vooral het risico wilt wegnemen.

Route 2: geleidelijk vervangen

Je bouwt nieuwe functionaliteit naast het oude systeem en zet module voor module over. Het oude systeem blijft draaien terwijl de nieuwe wereld groeit. Dit is in de meeste gevallen de beste balans tussen risico, kosten en snelheid — en de aanpak die we hieronder uitwerken.

Route 3: opnieuw bouwen

Alles vanaf nul. Aantrekkelijk op papier, want je begint schoon. In de praktijk het risicovolst: er zit jarenlange bedrijfslogica in het oude systeem die nergens beschreven staat — uitzonderingen, koppelingen, randgevallen die pas opvallen als ze ontbreken. Bovendien levert een herbouw pas waarde op bij oplevering. Doen als de functionaliteit toch fundamenteel anders moet, of als het oude systeem technisch echt niet te redden is.

---

Onze aanpak: vernieuwen zonder downtime

Voor route 2 gebruiken we het Strangler Fig Pattern, genoemd naar de wurgvijg die om een boom heen groeit tot die de boom volledig heeft vervangen. In plaats van het oude systeem in één keer uit te zetten, bouwen we een moderne Laravel-laag eromheen.

1. Stabiliseren — we maken de huidige omgeving eerst veilig: server bijwerken, back-ups controleren, de grootste lekken dichten. Dit haalt de tijdsdruk van het project af.
2. In kaart brengen — welke modules zijn er, wie gebruikt wat, en waar zit de meeste pijn? Daarmee bepalen we de volgorde: we beginnen bij het onderdeel dat het meeste oplevert, niet bij het technisch interessantste.
3. Isoleren — we bouwen een API tussen de oude en de nieuwe wereld, zodat beide met dezelfde data kunnen werken zonder elkaar te breken.
4. Overzetten — module voor module herbouwen, terwijl je bedrijf gewoon doordraait. Elke stap gaat pas live als hij bewezen werkt, en kan worden teruggedraaid.
5. Afbouwen — als de laatste module over is, gaat het oude systeem uit. Vaak blijkt onderweg dat een deel helemaal niet meer gebruikt wordt en dus ook niet herbouwd hoeft te worden.

---

Wat het kost

Er is geen standaardprijs, maar de verhoudingen tussen de routes zijn wel voorspelbaar. Technisch bijwerken is verreweg het goedkoopst en zit meestal in de orde van enkele duizenden tot tienduizenden euro's. Geleidelijk vervangen kost meer, maar spreidt zich over kwartalen en levert onderweg al besparing op. Opnieuw bouwen zit doorgaans in dezelfde orde van grootte als het oorspronkelijke project — reken op de bedragen uit wat kost maatwerk software?.

Zet daar de kosten van niets doen tegenover: de uren die je team kwijt is aan workarounds, de omzet die je misloopt doordat je niet kunt koppelen, en het risico van een datalek. Die rekening staat nergens op een factuur, maar loopt wel door.

---

Wanneer je beter niets kunt doen

Niet elk oud systeem hoeft vernieuwd te worden. Laat het met rust als:

• het stabiel draait, niet aan internet hangt en geen persoonsgegevens verwerkt;
• er geen functionele wijzigingen meer nodig zijn en dat de komende jaren zo blijft;
• je het proces binnen een jaar toch vervangt door een standaardpakket — moderniseren is dan weggegooid geld;
• het bedrijfsonderdeel dat de software gebruikt wordt afgestoten of uitgefaseerd.

In alle andere gevallen geldt: de keuze is niet "nu of nooit", maar "op jouw moment of op het moment dat het systeem het voor je beslist".

---

Veelgestelde vragen

Wil je weten waar jouw systeem staat? Bekijk onze dienst software vernieuwen, of lees eerst hoe een software-audit werkt.