3.6 Modernisering van legacy

Overzicht en motivatie

Legacysystemen zijn de systemen die de wereld draaiende houden. De kerngrootboeken van banken, belasting- en uitkeringsengines, systemen voor luchtverkeer en defensie, polisadministratie van verzekeraars en overheidsregisters waarvan samenlevingen afhangen zijn vaak tientallen jaren oud. Veel zijn geschreven in COBOL (Common Business-Oriented Language) of andere oudere technologieën, en ze verwerken nog steeds het grootste deel van de kritieke transacties. “Legacy” is geen belediging. Het betekent dat het systeem waardevol genoeg is om te zijn blijven bestaan, kritiek genoeg dat falen catastrofaal is en oud genoeg dat veilig wijzigen moeilijk is. Legacymodernisering is de discipline van deze systemen verbeteren, migreren of vervangen zonder de essentiële diensten te breken die ze leveren.

Dit is onevenredig een probleem van onderneming en overheid, en het is waar de grootste, meest publieke IT-falen plaatsvinden. Een enorm deel van de grote transacties wereldwijd raakt nog mainframesystemen. Een groot deel van de productiecode in grote instellingen staat in oudere talen, onderhouden door een verouderende, krimpende groep specialisten. Overheden dragen de zwaarste last: wettelijke verplichtingen gecodeerd over decennia, aanbestedings- en begrotingscycli die regeringen overleven en burgerdiensten die niet onderbroken mogen worden. Het dominante risico is niet dat deze systemen oud zijn, want veel draaien uitstekend. Het is dat de kennis om ze te onderhouden met pensioen gaat, de platforms steeds duurder en beperkter worden en de verleiding om het “gewoon te herschrijven” leidt tot enkele van de duurste falen in de geschiedenis van het vak.

Dit hoofdstuk behandelt de incrementele moderniseringspatronen die werkelijk werken (wurgvijg en branch by abstraction), hoe je legacyrisico beoordeelt en prioriteert, het beheer van mainframe- en COBOL-landschappen, de discipline van datamigratie en dubbel draaien, en bovenal hoe je de verleiding van de grote herschrijving weerstaat. De centrale overtuiging is dat succesvolle modernisering bijna altijd incrementeel, op bewijs gebaseerd en continu waarde leverend is. Het is nooit een meerjarige big bang.

Kernprincipes

Legacy betekent waardevol en fundamenteel, niet slechts oud. Respecteer wat het systeem doet voordat je het aanraakt. Het codeert decennia aan zwaarbevochten bedrijfsregels.
Incrementeel verslaat big-bang, bijna altijd. Vervang stukje voor stukje achter een stabiele interface. Lever continu waarde en houd het risico klein.
De grote herschrijving is de standaardfaalwijze. Volledige herschrijvingen lopen routinematig uit, leveren te weinig op en worden geannuleerd. Behandel de aandrang met diepe argwaan.
Je kunt niet moderniseren wat je niet begrijpt. Reverse-engineer en documenteer gedrag (inclusief ongedocumenteerde regels) voordat je het vervangt.
Datamigratie is waar projecten sterven. De data is ouder, vuiler en verstrengelder dan iemand verwacht. Plan haar als eersteklas inspanning.
Draai oud en nieuw parallel om vertrouwen op te bouwen. Dubbel draaien en vergelijken vangt afwijkingen voor de overschakeling.
Prioriteer naar risico en waarde, niet naar leeftijd. Moderniseer eerst wat het riskantst en meest waardevol is, niet wat simpelweg het oudst is.
Houd het licht aan terwijl je de motor verandert. De service moet de hele tijd blijven draaien. Er is geen aanvaardbare downtime voor kritieke burger- of financiële systemen.

Aanbevelingen

Moderniseer incrementeel met het wurgvijgpatroon

De wurgvijg (vernoemd naar de liaan die rond een boom groeit en hem geleidelijk vervangt) is het werkpaard van veilige modernisering. Plaats een routeringslaag (een API-gateway, façade of proxy) voor het legacysysteem. Bouw dan, vermogen voor vermogen, de vervanging in een modern systeem en leid die plak verkeer ernaartoe, de rest op het legacysysteem latend. In de tijd groeit het nieuwe systeem en krimpt het oude, tot het kan worden uitgefaseerd. Dit levert continu waarde, houdt elke wijziging klein en omkeerbaar, vermijdt een riskante overschakeling en laat je op elk punt stoppen of herprioriteren. Het is het tegendeel van de big bang. Het legacysysteem blijft draaien en blijft zijn kostgeld verdienen terwijl je het eromheen vervangt.

Gebruik branch by abstraction voor interne naden

Waar je een component moet vervangen waarvan veel delen van het systeem afhangen, gebruik branch by abstraction. Introduceer een abstractielaag (een interface) over de bestaande implementatie, migreer aanroepers om van de abstractie af te hangen, bouw de nieuwe implementatie achter dezelfde abstractie, schakel over (vaak achter een functievlag, geleidelijk) en verwijder ten slotte de oude implementatie. Zo kan een groot component incrementeel worden vervangen op de hoofdlijn van ontwikkeling zonder een langlevende branch, het systeem de hele tijd releasebaar houdend. Het past vanzelf bij de wurgvijg: de façade handelt externe naden af, branch by abstraction interne.

Beoordeel en prioriteer legacyrisico bewust

Bouw voor het moderniseren een nuchtere inventaris en risicobeoordeling van het landschap. Scoor elk systeem op bedrijfskritiek, technisch risico (veroudering, niet-ondersteunde platforms, beveiligingsblootstelling), wijzigingsfrequentie en, cruciaal, kennisrisico (hoeveel mensen het nog kunnen onderhouden en hoe dicht ze bij pensioen zijn). Zet systemen uit op een raster van risico tegenover waarde. Geef prioriteit aan het moderniseren van wat zowel hoog risico als hoge waarde heeft. Overweeg stabiele, weinig veranderende, goed begrepen systemen met rust te laten ook al zijn ze oud, want een werkend systeem dat niemand hoeft te wijzigen is geen noodgeval. Deze beoordeling verandert “alles is oud en eng” in een verdedigbare, gesequentieerde roadmap.

Beheer het mainframe- en COBOL-landschap, vervang het niet alleen

Niet elk mainframe- of COBOL-systeem moet, of kan veilig, binnenkort worden vervangen. De prioriteit op korte termijn is vaak beheer (stewardship): leg de kennis vast voordat die met pensioen gaat. Documenteer de bedrijfsregels die de code codeert (veel ervan ongedocumenteerd en onvervangbaar), investeer in geautomatiseerde tests die het huidige gedrag vastpinnen zodat toekomstige verandering veilig is, werf en kruisopleid onderhouders en moderniseer de omringende leveringspraktijken (broncodebeheer, continuous integration (CI), geautomatiseerd testen) zelfs terwijl de kern op zijn plaats blijft. Waar je wel moderniseert, geef de voorkeur aan het blootleggen van legacyvermogens via moderne API’s (inkapseling) als eerste stap. Behandel geautomatiseerde vertaling van COBOL naar een moderne taal met voorzichtigheid, omdat ze code produceert die draait maar vaak onbegrijpelijke logica getrouw reproduceert. Het schaarsste middel is begrip, niet rekenkracht.

Behandel datamigratie en dubbel draaien als de kern van het project

Het moeilijkste en riskantste deel van de meeste moderniseringsinspanningen is de data. Ze is omvangrijk, van slechte en inconsistente kwaliteit en vol ongedocumenteerde betekenis die over decennia is aangegroeid. Profileer en reinig haar, koppel oude aan nieuwe schema’s expliciet en bouw herhaalbare, geautomatiseerde migratie met volledige reconciliatie (aantallen, checksums, bedrijfstotalen) zodat je kunt bewijzen dat niets verloren ging of werd gewijzigd. Beperk het risico van de overschakeling met dubbel draaien (parallel draaien): laat het oude en nieuwe systeem naast elkaar op dezelfde invoer werken en vergelijk uitvoer tot het nieuwe systeem het oude evenaart tot je vertrouwensdrempel. Pas dan schakel je over, en houd het vermogen om terug te draaien. Migreer en schakel voor werkelijk kritieke systemen in plakken over in plaats van alles tegelijk.

Beheers de verleiding van de grote herschrijving

Het instinct om het rommelige oude systeem weg te gooien en een schoon nieuw vanaf nul te bouwen is krachtig, en voor grote, kritieke systemen is het bijna altijd fout. Volledige herschrijvingen onderschatten de waarde die verborgen zit in de “lelijke” code (randgevallen, regelgevende regels, bug-compatibel gedrag waarvan echte gebruikers afhangen), duren veel langer dan geprojecteerd, leveren pas aan het eind waarde en worden na enorme uitgaven vaak geannuleerd. Kies standaard voor incrementele modernisering. Bewaar herschrijvingen voor gevallen waarin het platform werkelijk onhoudbaar is en incrementele paden uitgeput zijn. Ontleed zelfs dan de herschrijving in onafhankelijk opleverbare stukken via het wurgpatroon in plaats van een enkele big-bang-release. Wanneer het leiderschap aandringt op een totale herschrijving, sta dan op de vraag: welke waarde wordt opgeleverd in de eerste drie maanden, en wat gebeurt er als het programma halverwege wordt gestopt?

Afwegingen: voor- en nadelen

Aanpak	Voordelen	Nadelen
Wurgvijg (incrementeel)	Continue waarde, laag risico, omkeerbaar, houdt de service draaiend	Langere totale doorlooptijd, moet twee systemen parallel draaien, integratie-overhead
Big-bang-herschrijving	Schone lei, geen legacybeperkingen in de nieuwe code	Zeer hoog faalpercentage, geen waarde tot het eind, enorme kosten, bedrijfsregels verloren
Inkapselen (omhullen met API’s)	Snel, laag risico, moderniseert toegang zonder de kern aan te raken	Kern blijft legacy. Stelt het onderliggende risico uit, lost het niet op
Laten zoals het is (beheren)	Geen projectrisico. Goedkoopst op korte termijn	Kennis- en platformrisico blijven zich opstapelen. Uiteindelijk afgedwongen actie

De fundamentele afweging is snelheid van transformatie tegenover risico van falen, en legacymodernisering is het domein waar die ruil het meest scheef is. De “snelle, schone” big-bang-herschrijving is een luchtspiegeling die herhaaldelijk de traagste en duurste uitkomst van allemaal produceert: een geannuleerd programma en een nog steeds niet gemoderniseerd systeem. Incrementele aanpakken voelen langzamer en vereisen twee systemen parallel te draaien, maar ze leveren de hele tijd waarde, houden risico klein en omkeerbaar en zijn het empirisch betrouwbare pad. De echte oordeelskeuze is tussen een stabiel legacysysteem nog een tijd beheren en nu met incrementele vervanging beginnen. Laat de risicotrajectorie die keuze sturen, vooral kennisrisico, in plaats van ongemak met oude technologie.

Vragen om met je team te bespreken

Heb je een plek om een routeringslaag voor je legacysysteem te zetten, en zo niet, wat zou er nodig zijn om er een te creëren? De wurgvijg hangt af van een naad: een API-gateway, façade of proxy waardoor je één vermogen tegelijk naar een nieuwe implementatie kunt omleiden. Veel oude systemen hebben zo’n naad niet, dus de eerste moderniseringsstap is vaak simpelweg het bouwen van het onderscheppingspunt, en dat werk is makkelijk te onderschatten. Neem de huidige integratiekaart mee en vraag waar verkeer per vermogen kan worden onderschept zonder big-bang-overschakeling. Als er nergens is, kan branch by abstraction op een interne naad in plaats daarvan de beginzet zijn. Zonder routeringslaag heb je geen incrementeel pad, precies hoe organisaties worden teruggeduwd naar de herschrijving die meestal faalt.
Heb je je landschap werkelijk op een raster van risico tegenover waarde uitgezet, of wordt je roadmap gedreven door welk systeem het oudst aanvoelt? Het hoofdstuk staat erop dat je eerst moderniseert wat hoog risico en hoge waarde is, en stabiele, weinig veranderende, goed begrepen systemen bewust met rust laat ook als ze eeuwenoud zijn. Zonder expliciet raster stroomt aandacht naar de luidste klacht of de minst modieuze technologie, en echte tijdbommen (een kritiek systeem met twee onderhouders nabij pensioen) wachten. Scoor elk systeem op bedrijfskritiek, technisch risico, wijzigingsfrequentie en kennisrisico, en sequentieer dan vanuit de rechterbovenhoek. Neem dat raster mee naar de vergadering als gedeelde kaart. Kennisrisico verdient het zwaarste gewicht, omdat het de enige invoer is die alleen erger wordt en niet kan worden teruggekocht zodra de mensen weg zijn.
Hoe bewijs je bij de overschakeling dat geen enkel record verloren ging of werd gewijzigd, en wie keurt dat bewijs goed? Datamigratie is waar deze projecten sterven, en vertrouwen komt uit reconciliatie: rijaantallen, checksums en bedrijfscontroletotalen die tussen oud en nieuw overeenkomen, plus dubbel draaien dat uitvoer op dezelfde invoer vergelijkt tot ze tot een hoge drempel overeenkomen. Voor een uitkerings- of grootboeksysteem is een afwijking een burger die te weinig krijgt of een cent die verloren gaat, dus het bewijs moet een auditor bevredigen, niet alleen een engineer. Besluit nu welke totalen je zult reconciliëren, welke vertrouwensdrempel de overschakeling triggert en hoe lang je oud en nieuw parallel draait. Houd terugdraaien de hele tijd beschikbaar, en schakel in plakken over in plaats van alles tegelijk. De afwijkingen die je tijdens dubbel draaien vindt zijn meestal ongedocumenteerde legacyregels die je moet behouden, dus behandel elke als ontdekking, niet slechts als defect.
Welke van je legacysystemen beheer je tegenover actief vervangen, en wie besliste welke welke is? Het hoofdstuk trekt een bewuste lijn tussen systemen die de moeite waard zijn ter plekke te stabiliseren (regels documenteren, karakteriseringstests toevoegen, onderhouders kruisopleiden) en systemen die de moeite waard zijn incrementeel te vervangen, en de twee vragen zeer verschillende financiering en bezetting. Voor een grote organisatie is het gevaar afdrijving: een systeem gelabeld “voorlopig beheren” wordt stilletjes “voor altijd beheren” tot de laatste onderhouder met pensioen gaat en de keuze onder crisis voor je wordt gemaakt. De concurrerende overwegingen zijn beheerkosten en platformveroudering aan de ene kant tegenover het risico en de ontwrichting van vervanging aan de andere, en kennisrisico moet de balans doen doorslaan omdat het alleen erger wordt. Neem het raster van risico tegenover waarde mee, de formatie van onderhouders en pensioenhorizon voor elk systeem en een expliciete eigenaar voor de beslissing beheren-of-vervangen. Noem in landschappen van onderneming en overheid een reviewritme en een verantwoordelijke functionaris voor elk systeem, want een classificatie die niemand herziet is een beslissing die niemand neemt.
Wanneer het leiderschap om een volledige herschrijving vraagt, wat is je vaste antwoord, en kun je laten zien wat een incrementeel pad in de eerste drie maanden oplevert? De big-bang-herschrijving is de standaardfaalwijze, en toch blijft ze gefinancierd worden omdat een schone lei makkelijk te verkopen is en een wurgvijg niet. Een groot team heeft een geoefende reactie nodig zodat het argument op bewijs wordt gewonnen in plaats van door wie het senior is in de kamer. De echte spanning is dat sommige platforms werkelijk onhoudbaar zijn en een herschrijving gerechtvaardigd is, dus het antwoord kan geen algehele weigering zijn: het moet wegen of incrementele naden nog bestaan tegenover de ware kosten van het oude platform in leven houden. Neem de waarde mee die een eerste incrementele stap zou opleveren, het historische faalpercentage van vergelijkbare herschrijvingen en een ontleding van elke voorgestelde herschrijving in onafhankelijk opleverbare stukken. Sta in de overheid, waar een geannuleerd meerjarig programma publiek geld in het volle zicht verbrandt, erop dat elke herschrijving vroeg waarde levert en het overleeft halverwege te worden gestopt zonder totaal verlies.
Hoe leg je de bedrijfsregels vast die in je oudste code zijn opgesloten voordat de mensen die ze begrijpen weg zijn? Veel van de waarde in een legacysysteem is ongedocumenteerd gedrag dat decennia aan randgevallen, regelgeving en bug-compatibele fixes hebben opgebouwd, en het leeft in een krimpende groep specialisten die met pensioen gaan in plaats van in enig schriftelijk record. Voor een grote organisatie is dit het ene risico dat niet kan worden teruggekocht zodra de mensen weg zijn, dus het verdient financiering vóór het meer zichtbare platformwerk. De concurrerende trek is dat kennisvastlegging (documentatie, karakteriseringstests, reverse engineering, kruisopleiding) voelt als overhead die niets oplevert, precies waarom ze wordt uitgesteld. Neem een inventaris mee van wie kritieke kennis heeft, hoe dicht ze bij vertrek zijn en welke testdekking het huidige gedrag vandaag vastpint. Behandel in gereguleerde en publieke settings de wettelijke regels gecodeerd in oude code als compliance-bezit: ze stilletjes verliezen is geen technische schuld, het is juridische blootstelling.

Sectorperspectief

Startup. Je legacy is je eigen gehaaste MVP, geen mainframe: een prototype dat nu omzet draagt en dat iedereen vreest aan te raken. Herschrijf het niet. Omhul de engste module achter een schone interface, voeg karakteriseringstests toe om haar gedrag vast te pinnen en snijd functionaliteit incrementeel uit zodat elke kleine release waarde levert en het risico krimpt. Je hebt geen runway voor een herbouw vanaf nul, dus optionaliteit telt meer dan elegantie.

Kleinbedrijf. Je hebt geen moderniseringsteam en een krap budget, dus de praktische zet is meestal een werkend systeem werkend te houden: leg vast wat de ene persoon die het begrijpt weet, krijg het in broncodebeheer met een paar geautomatiseerde tests en leun op een leverancier of pakketproduct in plaats van een maatwerkherbouw. Formuleer de beslissing als kopen tegenover bouwen, en geef de voorkeur aan kopen wanneer het vermogen een commodity is. Besteed je beperkte inspanning aan het ene systeem waarvan het falen het bedrijf zou stilleggen, niet aan wat simpelweg het oudst oogt.

Grote onderneming. Het probleem is portfolioschaal: tientallen systemen, veel teams en kennisrisico over het hele landschap. Voer een gedeelde risicobeoordeling van risico tegenover waarde uit, standaardiseer op incrementele patronen (wurgvijg en branch by abstraction) en behandel datamigratie en dubbel draaien als eersteklas disciplines met reconciliatie die iedereen vertrouwt. Bestuur modernisering als continu portfolio tegen risicotrajectorie in plaats van een wirwar van heroïsche projecten, en begroot beheer en kennisvastlegging expliciet zodat geen kritiek systeem afhangt van één onderhouder die met pensioen gaat.

Overheid. Wettelijke verplichtingen gecodeerd over decennia, aanbestedingsregels en burgerdiensten die niet onderbroken mogen worden maken big-bang-vervanging bijzonder gevaarlijk. Geef de voorkeur aan incrementele wurgvijgmigratie met overschakeling plak voor plak, bewijs door reconciliatie en lang parallel draaien dat geen enkel burgerrecord verloren ging of verkeerd werd berekend en houd terugdraaien de hele tijd beschikbaar. Aanbesteding moet gegevensportabiliteit en openbaarmaking van bedrijfsregels eisen in plaats van ondoorzichtige vertaling, en elk meerjarig programma moet vroeg controleerbare waarde leveren en publieke toetsing overleven als het halverwege wordt gestopt.

Voorbeelden

Startup. De oorspronkelijke MVP van een drie jaar oude startup is zijn eigen soort legacy geworden: een gehaast prototype dat nu echte omzet afhandelt en dat iedereen bang is aan te raken. In plaats van een herschrijving omhult het team de slechtste module achter een schone interface, voegt karakteriseringstests toe om haar huidige gedrag vast te pinnen en verplaatst functionaliteit er over een paar maanden stukje voor stukje uit. Elke kleine release levert waarde en krimpt het enge deel, dus de startup krijgt een onderhoudbaar systeem zonder het bedrijf in te zetten op een herbouw vanaf nul die ze zich niet kan veroorloven.

Grote onderneming. Een grote verzekeraar draait polisadministratie op een COBOL-mainframesysteem dat betrouwbaar is maar duur om te wijzigen en wordt onderhouden door een handvol engineers nabij pensioen. In plaats van een herschrijving omhult de verzekeraar het mainframe met moderne API’s en past de wurgvijg toe: nieuwe vermogens voor offerte-en-koop en self-service worden gebouwd op een modern platform en geroute via een façade, terwijl kernpolisrecords op het mainframe blijven. Parallel documenteert het team bedrijfsregels en voegt karakteriseringstests rond de COBOL toe. Over meerdere jaren verhuist vermogen na vermogen van het mainframe, elke release waarde leverend, tot de resterende kern op de voorwaarden van de verzekeraar kan worden uitgefaseerd in plaats van onder crisis.

Overheid. Een uitkeringsinstantie moet een tientallen jaren oud uitkeringsberekeningssysteem moderniseren dat miljoenen burgers betaalt en niet onderbroken of onjuist betaald mag worden. Ze verwerpt een big-bang-vervanging na het bestuderen van vergelijkbare mislukte programma’s. In plaats daarvan profileert en reinigt ze de data, bouwt ze geautomatiseerde migratie met volledige reconciliatie tegen controletotalen en draait ze de nieuwe uitkeringsengine vele maanden parallel aan de oude, beide dezelfde aanvragen voedend en elke berekening vergelijkend, elke afwijking onderzoekend (vaak ongedocumenteerde legacyregels ontdekkend die behouden moeten blijven). Pas wanneer het nieuwe systeem het oude tot een zeer hoog vertrouwen evenaart, schakelt ze over uitkeringssoort voor uitkeringssoort, terugdraaien de hele tijd behoudend. De wurgfaçade laat burgers één doorlopende dienst zien over de overgang.

Zakelijke onderbouwing: motivatie, ROI en TCO

Legacymodernisering heeft een ongebruikelijke zakelijke onderbouwing, omdat de grootste kosten vaak de kosten van nietsdoen zijn en het grootste risico het moderniseringsproject zelf. De oplopende kosten van niet moderniseren zijn concreet: stijgend onderhoud en licenties op verouderende platforms, een steeds schaarser en duurder specialistisch personeelsbestand, onvermogen snel aan nieuwe regelgevende of dienstvragen te voldoen en groeiende blootstelling aan een catastrofaal falen terwijl niemand meer begrijpt hoe het systeem werkt. Daartegenover zijn de kosten van modernisering hoog, en als big bang gedaan draagt ze een werkelijk hoge kans op falen. Precies daarom doet de incrementele aanpak ertoe voor de ROI: ze zet één grote gok om in een reeks kleine die elk waarde teruggeven en kunnen worden gestopt.

Maak de zaak voor het bestuur door de keuze te herkaderen. De vraag is niet “moderniseren of niet”. Het is “nu incrementeel moderniseren, of oplopende beheerkosten betalen en later onder crisis een afgedwongen, riskantere modernisering tegemoet zien”. Kwantificeer de TCO van de status quo (platform- en licentiekosten, de premie voor schaarse vaardigheden, de risicogewogen kosten van een onherstelbare storing) en vergelijk die met een gefaseerd programma dat bij elke stap risico en kosten vermindert terwijl de service blijft draaien. Sta er cruciaal op dat elke voorgestelde herschrijving zo wordt gestructureerd dat ze vroeg en vaak waarde levert. Een programma dat drie jaar niets oplevert en met totaal verlies kan worden geannuleerd is geen investering. Het is een gok. Het sterkste ROI-argument voor de wurgaanpak is optionaliteit: waarde wordt continu opgeleverd en de organisatie kan op elk punt bijsturen.

Antipatronen en valkuilen

De big-bang-herschrijving. Meerjarige, alles-of-niets-vervanging die tot het eind geen waarde levert en vaak tegen hoge kosten wordt geannuleerd.
Herschrijven zonder te begrijpen. Code vervangen waarvan de bedrijfsregels nooit zijn gedocumenteerd, en stilletjes randgevallen laten vallen waarvan echte gebruikers en wetten afhangen.
De data onderschatten. Datamigratie als bijgedachte behandelen terwijl ze het moeilijkste, riskantste deel van het project is.
Dubbel draaien overslaan. Overschakelen naar het nieuwe systeem zonder parallelle vergelijking, afwijkingen pas ontdekkend nadat ze echte mensen raken.
Geautomatiseerde vertaling als oplossing. COBOL machinaal vertalen naar een moderne taal en geloven dat het werk gedaan is, wat onbegrijpelijke code produceert die de oude logica letterlijk reproduceert.
Moderniseren naar leeftijd, niet naar risico. Inspanning besteden aan oude maar stabiele systemen terwijl systemen met hoog risico en veel verandering wachten.
De kennis verliezen. De laatste onderhouders met pensioen laten gaan zonder de bedrijfsregels vast te leggen en karakteriseringstests toe te voegen.
Geen terugdraaien. Overschakelen zonder weg terug wanneer het nieuwe systeem zich onder echte belasting en echte data misdraagt.

Volwassenheidsmodel

Niveau 1: Initiëren. Legacysystemen worden gevreesd en bevroren. Verandering wordt vermeden. Er bestaat geen inventaris of risicobeoordeling. Modernisering, als ze al wordt geprobeerd, is een ad hoc alles-of-niets-herschrijving gedreven door frustratie. Kennis leeft in een paar hoofden op weg naar pensioen zonder dat iets is opgeschreven.
Niveau 2: Ontwikkelen. Sommige teams hebben een inventaris en een ruw gevoel van risico, en een paar legacysystemen zijn voor toegang omhuld met API’s. Incrementele patronen zijn bekend maar ongelijk toegepast, en het denken drijft nog naar big-bang-herschrijvingen. Datamigratie wordt geprobeerd maar onderschat, en de praktijk verschilt sterk van team tot team.
Niveau 3: Standaardiseren. Systemen worden geprioriteerd naar risico en waarde volgens een gedocumenteerde, organisatiebrede methode. Incrementele patronen (wurgvijg, branch by abstraction) zijn de afgedwongen standaard, en elke modernisering volgt een standaard draaiboek. Datamigratie is een geplande, gereconcilieerde inspanning met dubbel draaien voor de overschakeling, en kennisvastlegging en karakteriseringstests zijn vereiste praktijk in plaats van optioneel.
Niveau 4: Beheersen. Modernisering wordt gemeten en gestuurd met data. Het landschap draagt uitgangswaarden: formatie van onderhouders en pensioenhorizon per systeem, dekking van karakteriseringstests, slagingspercentages van migratiereconciliatie, aantallen afwijkingen bij dubbel draaien en opgeleverde waarde per stap, allemaal gevolgd tegen doelen. Beslissingen om te beheren of te vervangen en go/no-go-oordelen over de overschakeling worden op dit bewijs genomen, en een systeem dat voorbij zijn kennisrisicodrempel afdrijft triggert actie in plaats van op een crisis te wachten.
Niveau 5: Orkestreren. Modernisering is continu, geïntegreerd met bedrijfs- en risicoplanning en adaptief. Het portfolio wordt herbalanceerd tegen risicotrajectorie (vooral kennisrisico) naarmate die verschuift, incrementele vervanging is routine en weinig dramatisch, elke stap levert waarde en is omkeerbaar, en de organisatie stuurt het tempo bewust. Lessen uit elke migratie voeden terug in het gedeelde draaiboek zodat het hele landschap in de tijd verbetert.

Ideeën voor discussie

Hoeveel mensen kunnen je meest kritieke legacysysteem nog onderhouden, en hoe dicht zijn ze bij vertrek?
Waar word je verleid door een big-bang-herschrijving, en welke waarde zou een incrementele aanpak in de eerste drie maanden in plaats daarvan kunnen opleveren?
Hoe goed zijn de bedrijfsregels in je oudste systemen gedocumenteerd, en wat gebeurt ermee als de code wordt vervangen?
Heb je de data geprofileerd die je zou moeten migreren, en weet je hoe vuil en verstrengeld ze werkelijk is?
Aan welke oude maar stabiele systemen besteed je moderniseringsenergie die je veilig met rust zou kunnen laten?
Kun je je nieuwe systeem parallel aan het oude draaien en bewijzen dat ze overeenkomen voordat je overschakelt?

Belangrijkste inzichten

Legacy betekent waardevol en fundamenteel. Respecteer en begrijp een systeem voordat je het wijzigt.
Moderniseer incrementeel met de wurgvijg en branch by abstraction, continu waarde leverend en elke wijziging klein en omkeerbaar houdend.
Behandel de big-bang-herschrijving als de standaardfaalwijze. Bewaar haar voor werkelijk onhoudbare platforms en ontleed haar zelfs dan.
Prioriteer naar risico en waarde (vooral kennisrisico), niet naar leeftijd. Sommige oude systemen kunnen het best worden beheerd, niet vervangen.
Datamigratie en dubbel draaien zijn het hart van de inspanning: profileer, reconcilieer, draai parallel en houd terugdraaien.
De sterkste zakelijke onderbouwing is optionaliteit: incrementele modernisering zet één grote, riskante gok om in veel kleine, waarde teruggevende.

Referenties en verder lezen

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)