Vrijwel elke organisatie loopt vroeg of laat tegen hetzelfde aan: een systeem dat ooit goed gebouwd is, jarenlang waardevol heeft gewerkt, maar nu een rem is op snelheid, aanwervingsmogelijkheden of strategische opties. De verleiding om dan helemaal opnieuw te beginnen is groot — en in de meeste gevallen onverstandig.
Mijn werk in legacy modernisatie draait om iets anders: het bestaande systeem niet als probleem zien, maar als startpunt. Welke delen zijn nog gezond? Welke delen kunnen we incrementeel vervangen? Waar liggen de echte bottlenecks, en waar voelt iets oud terwijl het in werkelijkheid prima functioneert?
Concreet heb ik op het nalatenschap-portaal AngularJS-applicaties productief naast Angular 16 laten draaien via een micro-frontend aanpak, en tegelijk de complete back-end vervangen door Kotlin op Vert.x met Keycloak en MariaDB — gefaseerd, met dubbele schrijfacties en schaduwlezingen, zonder dat het portaal ook maar één moment offline ging. Op het cultureel-educatieportaal heb ik een Silverstripe-systeem overgenomen en strategisch uitgebreid in plaats van te vervangen. Op de 3D-configurator heb ik grote delen van een gegroeide codebase gerefactord zonder de doorontwikkeling stil te zetten.
Innovatie hoort wat mij betreft expliciet bij dit verhaal. Een gezonde modernisering is niet alleen een vertaling van oud naar nieuw, maar ook een moment om bewust nieuwe mogelijkheden binnen te halen waar dat echte waarde geeft: BLE-koppelingen voor de trombosezorg, WebRTC voor het docentenplatform, een low-code stappen-engine voor het COVID-portaal, een real-time event-driven backend voor de horlogemaker. Telkens een keuze gemaakt op grond van wat het probleem vraagt, niet op grond van wat nieuw is.
De aanpak die ik in dit type werk hanteer is consistent: blijven leveren tijdens de verbouwing, kleine stappen met goede tests als vangnet, en heel duidelijke afspraken over wat in deze sprint wel en niet wijzigt. Een refactor of migratie is geen vrije pas om alles tegelijk anders te doen — juist die discipline maakt dat het traject ook echt eindigt.
Misschien wel de belangrijkste les uit dit type werk is dat techniek vaak niet de moeilijkste factor is. Het tegenkomen van impliciete kennis die alleen in de hoofden van een paar mensen zit, het managen van de zenuwen van een organisatie die afhankelijk is van het oude systeem, en het uitleggen waarom "alles vervangen" zelden de juiste keuze is — dáár ligt vaak het echte werk.