Pillar page
Modernisering van legacysystemen
Incrementele monoliet-naar-microservices refactoring, migratie van verouderde technologieën naar moderne stacks, cloudmigratie — zonder bedrijfsuitval, met rollbackplan en volledige audit trail.
Elk bedrijf heeft wel een of ander legacysysteem. Sommige hebben er meerdere. Een boekhoudapplicatie uit 2008 die op de een of andere manier nog werkt. Een CRM geschreven door consultants die niemand meer kent. Een magazijn in Access. Elk daarvan zal ooit vervangen moeten worden — de vraag is niet of, maar wanneer en hoe.
Legacy modernisering is een van de moeilijkste soorten IT-projecten. Het vereist het balanceren van drie krachten: bedrijfscontinuïteit behouden (het systeem moet de hele tijd blijven draaien), moderne technologieën introduceren (microservices, cloud, AI) en risicobeheersing (elke refactor kan iets breken dat al jaren werkt).
Waarom niet gewoon „helemaal opnieuw schrijven"?
Uit onze ervaring zijn 9 op de 10 succesvolle moderniseringen incrementele refactoring, geen rewrite. Rewrites zijn conceptueel verleidelijk („we beginnen met een schone lei"), maar in de praktijk hebben ze drie fundamentele problemen:
- Onzichtbare bedrijfslogica. Het oude systeem bevat jaren aan bedrijfsregels — speciale voorwaarden voor de grootste klanten, belastingvrijstellingen voor specifieke sectoren, workarounds voor regelgeving uit 2015. Het meeste is niet gedocumenteerd. Een rewrite moet dit alles reconstrueren uit het geheugen van mensen of uit codeanalyse.
- Dubbel werk. Terwijl het nieuwe systeem wordt geschreven, eist de business nog steeds wijzigingen in het oude (regelgeving, nieuwe klanten, kleine bugs). Het team dupliceert het werk (wijzigingen op twee plaatsen) of bevriest het oude systeem (bedrijfsrisico).
- Big bang deployment. Na een jaar werk is het nieuwe systeem „bijna klaar". Alle gebruikers in één nacht omzetten genereert monumentaal risico. Elk onverwacht probleem betekent terug naar het oude systeem, verlies aan teammoraal, ondermijning van vertrouwen van de business.
Incrementele refactoring (meestal volgens het Strangler Fig-patroon) lost alle drie op: bedrijfslogica wordt geleidelijk ontdekt, één bron van waarheid per entiteit, deployment in fasen met feature flags.
Zes moderniseringspatronen
Elk daarvan adresseert een specifiek risico. In de meeste projecten combineren we er meerdere, waarbij we het patroon per module kiezen.
Strangler Fig
Het oude systeem geleidelijk „omwikkelen" met nieuwe componenten. Oude code blijft draaien, maar elke nieuwe functionaliteit gaat naar een nieuwe microservice en bestaande modules worden één voor één vervangen. Na 12-24 maanden wordt de oude monoliet uitgeschakeld.
Anti-corruption layer
Een adapter die nieuwe code beschermt tegen de eigenaardigheden van het oude systeem (onleesbare veldnamen, vreemde datumformaten, inconsistente types). Alle „lelijke" logica geïsoleerd op één plek — nieuwe code werkt op een schoon domeinmodel.
Database refactoring
Patronen uit Refactoring Databases (Ambler/Sadalage): expand-and-contract voor schemamigraties, datavalidatie voor het verwijderen van oude kolommen, beide schema's parallel houden tijdens applicatiemigratie.
Branch by abstraction
Een abstractielaag rond het oude component introduceren, het nieuwe component parallel implementeren, geleidelijk verkeer omzetten van 0% naar 100% (feature flag). Zonder „big bang" deploy.
Shadow mode
De nieuwe code draait naast de oude — beide verwerken dezelfde verzoeken, maar alleen de resultaten van het oude systeem bereiken de gebruiker. Resultaten worden offline vergeleken. Na bevestiging van compatibiliteit (doorgaans 2-4 weken) zetten we het verkeer om naar de nieuwe code.
Event sourcing voor migratie
We registreren de stream van business events uit het oude systeem en spelen die af in het nieuwe. Hierdoor is voorafgaande validatie van de nieuwe architectuur mogelijk zonder productierisico, en kunnen we naar elke historische toestand terugkeren.
Typisch moderniseringsschema
Voor een gemiddeld systeem (monoliet van ~200k regels code, 5-10 bedrijfsmodules):
- Maand 1: Discovery en documentatie. Reverse engineering van de architectuur, mapping van afhankelijkheden, identificatie van datastromen, documentatie van bedrijfsprocessen met hulp van zakelijke stakeholders.
- Maand 2: Doelarchitectuur en pilot. Ontwerp van de nieuwe architectuur, technologieselectie, pilot op de eenvoudigste module (proof of concept). Eerste validatie van de aanpak.
- Maanden 3-4: Uitsnijden van de eerste productiemodule. Strangler Fig-patroon, shadow mode gedurende 2-3 weken, verkeersomschakeling, hypercare. Eerste echte bedrijfswaarde.
- Maanden 5-12: Iteratief uitsnijden van volgende modules. Elk in een cyclus van 4-6 weken: refactor → tests → shadow → productie → hypercare. Continue procesverbetering, vermindering van tijd per module.
- Maanden 12-18: Datamigratie en monoliet-decommissionering. Zodra alle kritieke modules zijn uitgesneden, ronden we de historische datamigratie af, schakelen we het oude systeem uit, archiveren we. Vieren.
Oud systeem vs. gemoderniseerd
| Aspect | Legacysysteem (typisch) | Na modernisering |
|---|---|---|
| Tijd om een nieuwe feature te leveren | 4-8 weken (hoog regressierisico) | 3-7 dagen (geautomatiseerde tests minimaliseren risico) |
| Testdekking | 5-15% (of geen) | >80%, in de CI/CD-pipeline |
| Beschikbaarheid van ontwikkelaars | Laag (verouderde technologie) | Hoog (populaire, moderne stacks) |
| Security | Oude libraries met ongepatchte CVE's | OWASP-scanning, gitleaks, geautomatiseerde updates |
| Schaling | Verticaal (meer resources voor de monoliet) | Horizontaal (specifieke microservices schalen) |
| Observability | Logs in bestanden, geen metrics | Prometheus + Grafana + Sentry + SIEM |
| Compliance (AVG, EU AI Act, ISO 27001) | Eisend, duur om aan te tonen | Ingebouwd in de architectuur, audit-ready |
Zes typische risico's — en hoe we ze adresseren
Risico: Geen tests in het legacysysteem
Mitigatie: Eerst bouwen we karakteriseringstests (capture tests) — we leggen het huidige systeemgedrag vast op basis van productielogs en verkeersopnames. Pas daarna beginnen we met refactoring, met de tests als vangnet.
Risico: Kennis geconcentreerd bij één persoon („truck factor 1")
Mitigatie: Kennisoverdracht start in de eerste week van het project. Alle bijeenkomsten met de persoon die het systeem kent worden opgenomen en getranscribeerd, kernprocessen gedocumenteerd, architectonische beslissingen onderbouwd. Na het project begrijpt het hele team het systeem.
Risico: Tijdelijke teamvertraging
Mitigatie: In de eerste 2-3 maanden onderhoudt het team het oude systeem + bouwt het nieuwe. Een natuurlijke vertraging in wijzigingstempo. We mitigeren dit door: prioriteit te geven aan wijzigingen die alleen naar het nieuwe systeem gaan, freeze voor wijzigingen met lage prioriteit in de oude codebase.
Risico: Datamigratie
Mitigatie: Elke datamigratie heeft drie fasen: dry-run (op een productiekopie), staging (in een testomgeving met productieschaal van data), productie (in een onderhoudsvenster of incrementeel). Rollbackplan klaar vóór de start.
Risico: Organisatorische weerstand
Mitigatie: Communicatie met de business vanaf dag één: waarom moderniseren, wat verandert voor de gebruiker, wat is het schema, hoe meten we succes. De eerste iteratie wordt zo gekozen dat snel tastbare waarde wordt getoond (bijv. een nieuwe UI of een sneller rapport).
Risico: Kostenonderschatting
Mitigatie: Discovery (1-2 weken) vóór projectprijsbepaling. Iteraties van 2-3 weken met concrete deliverables — makkelijker bij te sturen dan in een lang „alles tegelijk"-project. Budget met een buffer van 20-30% voor het onverwachte.
Veelgestelde vragen
Wat is een legacysysteem?
Waarom moderniseren als het systeem werkt?
Is het niet makkelijker om alles helemaal opnieuw te schrijven?
Vereist modernisering bedrijfsuitval?
Hoe lang duurt een typische modernisering?
Vanaf welke technologieën migreren we het vaakst?
Hoe zit het met bestaande integraties met andere systemen?
Hoe beperkt u het bedrijfsrisico?
Hoe zit het met systeemdocumentatie die er niet is?
Hoe verhouden moderniseringskosten zich tot het onderhoud van het oude systeem?
Laten we beginnen met een audit
Een technische audit van een week: in kaart brengen van de huidige toestand, identificatie van de meest urgente moderniseringsgebieden, een gefaseerd plan met concrete bedrijfsuitkomsten in de eerste iteratie.