Laatst zei iemand tegen mij: “If it ain’t broken, don’t fix it.”
Dat klinkt als een simpele, misschien wel wat ouderwetse uitspraak. Alsof je vooral niets moet veranderen zolang het systeem nog draait.
Maar in legacy-omgevingen hoor ik daar iets anders in. Niet: blijf er vanaf omdat oud goed genoeg is. Maar: wees voorzichtig, want niemand weet hier meer precies waarom het werkt.
En dat is een heel ander probleem.
Want als niemand meer weet hoe een systeem echt in elkaar zit, dan is vervangen geen gewone technische migratie meer. Dan trek je aan een draadje waarvan je niet weet waar het naartoe loopt. Voor je het weet gaat de doos van Pandora open.
Een oude koppeling blijkt toch nog nodig. Een veld dat niemand gebruikt, voedt een rapportage. Een nachtelijk script corrigeert data waar drie afdelingen op vertrouwen. Een rare vertraging voorkomt dat een machine in storing valt. Een uitzondering in de code blijkt een oude klantafspraak. Een handmatige Excel-lijst blijkt onderdeel van het echte proces.
En dan ontdek je dat het oude systeem niet alleen software of hardware was. Het was geheugen. Niet netjes gedocumenteerd, niet elegant ontworpen, niet altijd veilig of toekomstbestendig — maar wel gevuld met jaren aan proceskennis.
Daarom vind ik “If it ain’t broken, don’t fix it” eigenlijk net niet scherp genoeg. Ik zou hem liever zo formuleren:
If it ain’t broken, first understand why it still works.
Hoe legacy groeit
In veel organisaties wordt legacy vooral gezien als ballast. Oude programmeertalen, oude databases, oude servers, oude PLC’s, oude SCADA-omgevingen, oude koppelingen, oude schermen waar niemand nog blij van wordt.
En soms is dat terecht. Oude systemen kunnen kwetsbaar zijn. Ze kunnen draaien op hardware die niet meer leverbaar is, afhankelijk zijn van software waarvoor geen patches meer komen, en slecht aansluiten op moderne security-eisen, monitoring of integratiebehoeften.
Maar dat is maar één kant van het verhaal. De andere kant is dat zo’n oud systeem vaak jarenlang heeft meebewogen met de werkelijkheid. Niet met de werkelijkheid zoals die ooit in een procesplaat stond, maar met de werkelijkheid zoals die echt was. Er kwam een uitzondering bij. Daarna nog één. Een tijdelijke workaround werd permanent. Een script dat even snel nodig was, werd bedrijfskritisch. Een koppeling die niemand mooi vond, bleef bestaan omdat drie processen ervan afhankelijk werden.
Ik heb dat zelf van dichtbij gezien. Jaren geleden werkte ik aan een besturingssysteem bij een energiecentrale — de-icing van de luchtinlaat. Op papier was het een overzichtelijke installatie met een duidelijke functie. In de praktijk zat er een hele laag logica omheen die nergens gedocumenteerd was: uitzonderingen voor bepaalde weersomstandigheden, handmatige overrides die operators in de loop der jaren hadden toegevoegd, timingafhankelijkheden die stilzwijgend voorkwamen dat de installatie zichzelf in de problemen draaide. Niets daarvan stond in een ontwerpdocument. Het zat in het systeem, en in de hoofden van de mensen die ermee werkten.
Zo groeit legacy. Niet omdat mensen dom zijn of niemand heeft opgelet, maar omdat organisaties veranderen, processen schuiven, klanten andere dingen vragen, wetgeving verandert, machines ouder worden en mensen oplossingen zoeken om het werk gedaan te krijgen.
Oud is niet automatisch achterhaald
Er zit een misverstand onder veel legacy-discussies: dat oude techniek automatisch achterhaalde techniek is. Dat klopt niet altijd.
Veel fundamentele techniek is nog steeds hetzelfde. Een relationele database is nog steeds een relationele database. Een TCP/IP-netwerk is nog steeds een TCP/IP-netwerk. Ook in industriële omgevingen zijn veel principes verrassend constant: meten, sturen, terugkoppelen, begrenzen, beveiligen, loggen.
De schil verandert — tooling, interfaces, architecturale context. Denk aan event-driven architecturen, zero trust, cloud-native patterns. Maar de onderliggende logica is vaak minder veranderd dan men denkt.
Soms is het probleem niet dat de techniek fundamenteel verouderd is, maar dat de wereld om het systeem heen veranderd is. Het systeem moest ooit één taak uitvoeren in een afgebakende context. Nu moet hetzelfde systeem koppelen met moderne applicaties, data leveren aan dashboards, voldoen aan nieuwe security-eisen, beschikbaar zijn voor meerdere afdelingen en passen binnen governance die er destijds nog niet was.
Dan is het systeem niet per se kapot. Het is alleen in een wereld terechtgekomen waarvoor het nooit ontworpen is.
Het formele proces is niet altijd het echte proces
Een van de grootste risico’s bij modernisering is dat men begint bij het formele proces. Er wordt gekeken naar documentatie, naar procesplaten, naar architectuurschema’s, naar hoe het ooit bedoeld was.
Dat lijkt logisch. Maar in brownfield-omgevingen is dat vaak niet genoeg.
Het echte proces zit in gedrag. In uitzonderingen. In handmatige stappen. In oude scripts. In databasewaarden die ooit tijdelijk waren. In operatorhandelingen die al zo lang bestaan dat niemand ze meer als workaround herkent. En vaak is het legacy-systeem de enige plek waar dat echte proces nog zichtbaar is — niet mooi, niet volledig, niet netjes beschreven, maar wel aanwezig.
Daarom kan een oud systeem technisch verouderd zijn en functioneel nog steeds volwassener dan het nieuwe ontwerp. Dat is ongemakkelijk, maar belangrijk. Want een modern systeem dat alleen het formele proces volgt, kan perfect gebouwd zijn en toch falen in de praktijk. Niet omdat de techniek slecht is, maar omdat het de werkelijke organisatie niet begrijpt.
Nieuwe techniek lost geen oude onwetendheid op.
Modernisering kan kennis vernietigen
Wanneer je een legacy-systeem vervangt zonder te begrijpen welke kennis erin zit, gooi je niet alleen oude techniek weg. Je gooit ook organisatiegeheugen weg.
Dat gebeurt zelden in één grote klap. Het gaat subtiel. Na livegang blijkt dat bepaalde uitzonderingen niet meer werken. Rapportages kloppen net niet. Machines reageren anders. Operators gaan extra controles doen. Gebruikers houden Excel-lijsten bij. Afdelingen bouwen schaduwprocessen. Beheer krijgt meldingen die niemand had voorzien.
En na een paar maanden vraagt iedereen zich af waarom het nieuwe systeem zoveel gedoe oplevert. Niet omdat modernisering verkeerd was, maar omdat het oude systeem beter gelezen had moeten worden.
Hoe dan wel?
Niet door legacy blind te vervangen. Maar ook niet door alles te laten zoals het is. De kunst is om het systeem eerst leesbaar te maken, daarna beheersbaar, en pas daarna vervangbaar.
Begin met observeren — en met praten. Kijk niet alleen naar documentatie, maar vooral naar gedrag. Wat komt erin? Wat gaat eruit? Welke uitzonderingen zijn er? Welke afdelingen, machines, rapportages of beslissingen vertrouwen op dit systeem? En minstens zo belangrijk: praat met de mensen die ermee werken. De operator die al vijftien jaar op die machine draait. De beheerder die dat nachtelijke script ooit geschreven heeft. De planner die elke maandag een Excel-export draait waarvan niemand wist dat die bestond. De echte proceskennis zit vaak niet in code of configuratie, maar in hoofden. En die kennis verdwijnt als je die mensen niet betrekt voordat je begint met vervangen.
Maak de verborgen proceskennis expliciet. Veel logica zit niet meer in documenten, maar in code, scripts, databasevelden, configuratiebestanden, operatorhandelingen, Excel-lijsten en oude koppelingen. Breng dat in kaart — niet om het te documenteren voor een la, maar om het mee te nemen in het nieuwe ontwerp.
Zet een veilige schil om het systeem. Voeg logging toe. Voeg monitoring toe. Controleer backups. Beperk toegang. Segmenteer het netwerk. Maak koppelingen expliciet. Bouw eventueel een API-laag, exportlaag of middleware-component. Niet om het oude systeem mooier te maken, maar om het beheersbaar te maken.
Vervang daarna stapsgewijs. Eerst één koppeling. Dan één processtap. Dan één module. Laat oud en nieuw waar mogelijk tijdelijk naast elkaar draaien. Vergelijk output, gedrag, fouten en uitzonderingen — niet alleen technisch, maar ook functioneel.
Een big bang-migratie lijkt soms efficiënt, maar in brownfield-omgevingen is dat vaak schijnzekerheid. Je ontdekt de echte complexiteit pas wanneer het nieuwe systeem de oude werkelijkheid moet dragen.
De regel is simpel: vervang geen onderdeel waarvan je de functie nog niet begrijpt. Of nog scherper: je mag pas iets uitzetten als je weet waarom het ooit aan stond.
Moderniseren begint met begrijpen
Legacy is zelden alleen een technisch probleem. Het is een combinatie van techniek, proces, historie en vergeten keuzes.
Wie alleen naar de ouderdom van een systeem kijkt, ziet vooral risico. Wie beter kijkt, ziet ook kennis. Dat betekent niet dat oude systemen moeten blijven zoals ze zijn — sommige systemen moeten echt vervangen worden, sommige koppelingen zijn gevaarlijk, sommige afhankelijkheden zijn onverantwoord, sommige technologie is niet meer veilig of beheerbaar.
Maar ook dan begint goede modernisering niet met slopen. Ze begint met begrijpen.
Wat doet dit systeem echt? Waarom werkt het zo? Welke kennis zit erin opgeslagen? Wat moet blijven, wat kan weg, wat moet opnieuw ontworpen worden?
Legacy ontstaat niet altijd doordat techniek veroudert. Soms ontstaat legacy doordat de wereld om het systeem heen verandert. En precies daarom is modernisering geen kwestie van oud vervangen door nieuw — het is het zorgvuldig overzetten van werkende kennis naar een vorm die weer past bij de huidige werkelijkheid.
“If it ain’t broken, don’t fix it.”
Maar vooral:
“If it ain’t broken, first understand why it still works.”