Legacy Modernisering voor het MKB: Applicaties Vernieuwen Zonder de Winkel Plat te Leggen

Elke MKB-ondernemer kent de spanning: er draait één systeem dat je bedrijf jaren vooruit heeft geholpen, maar inmiddels niemand meer durft aan te raken. Een orderpakket op een Windows Server 2012, een PHP 5-webapp die alleen de oud-ontwikkelaar begreep, een maatwerk Access-database waar de boekhouding en de productieplanning aan hangen. Legacy modernisering gaat over het eerlijke antwoord op die situatie: wanneer vervang je, wanneer bouw je op, en hoe doe je dat zonder de winkel plat te leggen.

Wat is legacy modernisering precies

Legacy modernisering is het geheel aan beslissingen en projecten waarmee je verouderde bedrijfsapplicaties geschikt maakt voor de volgende tien jaar. Dat kan betekenen dat je ze op een moderne cloudomgeving zet zonder de code aan te raken, dat je de pijnlijkste modules herschrijft, of dat je een systeem vervangt door een standaard SaaS-pakket. Het is zelden "alles weggooien en opnieuw bouwen", en nog minder vaak "niets doen".

Een applicatie noemen we legacy zodra één van deze drie dingen geldt: je kunt moeilijk aan ontwikkelaars komen die er nog mee werken, de vendor levert geen beveiligingsupdates meer, of elke kleine wijziging kost disproportioneel veel tijd en risico. Een systeem van 2015 kan al legacy zijn, en een systeem van 2003 kan prima nog een paar jaar mee als het geisoleerd en gepatcht draait.

Waarom MKB-bedrijven uitstellen (en wat dat kost)

Bij elke directie leeft dezelfde onderbuik: zolang het draait, is er geen crisis. Dat is waar, tot het niet meer waar is. McKinsey rekende voor dat bedrijven 10 tot 20 procent extra betalen bovenop elk IT-project puur om bestaande technische schuld te omzeilen, en dat bij een onderzochte verzekeraar de technische schuld per systeem tussen 15 en 60 procent van het IT-budget kostte. Voor het MKB vertalen die cijfers zich in iets concreters: elke nieuwe wens aan het systeem duurt drie keer zo lang als had gemoeten, een storing kost een halve dag productie, en de leverancier die alleen jouw stack nog kent, verhoogt zijn uurtarief jaarlijks.

Uitstellen zelf heeft ook een kostprijs die niet op de factuur staat. Oude systemen draaien vaker op infrastructuur zonder patches, wat je AVG-zorgplicht lastig invult en, als je onder de nieuwe Cyberbeveiligingswet valt, een probleem wordt. Onze complete gids over NIS2 voor het Nederlandse MKB laat zien dat aantoonbaar beveiligingsbeleid onder NIS2 ook over je oude applicaties gaat.

De zes modernisatiepaden op één rij

In de literatuur circuleren meestal zeven R's. Voor het MKB komen we uit op zes paden die er echt toe doen, van minste tot meeste moeite.

1. Retain, bewust niets veranderen

Je laat het systeem staan en accepteert dat uitgangspunt expliciet. Dat kan prima als het stabiel draait, de leverancier nog bestaat en de business weinig vraagt. Belangrijk is dat je het isoleert: eigen netwerksegment, strakke firewallregels, back-ups die werken en MFA op elke login. Zonder die hygiene is retain geen keuze, maar een risico.

2. Retire, de stekker eruit

Soms wordt een systeem nauwelijks nog gebruikt. Export de data, archiveer wat je wettelijk moet bewaren (vaak zeven jaar voor fiscale documenten), en haal het offline. Elk systeem minder is één aanvalsoppervlak minder.

3. Rehost, verplaatsen zonder aanpassen

Je zet de applicatie as-is op moderne infrastructuur, meestal in de cloud. Dit heet ook wel "lift and shift". Je krijgt in weken van verouderde hardware af, maar de software zelf blijft wat het was. Nuttig als je datacenter weg moet, en als tussenstap voor een later refactor-project.

4. Replatform, licht herbouwen

Hier verander je gericht componenten. De zelfbeheerde SQL Server wordt een managed database, de authenticatie verhuist naar Entra ID. De logica blijft intact. Dit is voor veel MKB-bedrijven het aantrekkelijkste pad: het meeste resultaat voor het minste risico.

5. Refactor of rearchitect, de motor opnieuw bouwen

Je houdt het doel van de applicatie, maar je herbouwt stukken van binnen. Een monoliet wordt een paar duidelijke modules, hardcoded integraties worden API's, de UI komt los van de business-logica. Dit loont bij systemen met echte business-waarde die te vaak verandering in de weg zitten.

6. Rebuild of replace, opnieuw of een pakket

Soms past het systeem niet meer bij je bedrijf. Een eigen CRM uit 2010 wordt een moderne SaaS, een maatwerk voorraadsysteem wordt vervangen door een branchepakket. Risico is adoptie: het pakket doet dingen anders, en je processen moeten mee.

Hoe kies je het juiste pad per systeem

Een modernisatieplan voor het MKB is zelden "alles rebuild" of "alles replatform". Het is een portfoliokeuze. Zet je applicaties in een eenvoudige matrix: business-waarde op de ene as, technische gezondheid op de andere.

• Hoge waarde, slechte gezondheid: refactor of rebuild. Dit is waar je investeert.
• Hoge waarde, redelijke gezondheid: replatform. Je versterkt een systeem dat je wilt houden.
• Lage waarde, slechte gezondheid: retire of replace. Niet aan modernisering besteden.
• Lage waarde, redelijke gezondheid: retain. Isoleren en met rust laten.

Deze oefening doe je op één middag met de ondernemer, de IT-verantwoordelijke en iemand die het dagelijkse werk kent. De uitkomst is nooit een cijfer, maar een lijstje met vier of vijf prioriteiten voor het komende jaar.

Het Strangler Fig-patroon in gewone taal

Martin Fowler bedacht in 2004 een beeld dat nog steeds werkt: je nieuwe systeem groeit als een wurgvijg om het oude heen, functie voor functie, tot het oude kan sterven. Voor het MKB is dat belangrijk omdat je zelden een halfjaar zonder bedrijfssysteem kunt. In de praktijk werkt het zo: zet een proxy of API-gateway voor je oude applicatie, bouw nieuwe functionaliteit achter die gateway op moderne infra, en verplaats stukje bij beetje bestaande endpoints van oud naar nieuw. De gebruiker merkt er weinig van, en als een nieuw stuk niet werkt, zet je de verkeer-regel terug.

Dit is bijna altijd beter dan een "big bang" van zes maanden stilte waarin iedereen hoopt dat de nieuwe versie werkt. Een big bang voelt moedig, maar je stapelt er alle risico op één dag mee op.

Wat het kost, in realistische ranges

Modernisering is lastig in één getal te vatten omdat scope alles bepaalt. Een paar vuistregels die wij in MKB-trajecten vaak zien.

• Rehost en replatform van een middelgrote bedrijfsapplicatie: enkele tienduizenden euro's, uit te smeren over een paar maanden. De lopende cloudkosten vervangen deels de oude hardware- en licentiekosten.
• Refactor-trajecten per module: afhankelijk van omvang 15.000 tot 80.000 euro per module, meestal verdeeld over kwartalen zodat de business ritme houdt.
• Volledig rebuild of SaaS-vervanging: zelden onder 50.000 euro, vaak oplopend naar enkele tonnen bij maatwerk met integraties.

Vergelijk deze bedragen niet alleen met "nu niets doen", maar met de kosten die je nu al stilzwijgend betaalt: onderhoud, workarounds, trage releases, risico.

Legacy en de EU Data Act

Wie moderniseert naar de cloud, krijgt met de EU Data Act te maken. Die verordening is per 12 september 2025 van toepassing op clouddiensten. Vanaf januari 2027 mogen providers je geen switching- of egress-fees meer in rekening brengen, en elke overeenkomst moet een exit-clausule met een maximale overdracht van 30 dagen bevatten. Voor jouw modernisatietraject betekent dat: eis vanaf nu portabiliteit op in nieuwe contracten, dus geen harde afhankelijkheid van proprietary data-formaten of één specifieke managed dienst zonder open alternatief. Onze gids over vendor lock-in vermijden in de cloud legt uit hoe je dat in je architectuur verankert.

De zes stappen van een gezond modernisatietraject

1. Portfolio-inventarisatie. Een lijst van alle applicaties met eigenaar, versie, host, gebruikersaantal en status.
2. Waarde-gezondheidsmatrix. Elke applicatie in een kwadrant, met directie en eindgebruikers.
3. Pad per systeem. Retain, retire, rehost, replatform, refactor of replace, met motivatie.
4. Volgorde en MVP. Welke drie systemen pak je in de komende zes maanden, wat is de minimale eerste release?
5. Strangler-aanpak implementeren. Nieuwe functionaliteit achter een gateway, bestaande endpoints stuk voor stuk verplaatsen.
6. Borg de leercurve. Elke oplevering levert kennis op voor de volgende. Documenteer architectuurkeuzes en test-automatisering.

Lees ook onze gids over het opstellen van een IT-roadmap als je dit traject in een breder meerjarenplan wilt zetten.

Veelvoorkomende valkuilen in MKB-trajecten

• Alles tegelijk willen moderniseren. In een jaar vijf systemen vervangen is de klassieke fout. Verdeel over kwartalen.
• Geen testomgeving. Zonder gelijkwaardige test- en acceptatieomgeving mag geen moderne release de lucht in. Reken 10 tot 15 procent van het traject op deze infrastructuur.
• Geen data-strategie. Spreek vooraf af hoe je data migreert en wie eigenaar is van welk veld.
• De oude lock-in vervangen door een nieuwe. Vraag naar export-formaten, documentatie en een exit-clausule voordat je tekent.
• Alleen IT, geen business. Zonder trekker uit de business sneuvelt elke modernisering na drie maanden. Benoem een product owner uit de eindgebruikersgroep.
• Vergeten adoptie. Een nieuwe UI die beter werkt maar anders oogt, voelt in de eerste weken altijd "slechter". Train, communiceer, houd de pijnperiode kort.

Wat je in huis houdt en wat je uitbesteedt

Praktisch zijn drie rollen altijd nodig: een product owner uit je eigen organisatie, een architect die de langetermijnlijn bewaakt, en een team dat bouwt. Dat team kan grotendeels extern, en vaak is dat voor MKB-bedrijven de enige haalbare route. Belangrijk is dat je kennis documenteert bij elk sprint-einde, zodat je niet afhankelijk wordt van die ene senior. Onze software-engineering praktijk is zo ingericht dat kennis en code bij de klant blijven, met gedeelde repositories en overdrachtsmomenten.

Veelgestelde vragen over legacy modernisering

Wanneer is modernisering urgenter dan het voelt? Vier signalen zijn harde urgentie: er is geen leverancier meer die het systeem onderhoudt, de onderliggende infrastructuur krijgt geen beveiligingsupdates meer, je kunt geen ontwikkelaars meer vinden voor de stack, of elke kleine wijziging kost disproportioneel veel tijd. In die situatie is wachten geen keuze meer, maar een risico dat zich bij elke dag opstapelt.

Moeten we naar de cloud, of mag het ook on-premise blijven? Veel MKB-modernisaties gaan naar de cloud omdat managed diensten je ontlasten op patchen, back-up en schaalbaarheid. Maar een stabiele on-premise omgeving kan prima blijven voor applicaties met strakke latency-eisen of specifieke dataclassificaties. De keuze hangt af van je totale beheerkosten, je team en je risicoprofiel. Onze gids over server of cloud helpt die keuze onderbouwd te maken.

Hoe lang duurt een modernisatietraject bij een MKB? Voor een enkele applicatie zie je in de praktijk een paar maanden tot ongeveer twee jaar afhankelijk van omvang en complexiteit. Een rehost kan in weken, een replatform in enkele maanden, een volledige rebuild loopt vaak van zes maanden tot anderhalf jaar. Verdeel je trajecten over kwartaalgewijze releases, dan heb je elke keer een moment om bij te sturen.

Werkt het Strangler-patroon ook voor hele kleine systemen? Ja, en vaak juist dan. Een kleine applicatie laat zich doorgaans in enkele endpoints opdelen die je stapsgewijs achter een proxy nieuw kunt bouwen. Omdat de scope klein is, kun je zelfs een paar functies per sprint migreren. Het idee is universeel: liever elke week een werkende verbetering dan over een half jaar een grote onzekere knal.

Kan subsidie of fiscaal voordeel helpen? Soms wel. Innovatieregelingen zoals de WBSO kunnen een deel van je ontwikkeluren fiscaal gunstiger maken. Toets vooraf of je traject in aanmerking komt voordat je op subsidie rekent.

Conclusie

Legacy modernisering is niet "alles opnieuw" en ook niet "nog maar een jaar wachten". Het is een portfoliokeuze waarin je per systeem bewust kiest tussen retain, retire, rehost, replatform, refactor of replace, en waarin je nieuwe functionaliteit stapsgewijs opbouwt in plaats van in één grote knal. Begin met een eerlijke inventarisatie, kies drie systemen voor dit jaar, bouw achter een gateway en houd je team scherp op kennisoverdracht.

Loop je vast op de vraag welk pad bij jouw bedrijfssystemen past, of wil je sparren over een haalbaar meerjarenplan dat je business niet platlegt? TRON Group begeleidt MKB-bedrijven in modernisatietrajecten van portfolio-inventarisatie tot oplevering. Je kunt vrijblijvend bellen op 085-3035869 of je plan laten toetsen bij onze software-engineering praktijk.