Veel Nederlandse bedrijven draaien op software die vijf, tien of zelfs twintig jaar oud is. Het systeem werkt, maar het knelt: nieuwe functies toevoegen duurt maanden, integraties met moderne tools zijn lastig, en de ontwikkelaar die het oorspronkelijk bouwde is allang vertrokken. De verleiding is groot om alles in een keer te vervangen. Dat is bijna altijd een slecht idee.
Het probleem met big-bang vervanging
Een volledige vervanging van een legacy systeem — ook wel big-bang migratie genoemd — is een van de riskantste projecten in de IT. De cijfers spreken voor zich:
| Aspect | Big-bang vervanging | Strangler fig aanpak |
|---|---|---|
| Doorlooptijd | 12 - 36 maanden | Eerste resultaat in 4 - 8 weken |
| Risico op mislukking | Hoog (60-70% overschrijdt budget/planning) | Laag (per onderdeel beheersbaar) |
| Bedrijfscontinuiteit | Onderbroken tijdens migratie | Ononderbroken |
| Investering vooraf | Groot (volledige vervanging) | Gefaseerd (per onderdeel) |
| Terugdraaien mogelijk | Nauwelijks | Per onderdeel mogelijk |
| Waardecreatie | Pas na oplevering | Vanaf eerste fase |
Het fundamentele probleem: tijdens een big-bang project moet u het oude systeem draaiende houden en tegelijkertijd het nieuwe bouwen. Ondertussen veranderen de bedrijfseisen, en tegen de tijd dat het nieuwe systeem klaar is, sluit het niet meer aan bij de werkelijkheid.
Big-bang vervanging
- ❌12-36 maanden doorlooptijd
- ❌60-70% overschrijdt budget of planning
- ❌Bedrijfsvoering onderbroken tijdens migratie
- ❌Grote investering vooraf vereist
- ❌Terugdraaien nauwelijks mogelijk
- ❌Waarde pas na volledige oplevering
Strangler fig aanpak
- ✅Eerste resultaat in 4-8 weken
- ✅Per onderdeel beheersbaar risico
- ✅Bedrijfsvoering ononderbroken
- ✅Gefaseerde investering per onderdeel
- ✅Per onderdeel terugdraaibaar
- ✅Waardecreatie vanaf eerste fase
De strangler fig methode
De strangler fig is vernoemd naar de tropische vijgenboom die rond een gastheerboom groeit, geleidelijk alle functies overneemt, en uiteindelijk de oorspronkelijke boom vervangt — zonder dat het bos er ooit kaal bij staat.
Vertaald naar software: u bouwt nieuwe functionaliteit naast het oude systeem, leidt gebruikers geleidelijk om naar de nieuwe componenten, en schakelt de oude onderdelen pas uit wanneer de nieuwe volledig functioneren.
De drie fasen
Fase 1: Wrap (omhullen)
Plaats een laag rondom het legacy systeem die als tussenpersoon fungeert. Dit kan een API-gateway zijn, een reverse proxy, of een facade-service. Alle verzoeken gaan voortaan via deze laag.
Het voordeel: u verandert niets aan het bestaande systeem. Het draait ongewijzigd verder. Maar u heeft nu een controlepunt waar u verkeer kunt routeren.
Fase 2: Replace (vervangen)
Kies een afgebakend onderdeel van het systeem en bouw dit opnieuw met moderne technologie. Leid het verkeer voor dat onderdeel om naar de nieuwe component via de tussenlaag. Het oude onderdeel draait nog steeds, maar wordt niet meer gebruikt.
Begin met het onderdeel dat:
- De meeste problemen veroorzaakt (meeste bugs, klachten, of handmatig werk)
- Relatief onafhankelijk is (weinig koppelingen met andere onderdelen)
- De hoogste bedrijfswaarde heeft (directe impact op omzet of efficiency)
Fase 3: Retire (uitfaseren)
Zodra de nieuwe component stabiel draait en alle gebruikers zijn overgezet, schakelt u het oude onderdeel uit. Houd het nog een periode in standby voor het geval er onvoorziene problemen optreden. Na een succesvolle overgangsperiode verwijdert u het definitief.
Herhaal fase 2 en 3 voor elk onderdeel totdat het hele legacy systeem is vervangen.
Een praktijkvoorbeeld
Stel: u heeft een monolithisch ERP-systeem dat orderbeheer, voorraadbeheer, facturatie en rapportages afhandelt. Het systeem is gebouwd in een verouderde technologiestack, er is geen API, en aanpassingen kosten weken.
API-gateway plaatsen
Alle verzoeken gaan via een tussenlaag. Functioneel verandert er niets — u krijgt een controlepunt.
Rapportages moderniseren
Read-only modules zijn het eenvoudigst. Modern dashboard met directe meerwaarde voor gebruikers.
Facturatie vernieuwen
De module met de meeste handmatige correcties. Automatische creditfacturen en herinneringen.
Orderbeheer & voorraadbeheer
De complexe kern, maar met bewezen aanpak en werkende API-gateway inmiddels op zijn plek.
Legacy uitfaseren
Na 12-18 maanden: het oude systeem uitschakelen. Back-up bewaren, nieuwe services nemen volledig over.
Stap 1: API-gateway plaatsen
U implementeert een API-gateway die alle verzoeken naar het ERP opvangt. Initieel routeert de gateway alles 1-op-1 door naar het bestaande systeem. Er verandert functioneel niets.
Stap 2: Rapportages moderniseren
Rapportages zijn vaak het eenvoudigst los te koppelen: ze lezen alleen data en schrijven niet terug. U bouwt een moderne rapportagemodule die data uit het legacy systeem haalt (via de API-gateway of directe databasetoegang) en presenteert in een modern dashboard.
Gebruikers zien direct resultaat: snellere rapportages, betere visualisaties, en de mogelijkheid om zelf analyses te maken. Dit creëert draagvlak voor de volgende stappen.
Stap 3: Facturatie vernieuwen
De facturatiemodule veroorzaakt de meeste handmatige correcties. U bouwt een nieuwe facturatieservice die integreert met uw boekhoudsoftware en automatisch creditfacturen en herinneringen verstuurt. Via de API-gateway routeert u facturatieverzoeken naar de nieuwe service.
Stap 4: Orderbeheer en voorraadbeheer
Met de ervaring van de eerste twee migraties pakt u de kern aan: orderbeheer en voorraadbeheer. Dit zijn de meest complexe onderdelen, maar u heeft inmiddels een bewezen aanpak en een werkende API-gateway.
Stap 5: Legacy uitfaseren
Na 12-18 maanden draait het oorspronkelijke ERP-systeem nog, maar wordt niet meer actief gebruikt. U schakelt het uit, bewaart een back-up, en het nieuwe systeem — bestaande uit meerdere onafhankelijke services — neemt het volledig over.
Technische patronen voor de strangler fig
API-gateway als routeerder
De API-gateway is het hart van de strangler fig aanpak. Deze routeert verzoeken op basis van regels:
/api/rapportages/*→ Nieuwe rapportageservice/api/facturen/*→ Nieuwe facturatieservice/api/*→ Legacy systeem (alles wat nog niet is gemigreerd)
Database-synchronisatie
Tijdens de migratie moeten oude en nieuwe componenten vaak dezelfde data gebruiken. Opties:
| Strategie | Voordeel | Nadeel |
|---|---|---|
| Gedeelde database | Eenvoudig, directe toegang | Koppeling tussen oud en nieuw |
| Change Data Capture (CDC) | Realtime synchronisatie | Complexere opzet |
| Event-driven synchronisatie | Losse koppeling | Eventual consistency |
| Batch synchronisatie | Eenvoudig te implementeren | Vertraging in data |
Voor de meeste situaties adviseer ik Change Data Capture: het synchroniseert data in realtime zonder dat het legacy systeem hoeft te worden aangepast.
Feature flags
Gebruik feature flags om de overgang te beheren. U kunt per gebruiker, afdeling of percentage bepalen wie de nieuwe component gebruikt en wie nog op het legacy systeem werkt. Dit maakt gecontroleerde uitrol mogelijk en verkleint het risico.
Veelgemaakte fouten
Te veel tegelijk willen vervangen
De kracht van de strangler fig is geleidelijkheid. Vervang een onderdeel tegelijk, niet drie. Elk onderdeel dat u vervangt, leert u iets over het legacy systeem dat u niet wist.
De tussenlaag overslaan
Het is verleidelijk om direct te beginnen met het herbouwen van functionaliteit. Maar zonder API-gateway of facade heeft u geen controlepunt om verkeer te routeren. Dit maakt de overgang abrupt in plaats van geleidelijk.
Geen meetbare criteria voor succes
Definieer voor elk onderdeel wanneer de migratie geslaagd is. Bijvoorbeeld: "De nieuwe facturatieservice verwerkt 99,9% van de facturen zonder handmatige correctie gedurende vier weken." Zonder dergelijke criteria weet u niet wanneer u het oude onderdeel kunt uitschakelen.
De tussenlaag is niet optioneel
Zonder API-gateway of facade heeft u geen controlepunt om verkeer te routeren. Dit maakt de overgang abrupt in plaats van geleidelijk — en dat is precies het risico dat u wilt vermijden.
Het legacy team niet betrekken
De mensen die het oude systeem kennen, zijn onmisbaar. Zij weten waar de verborgen bedrijfslogica zit, welke uitzonderingen er zijn, en waarom bepaalde keuzes zijn gemaakt. Betrek hen actief bij het migratieproject.
Wanneer de strangler fig niet past
De strangler fig aanpak werkt het best bij systemen die modulair te ontleden zijn. Bij zeer kleine systemen (waar een volledige vervanging in enkele weken kan) of bij systemen zonder enige API of databasetoegang kan een andere aanpak effectiever zijn. Maar voor de meeste legacy systemen in het MKB is het de veiligste en meest kosteneffectieve methode.
Klaar om uw legacy systeem aan te pakken?
Een legacy systeem moderniseren hoeft niet alles-of-niets te zijn. Met de strangler fig aanpak boekt u snel resultaat, beperkt u risico, en houdt u uw bedrijfsvoering ononderbroken.
Wilt u weten hoe deze aanpak er voor uw situatie uitziet? Ik maak graag een migratieplan op maat.
Plan een vrijblijvend gesprek en ontdek hoe u uw legacy systeem stap voor stap kunt moderniseren.