Case Study: ERP-Modernisatie bij een Productiebedrijf — Van Monoliet naar Microservices

Legacy-systemen zijn een tweesnijdend zwaard. Ze draaien de core van je bedrijf en bevatten jarenlang opgebouwde bedrijfslogica, maar ze worden steeds moeilijker te onderhouden, te vernieuwen en te integreren met moderne technologie. In deze case study beschrijven we hoe een productiebedrijf in Brabant zijn 15 jaar oude monolithische ERP-systeem stap voor stap moderniseerde — zonder de operatie stil te leggen.

De Klant#

Het betreft een middelgroot productiebedrijf in Noord-Brabant, actief in de maakindustrie. Met circa 200 medewerkers produceren ze op maat gemaakte metaalproducten voor de bouw-, infra- en energiesector. Het bedrijf verwerkt jaarlijks meer dan 3.000 productieorders en levert aan klanten in heel Europa.

De kern van hun bedrijfsvoering draaide op een ERP-systeem dat 15 jaar eerder op maat was gebouwd. In de beginjaren was het systeem een voorsprong — perfect afgestemd op de specifieke bedrijfsprocessen. Maar na anderhalf decennium van uitbreidingen, aanpassingen en workarounds was het uitgegroeid tot een monoliet die het bedrijf meer remde dan ondersteunde.

De Uitdaging#

Een Monoliet die Onder Zijn Eigen Gewicht Bezweek

Het ERP-systeem was in de loop der jaren uitgegroeid tot een applicatie van meer dan 800.000 regels code. Alle functionaliteit — van offertes en productieplanning tot voorraadbeheer, facturatie en rapportage — zat verweven in één grote codebase. Wijzigingen in het ene onderdeel hadden regelmatig onverwachte effecten op andere onderdelen.

Concrete Pijnpunten

Trage releases en hoog risico Een nieuwe feature of bugfix implementeren duurde gemiddeld 6 tot 8 weken, inclusief uitgebreide regressietests. Zelfs kleine aanpassingen vereisten een volledige release van het hele systeem, omdat componenten zo sterk verweven waren. Releases vonden daardoor slechts eens per kwartaal plaats, altijd in het weekend, en gingen gepaard met spanning en risico.

Hoge onderhoudskosten Het onderhoud van het systeem kostte jaarlijks meer dan EUR 180.000 aan externe development-uren. Een groot deel daarvan ging niet naar nieuwe functionaliteit maar naar het oplossen van regressiebugs en het bijwerken van verouderde dependencies.

Beperkte schaalbaarheid Het systeem draaide op een enkele server. Bij piekbelasting — zoals het einde van het kwartaal wanneer veel facturen gegenereerd werden — werden doorlooptijden merkbaar langer. Horizontaal schalen was door de monolithische architectuur niet mogelijk.

Kennis concentratie Slechts twee externe ontwikkelaars hadden diepgaande kennis van het volledige systeem. Dit creëerde een risicovol single point of failure voor het bedrijf.

Integratieproblemen Nieuwe tools en systemen — zoals een modern CRM, een webportaal voor klanten of IoT-sensoren op de productievloer — konden niet of nauwelijks aangesloten worden op het legacy ERP.

De CTO formuleerde het dilemma helder: "We konden niet vooruit met het oude systeem, maar we konden ook niet stoppen — het draaide letterlijk onze hele productie."

De Aanpak: Het Strangler Fig Pattern#

Waarom Geen Big Bang?

De eerste reflex bij legacy-modernisatie is vaak een volledige herbouw: begin op een leeg vel en bouw het systeem opnieuw. Dit klinkt aantrekkelijk maar is in de praktijk extreem risicovol. Big bang-migraties duren doorgaans langer dan gepland, kosten meer dan begroot, en de kans op mislukking is hoog.

Wij kozen voor het strangler fig pattern — een bewezen strategie waarbij je het oude systeem geleidelijk vervangt door nieuwe services, net zoals een wurgvijg langzaam een boom overgroeit. Het oude systeem blijft draaien terwijl functionaliteit stukje bij beetje verhuist naar moderne, onafhankelijke services.

Fasering

De modernisatie verliep in vier fasen over een periode van 14 maanden:

De Technische Oplossing#

Architectuurontwerp

De nieuwe architectuur bestond uit de volgende bouwstenen:

Gecontaineriseerde microservices Elke bedrijfsfunctie werd een zelfstandige service in een eigen container. Services konden onafhankelijk van elkaar worden ontwikkeld, getest, gedeployed en geschaald.

API Gateway Een centrale API gateway routeerde alle verzoeken naar de juiste service — of dat nu een nieuwe microservice was of een endpoint in het legacy-systeem. Dit maakte het mogelijk om per functionaliteit over te schakelen zonder dat de gebruiker iets merkte.

Event-driven communicatie Services communiceerden via een event bus. Wanneer er iets relevants gebeurde — een nieuwe order, een statuswijziging, een voorraadmutatie — publiceerde de verantwoordelijke service een event. Andere services die deze informatie nodig hadden, abonneerden zich op het relevante event.

Gedeelde database-strategie In de eerste fase deelden oude en nieuwe componenten nog dezelfde database. Naarmate services volwassener werden, kregen ze hun eigen database (database-per-service pattern), wat de ontkoppeling completeerde.

Fase 1: Foundation (Maand 1-2)

Voordat we de eerste bedrijfsfunctionaliteit migreerden, legden we het fundament:

• Container orchestratie platform ingericht voor het hosten van microservices
• API gateway geconfigureerd als facade voor zowel legacy- als nieuwe endpoints
• CI/CD pipeline gebouwd voor geautomatiseerde builds, tests en deployments
• Monitoring en logging ingericht met gecentraliseerde log-aggregatie en dashboards
• Event bus opgezet voor asynchrone communicatie tussen services

Fase 2: Eerste Services (Maand 3-6)

We begonnen bewust met functionaliteit die relatief los stond van de kern:

Offertemodule Het offerte-proces was een duidelijk afgebakende functie met beperkte afhankelijkheden. De nieuwe service bood meteen meerwaarde: een modern UI, betere samenwerking tussen sales en engineering, en automatische kostenberekening op basis van materiaalspecificaties.

Klantbeheer (CRM-integratie) Klantgegevens werden uit de monoliet gehaald en in een nieuwe service geplaatst die ook als brug fungeerde naar het inmiddels aangeschafte CRM-systeem.

De API gateway zorgde ervoor dat de rest van het systeem niets merkte van de migratie — verzoeken voor offerte- en klantdata werden automatisch doorgestuurd naar de nieuwe services.

Fase 3: Kernprocessen (Maand 7-10)

Nu het patroon bewezen was, pakten we de complexere onderdelen aan:

Productieplanning Dit was de meest uitdagende migratie. De planningslogica was diep verweven met vrijwel alle andere modules. We kozen voor een stapsgewijze aanpak:

1. Eerst de planningsdata spiegelen naar de nieuwe service (read-only)
2. Dan de planningslogica parallal draaien en resultaten vergelijken
3. Tot slot de nieuwe service als primair systeem activeren

Voorraadbeheer Het voorraadbeheer werd een eigen service met real-time koppeling aan de productievloer. Dit maakte het ook mogelijk om IoT-sensoren aan te sluiten voor automatische voorraadregistratie — iets dat met het legacy-systeem niet haalbaar was.

Fase 4: Afronding (Maand 11-14)

Facturatie De facturatiemodule werd gemigreerd met extra aandacht voor de koppeling met de boekhoudsoftware en belastingregels.

Rapportage Een nieuwe rapportageservice met een modern dashboard verving de oude, statische rapporten. Managers kregen voor het eerst real-time inzicht in productieperformance, doorlooptijden en kostenanalyses.

Legacy-ontmanteling Na verificatie dat alle functionaliteit correct werkte in de nieuwe services, werden de legacy-modules stuk voor stuk uitgeschakeld. De API gateway maakte dit proces pijnloos: er werd simpelweg geen verkeer meer naar de legacy-endpoints gerouteerd.

De Resultaten#

Na volledige afronding van het modernisatietraject waren de verbeteringen meetbaar op alle vlakken:

Financieel Overzicht

De totale investering in het modernisatietraject bedroeg circa EUR 320.000 over 14 maanden. Met een jaarlijkse besparing van EUR 72.000 op onderhoudskosten alleen al, is de terugverdientijd minder dan 4,5 jaar. Maar de werkelijke waarde zit in de mogelijkheden die het nieuwe platform biedt:

• Snellere time-to-market voor nieuwe functies die klanten vragen
• Schaalbaarheid om groei op te vangen zonder systeemlimieten
• Integratiemogelijkheden met moderne tools, IoT en AI
• Verminderd bedrijfsrisico door eliminatie van de single points of failure

Impact op de Organisatie

De modernisatie had ook een cultureel effect. Het development team — inmiddels uitgebreid van 2 naar 5 ontwikkelaars — werkt nu met moderne practices: code reviews, geautomatiseerde tests, feature flags en canary deployments. Dit trekt ook beter talent aan.

Op de werkvloer merkten productiemedewerkers dat het systeem sneller en betrouwbaarder reageerde. De productieplanners kregen betere tools en real-time data, wat leidde tot scherpere planning en minder verspilling.

Geleerde Lessen#

1. Begin met de Randen, Niet met de Kern

Door te starten met relatief onafhankelijke modules (offertes, klantbeheer) bouwden we ervaring op met het migratiepatroon voordat we de complexe kernprocessen aanpakten. Fouten in de eerste fase hadden beperkte impact en leverden waardevolle inzichten op.

2. Het Strangler Fig Pattern Werkt, Maar Vereist Discipline

De verleiding is groot om "even snel" een stukje legacy aan te passen in plaats van het netjes naar een nieuwe service te migreren. Dit ondermijnt het hele modernisatietraject. Wij hanteerden een strenge regel: alle nieuwe functionaliteit wordt als microservice gebouwd, nooit in de monoliet.

3. Investeer in de API Gateway

De API gateway was het belangrijkste component van de hele migratie. Het maakte het mogelijk om per functionaliteit over te schakelen, traffic geleidelijk te verplaatsen, en terug te rollen als er problemen waren. Zonder deze laag was een geleidelijke migratie niet haalbaar geweest.

4. Data-migratie is het Moeilijkste Onderdeel

De code migreren was uitdagend maar voorspelbaar. De data-migratie — met 15 jaar aan historische gegevens, inconsistenties en impliciete relaties — was het meest complexe onderdeel. Reserveer hier ruim tijd voor en onderschat het niet.

5. Communicatie is Cruciaal

Een modernisatietraject van 14 maanden raakt veel mensen in de organisatie. Regelmatige updates, demo's van nieuwe functionaliteit en het vieren van mijlpalen hielden het draagvlak hoog. De eindgebruikers werden onze grootste ambassadeurs doordat ze al vroeg in het traject verbeteringen ervoeren.

Conclusie#

De modernisatie van een 15 jaar oud monolithisch ERP-systeem klinkt als een overweldigend project — en dat is het ook. Maar met de juiste aanpak, een bewezen migratiestrategie en gefaseerde uitvoering is het haalbaar zonder je operatie stil te leggen.

Dit productiebedrijf beschikt nu over een modern, schaalbaar en onderhoudbaar platform dat klaar is voor de toekomst. Nieuwe functionaliteit kan in weken in plaats van maanden worden opgeleverd, het systeem schaalt mee met de groei, en moderne technologieën zoals IoT en AI zijn nu aansluitbaar.

Worstel jij ook met een verouderd systeem dat je bedrijf remt? Bekijk onze aanpak voor legacy-modernisatie of lees meer over onze ervaring in de maakindustrie.

"Je hoeft niet alles in één keer te vervangen. Door slim te faseren kun je moderniseren terwijl je bedrijf gewoon doorloopt." — Clever AI Software