Hoe legacy moderniseren zonder de business stil te leggen: het strangler fig pattern

Martin Fowler introduceerde het strangler pattern in 2004 als alternatief voor risicovolle big bang migraties. Bart Demeulenaere, Competence Manager bij Elmos en specialist in software architectuur en modernisatietrajecten, past dit pattern regelmatig toe in onze projecten. "Het identificeren van kritische business kerncomponenten en die stelselmatig omvormen met een technische trucendoos is een haalbaarder track," zegt Bart. "Dat geeft je de mogelijkheid om gradueel de migratie te doen, terwijl eindgebruikers bij één systeem blijven werken."
‍

Dit artikel beschrijft de technische implementatie van het pattern, inclusief architectuurpatronen en praktische strategieën.
‍

Wanneer het pattern toepassen

Het strangler pattern is niet voor elk scenario geschikt. De beste resultaten bereik je wanneer:

"Voor kleine applicaties kun je vaak beter een volledige rewrite doen," legt Bart uit. "Maar voor grote tot heel grote systemen is het strangler pattern de enige realistische optie."
‍

De technische architectuur

Het pattern vereist een specifieke architectuuropzet die zowel het oude als het nieuwe systeem ondersteunt.

Component 1: De facade layer

De facade is het hart van het pattern. Alle requests gaan door deze laag, die bepaalt of trafiek/requests naar het oude of nieuwe systeem wordt gerouteerd.

[Client] → [Facade/Router] → [Legacy System] → [New System]

Voor .NET omgevingen is een combinatie van YARP (Yet Another Reverse Proxy) met custom routing logic een bewezen aanpak.
‍

Component 2: De anti-corruption layer

Wanneer nieuw en oud systeem moeten communiceren, voorkom je dat legacy-concepten de nieuwe codebase "besmetten" met een anti-corruption layer (ACL).

De ACL vertaalt tussen de twee werelden:

"De anti-corruption layer is tijdelijk, maar cruciaal," benadrukt Bart. "Zonder die laag importeer je alle problemen van het oude systeem in je nieuwe code. Je technische trucendoos moet ook opgekuist worden zodra de functionaliteit is overgezet."
‍

Component 3: Event-based synchronisatie

Gedurende de migratie moeten beide systemen vaak dezelfde data hebben. Event-driven synchronisatie houdt ze in sync zonder tight coupling.

Pattern: Change Data Capture (CDC)

[Legacy DB] → [CDC Tool] → [Event Bus] → [New System DB]

‍

Tools zoals Debezium (voor PostgreSQL/MySQL) of SQL Server Change Tracking maken dit mogelijk zonder aanpassingen aan de legacy code.
‍

Het migratieproces: 4 fasen per component

Elke component doorloopt dezelfde vier fasen:

Fase 1: Wrap

Plaats een facade rond de legacy component. Alle aanroepen gaan voortaan via deze facade, ook al routeert die nog 100% naar legacy.

Doel: Controlepunt creëren zonder functionaliteit te wijzigen.

Verificatie: Alle bestaande tests blijven slagen. Geen gedragswijziging.
‍

Fase 2: Build

Bouw de nieuwe implementatie achter dezelfde interface. De facade kent beide implementaties, maar routeert nog steeds naar legacy.

Doel: Nieuwe code volledig klaar, getest in isolatie.

Verificatie: Unit tests en integration tests voor nieuwe implementatie. Contract tests om interface-compatibiliteit te garanderen.
‍

Fase 3: Route

Routeer traffic geleidelijk naar de nieuwe implementatie:

• Eerst 10% naar nieuw, 90% naar legacy
• Dan 50/50
• Dan 90% naar nieuw, 10% naar legacy
• Uiteindelijk 100% naar nieuw

Doel: Productievalidatie met mogelijkheid tot instant rollback.

Verificatie: Monitoring op errors, latency, en business metrics. Rollback-procedure getest en gedocumenteerd.
‍

Fase 4: Remove

Verwijder de legacy code en de routing logic. De facade wordt vereenvoudigd of verwijderd.

Doel: Technische schuld elimineren.

Verificatie: Legacy code volledig verwijderd uit repository. Geen dode imports of configuraties.
‍

Monitoring en rollback

Succesvolle strangler implementations vereisen robuuste monitoring. Meet minimaal:

Quick win deze week: Implementeer feature flags voor je eerste component. Tools zoals LaunchDarkly, Unleash, of een simpele config-based toggle geven je instant rollback-capaciteit.
‍

Rollback strategie

Definieer vooraf wanneer je terugschakelt:

• Error rate >2× baseline gedurende 5 minuten
• P95 latency >2× baseline gedurende 10 minuten
• Kritieke business flow failure

Automatiseer de rollback waar mogelijk. Eén command om terug te schakelen naar legacy.
‍

Veelgemaakte fouten

‍

Praktische takeaways

1. Start met een non-critical component. Kies een component met beperkte dependencies voor je eerste strangler. Leer het proces voordat je kritieke functionaliteit migreert.
   
   
2. Implementeer feature flags eerst. Voordat je begint met builden, zorg dat je routing-mechanisme en rollback werken. Test dit met de bestaande legacy code.
   
   
3. Meet de baseline vóór migratie. Documenteer de huidige performance (latency, error rate, throughput) van elke component. Dit is je vergelijkingspunt.
   
   
4. Bouw de ACL vanaf dag één. Ook als legacy en nieuw "bijna hetzelfde" lijken, bouw een anti-corruption layer. De verschillen worden altijd groter dan verwacht.
   
   
5. Plan voor tijdelijke complexiteit. Gedurende migratie draait zowel legacy als nieuw. Budget hier capaciteit voor in je team en infrastructuur.
   ‍
   
   

Conclusie

Het strangler pattern is geen quick fix. Het vereist discipline, goede tooling, en acceptatie van tijdelijke complexiteit. Maar voor grote legacy-systemen is het de veiligste weg naar modernisatie. De kern is risicoreductie: elke stap is omkeerbaar, elke component wordt individueel gevalideerd, en het productiesysteem blijft altijd operationeel.
‍

"Je hebt altijd een werkend systeem," vat Bart samen. "Ook als er iets misgaat. Dat is het verschil tussen een gecontroleerde transitie en een gok."

Klaar om je legacy-systemen stap voor stap te moderniseren? Crafted by Elmos.

Bart Demeulenaere is Competence Manager bij Elmos met expertise in software architectuur en modernisatietrajecten.

‍