--- title: "Een legacy-applicatie moderniseren: waar begin je?" description: "Waar begin je met een legacy-applicatie? Analyseer, stabiliseer productie, bouw een vangnet van tests en vervang stap voor stap in plaats van te herschrijven." canonical: https://sdk.enterprises/nl/insights/modernising-a-legacy-application-where-to-start language: nl --- # Een legacy-applicatie moderniseren: waar begin je? Bijgewerkt: 2026-09-26 > Begin met het moderniseren van een legacy-applicatie door op te schrijven waarom ze moet veranderen, en analyseer daarna de code en de productie samen. Stabiliseer het systeem en zet tests rond het gedrag waar het bedrijf op leunt, voordat je de structuur verandert. Met dat vangnet op zijn plaats vervang je het systeem stap voor stap, verhuis je data weloverwogen en bewaar je een volledige herbouw voor het zeldzame geval waarin weinig het behouden waard is. ## Benoem de zakelijke reden voordat je de code aanraakt Modernisering is duur, dus begin bij de reden. Veelvoorkomende redenen zijn een runtime of framework dat end-of-life is, wijzigingen die weken duren omdat elke release iets breekt, een systeem dat maar één persoon begrijpt, of een platform dat niet kan dragen wat het bedrijf straks nodig heeft. Elke reden wijst naar een andere eerste stap. Schrijf de reden op met een maatstaf die je later kunt controleren, zoals hoe vaak je releaset, hoeveel incidenten je hebt of hoe lang een gemiddelde wijziging erover doet om bij gebruikers te komen. Zonder die maatstaf wordt modernisering een technisch project zonder einde dat bij de volgende budgetronde moeilijk te verdedigen is. ## Analyseer code en productie voordat je iets beslist Een analyse vertelt je wat je werkelijk hebt. Houd haar kort en laat haar eindigen met een schriftelijk rapport en een aanbevolen eerste stap. Lees de code, maar lees ook de productie: logs, incidenten, trage queries en de manier waarop releases verlopen. De ergste problemen zitten vaak rond de code in plaats van erin. - Versies van runtime, framework en libraries, en welke daarvan geen beveiligingsupdates meer krijgen - Welke delen het vaakst veranderen en welke het vaakst breken, op basis van de versiegeschiedenis en het incidentenlog - Testdekking op de routes waar het bedrijf op leunt - Hoe de applicatie wordt gebouwd, geconfigureerd en gedeployd, en wie dat kan - Het datamodel, de omvang ervan en welke andere systemen dezelfde database lezen of beschrijven - De mensen die het systeem kennen, en wat alleen zij weten ## Stabiliseer eerst de productie, zodat het werk een stevige basis heeft Valt het systeem elke week uit, dan wordt de modernisering ook elke week onderbroken. Pak eerst aan wat incidenten veroorzaakt: voeg monitoring en alerts toe op kritieke routes, automatiseer de build en de deployment zodat releases herhaalbaar zijn, en haal geheimen en configuratie uit de code. Deze stappen betalen zich direct terug en maken elke volgende stap veiliger. Ze laten ook vroeg zien of het team het systeem kan veranderen zonder het te breken, en dat wil je weten voordat je je aan een groter plan verbindt. ## Bouw een vangnet van tests rond het gedrag waar je op rekent Legacy-code heeft meestal weinig tests, en het gedocumenteerde gedrag komt zelden overeen met het echte gedrag. Schrijf voordat je de structuur verandert karakteriseringstests: tests die vastleggen wat het systeem vandaag doet, inclusief de vreemde randgevallen, zodat elke verandering in gedrag als falende test zichtbaar wordt. Begin aan de randen, met tests die de applicatie via haar API of gebruikersinterface aanroepen en de resultaten controleren, want die overleven interne wijzigingen. Speel voor berekeningen en rapporten echte invoer af door de oude en de nieuwe code en vergelijk de uitkomsten. Voeg fijnmazigere tests toe aan elk onderdeel terwijl je het refactort. Ons artikel over het upgraden van een kritieke Java 8-applicatie laat hetzelfde vangnet zien bij een runtime-upgrade. ## Vervang het systeem stap voor stap in plaats van het te herschrijven Een volledige herbouw ziet er op papier netjes uit, maar het oude systeem blijft draaien en veranderen terwijl het nieuwe een inhaalslag maakt, en elk ongedocumenteerd gedrag moet onderweg opnieuw worden ontdekt. Daarom duren herbouwprojecten zo vaak langer dan gepland, terwijl het bedrijf wacht. Het gangbare alternatief is het strangler fig pattern. Zet een routeringslaag, zoals een reverse proxy of een API-gateway, vóór de legacy-applicatie. Bouw één functionaliteit tegelijk in de nieuwe code en stuur het verkeer voor die functionaliteit ernaartoe zodra ze zich heeft bewezen. Het oude systeem krimpt tot het kan worden uitgezet, en het bedrijf krijgt bij elke stap waarde. Een herbouw kan nog steeds de juiste keuze zijn: als de codebase klein is en het gedrag goed begrepen, of als het platform waarop ze draait niet lang genoeg in leven kan worden gehouden voor een geleidelijke vervanging. Beslis met schriftelijke criteria, niet uit frustratie. ## Behandel de data als een aparte migratie Code kun je in plakken vervangen; data is moeilijker op te splitsen. Zolang de legacy-code en de nieuwe code één database delen, moet elke schemawijziging worden afgestemd. Bepaal vroeg welk systeem voor elk soort data de bron van waarheid is, en voorkom dat twee systemen hetzelfde record beschrijven zonder een regel over welke schrijfactie wint. Verhuist er een functionaliteit, verhuis of synchroniseer haar data dan weloverwogen: migratiescripts die tegen een kopie van productie zijn getest, of continue synchronisatie zolang beide systemen draaien. Plan hoe je de twee met elkaar afstemt, bijvoorbeeld met dagelijkse tellingen en checksums, en houd de mogelijkheid om terug te schakelen tot de cijfers kloppen. ## Orden het werk op risico en waarde, en laat vroeg voortgang zien Orden het werk zo dat elke stap risico verkleint of iets oplevert wat het bedrijf kan zien. Een gangbare volgorde is: stabiliseren en automatiseren, tests toevoegen, de runtime upgraden en dan de functionaliteiten afsplitsen die het vaakst veranderen. Onderdelen die stabiel zijn en zelden worden aangeraakt, kunnen wachten, soms voor onbepaalde tijd. Houd het plan kort en bekijk het na elke stap opnieuw, want wat je leert, verandert de volgorde. Onze engineers hebben zo gewerkt aan kritieke systemen. Via Sopra Steria leidden ze een migratie van Java 8 naar 16 van een kritieke applicatie voor day-trading in gas, en als onderdeel van het cloudprogrammateam van Crédit Agricole beoordeelden we elke applicatie die we migreerden om te bepalen of ze een upgrade kreeg of werd herbouwd. Wil je een analyse van je eigen systeem, of een team dat het plan uitvoert, dan doet SDK Enterprises beide onder één contract. ## De kern - Schrijf de zakelijke reden voor de modernisering op, met een maatstaf die je later kunt controleren. - Analyseer code en productie samen voordat je kiest tussen upgrade, geleidelijke vervanging en herbouw. - Stabiliseer de productie en zet karakteriseringstests rond kritiek gedrag voordat je de structuur verandert. - Vervang het systeem stap voor stap achter een routeringslaag, tenzij een herbouw duidelijk kleiner en veiliger is. - Plan eigenaarschap, synchronisatie en afstemming van de data als een aparte migratie. ## Veelgestelde vragen ### Moeten we onze legacy-applicatie vanaf nul herschrijven? Meestal niet. Een herbouw concurreert met een systeem dat blijft veranderen en moet gedrag herontdekken dat niemand heeft gedocumenteerd. Vervang het geleidelijk, tenzij de codebase klein en goed begrepen is, of vastzit aan een platform dat niet in de lucht kan worden gehouden. ### Hoe lang duurt het om een legacy-applicatie te moderniseren? Dat hangt af van de omvang van het systeem, de testdekking, hoe verweven de data is en hoeveel er moet veranderen. Een korte analyse geeft je een realistisch plan en een eerste stap die klein genoeg is om af te ronden en te meten, in plaats van één datum voor het hele traject. ### Kunnen we nieuwe functies blijven uitbrengen terwijl we moderniseren? Ja, en dat moet je ook doen. Met geleidelijke vervanging kan het team functies in de nieuwe code opleveren terwijl het legacy-systeem blijft draaien. Spreek af hoeveel van de tijd van het team naar modernisering gaat, zodat het werk aan functies die tijd niet ongemerkt opslokt. ## Begin bij wat je nodig hebt - [Parttime CTO](https://sdk.enterprises/nl/fractional-cto) ## Gerelateerde diensten - [Software op maat](https://sdk.enterprises/nl/services/product-engineering) - [Technische audit en advies](https://sdk.enterprises/nl/services/consulting) ## Verder lezen - [Een kritieke Java 8-applicatie upgraden naar modern Java](https://sdk.enterprises/nl/insights/upgrading-legacy-java) - [Honderden legacy-apps naar AWS migreren zonder vast te lopen](https://sdk.enterprises/nl/insights/migrating-hundreds-of-apps-to-aws)