Dienst · Software-ontwikkeling

Cobol-systeem vervangen.

Een Cobol-applicatie op de mainframe die al decennia de kernprocessen draait: batchverwerking, financiële administratie, polisadministratie, salarisverwerking of overheidsuitkeringen. Het systeem werkt nog altijd stabiel, maar de mensen die de logica doorgronden gaan met pensioen, de licentie- en capaciteitskosten van de mainframe lopen op, en koppelen met een moderne API of cloud-omgeving is met de huidige architectuur nauwelijks te doen. Wij ontsluiten en vervangen Cobol-mainframesystemen stap voor stap, met behoud van de onderliggende business-regels en met uitgebreide validatie tegen de bestaande batchverwerking.

Plan een kennismaking Bekijk ons werk
↻

Een Cobol-mainframe stilzetten raakt het hart van de bedrijfsvoering.

Bij banken, verzekeraars, pensioenfondsen en overheidsinstanties draait de kernverwerking vaak nog altijd op Cobol. Nachtelijke batchjobs die polissen bijwerken, salarissen berekenen of uitkeringen verwerken, aangestuurd via JCL, met data in VSAM-bestanden of DB2-tabellen die dertig, veertig jaar geleden zijn opgezet. Deze systemen zijn niet fragiel in de zin dat ze vaak crashen, integendeel: ze hebben decennialang bewezen stabiel te draaien onder een bedrijfskritische last. Dat is precies waarom ze zo moeilijk los te laten zijn, en waarom vervanging zoveel zorgvuldigheid vraagt.

Cobol is een van de stacks die wij het vaakst tegenkomen binnen ons bredere traject legacy software vervangen, maar de mainframe-context brengt eigen risico's met zich mee die een aparte aanpak vragen. Het vakgebied vergrijst, er komen nauwelijks nieuwe Cobol-ontwikkelaars bij, en de mensen die de logica nog kennen zijn vaak al met pensioen of staan op het punt te vertrekken. Documentatie is er zelden, of is decennia geleden geschreven en sindsdien niet meer bijgewerkt. Elke wijziging aan het systeem is daardoor risicovoller dan hij zou moeten zijn: niemand weet precies wat er allemaal onder de motorkap gebeurt.

Het risico van niet-vervangen is niet dat het systeem morgen omvalt. Het risico is geleidelijk: kennis die stilletjes verdwijnt met elke pensionering, licentie- en capaciteitskosten die jaar op jaar een groter deel van het IT-budget opeisen, en een steeds grotere kloof met de moderne API's en cloud-diensten waarmee de rest van de organisatie inmiddels werkt. Wij beginnen daarom altijd met begrijpen wat er staat, voor we bepalen hoe en in welk tempo het vervangen wordt.

Hoe wij Cobol-trajecten aanpakken.

Business-regels documenteren
We reconstrueren de batchlogica en databronnen voor we iets bouwen
Gefaseerd uitfaseren
Strangler-pattern: batchjob voor batchjob overzetten, mainframe blijft draaien
Parallel-draaien & validatie
Shadow-run naast de bestaande batch, vergelijking op recordniveau
Kennis vastleggen
Wat in de hoofden van vertrekkende Cobol-programmeurs zit, komt op papier

Drie stappen om een Cobol-systeem te vervangen.

Bij mainframe-trajecten kiezen we zelden voor één ingreep. De stappen hieronder volgen elkaar op en overlappen deels: begrijpen wat er staat, het geleidelijk uitfaseren, en het uitgebreid bewijzen dat de nieuwe applicatie hetzelfde rekent als de oude.

Aanpak 01

Business-regels en batchlogica documenteren

Het fundament onder ieder Cobol-traject

We reverse-engineeren het bestaande systeem: Cobol-programma's en copybooks doorlichten, de JCL volgen om te zien in welke volgorde batchstappen lopen en van elkaar afhangen, en de onderliggende VSAM-bestanden en DB2-tabellen analyseren op structuur, sleutels en impliciete relaties. Waar nog collega's zijn die de dagelijkse werking kennen, halen we hun kennis op voor die met pensioen gaat of vertrekt. Het resultaat is een leesbare business-regelscatalogus die onafhankelijk is van één persoon.

Deze fase is bewust grondig, omdat de meest gemaakte fout bij Cobol-vervanging is dat een schijnbaar simpele batchjob toch een stille uitzonderingsregel blijkt te bevatten die nergens is opgeschreven. Die uitzonderingen komen we liever tijdens discovery tegen dan pas na een cut-over.

Copybook-analyseJCL-doorlichtingVSAM/DB2-analyseInterviews sleutelgebruikersBusiness-regelscatalogusBatchschema in kaart
Aanpak 02

Gefaseerd uitfaseren via het strangler-pattern

De gebruikelijke route bij bedrijfskritische mainframes

We zetten een koppelvlak voor de mainframe waarmee batchstromen en transacties per module kunnen worden omgeleid naar de nieuwe applicatie zodra die gereed is. De mainframe blijft draaien zolang er nog onvervangen batchjobs op staan, en wordt module voor module leeggehaald. Voor situaties waarin een deel van het landschap voorlopig blijft bestaan naast een nieuwe schil, sluit dit aan op onze bredere dienst legacy software moderniseren.

In de praktijk betekent dit dat de kernverwerking maanden achtereen deels op de mainframe en deels op het nieuwe platform draait, zonder dat er één moment is waarop alles tegelijk overgaat. Dat voelt trager dan een big-bang, maar is bij financieel-kritische systemen vrijwel altijd de veiligere en uiteindelijk snellere route.

Koppelvlak voor de mainframeBatchjob voor batchjobAPI-laagFeature-pariteit eerstGefaseerde uitrolAnti-corruption layer
Aanpak 03

Parallel-draaien en valideren op recordniveau

Onmisbaar bij financieel-kritische verwerking

Nieuwe modules worden eerst gebouwd op functionele gelijkheid met het bestaande systeem, niet op verbetering. Zodra een module klaar is, draait die als shadow-run naast de bestaande batch: dezelfde input, twee systemen, en een vergelijking van de uitkomsten op recordniveau, van saldi tot telsommen tot sleutelvelden. Pas wanneer een batch meerdere cycli achtereen exact overeenkomt, wordt die als gereed voor cut-over beschouwd.

Omdat het hier vaak om financiële administratie, polissen of uitkeringen gaat, bouwen we dit validatietraject bewust ruimer in dan bij een gemiddelde applicatie. Een discrepantie die bij een interne tool acceptabel zou zijn, is dat hier niet.

Shadow-runRecordniveau-reconciliatieFinanciële validatieRollback-padParallelle batchvergelijkingCut-over-plan

Wat u aan het einde heeft.

Een modern systeem in productie, vastgelegde business-regels die niet langer in de hoofden van een handjevol mensen zitten, en een mainframe die stap voor stap is leeggemaakt.

Productie + staging

Twee omgevingen op een moderne, ondersteunde stack, in uw eigen cloud of on-premise.

Vastgelegde business-regels

Leesbare documentatie van wat de Cobol-logica deed, onafhankelijk van individuele kennis.

Data-migratierapport

Wat er is overgegaan van VSAM en DB2 naar de nieuwe database, en welke validaties zijn uitgevoerd.

Decommissioning-plan mainframe

Hoe de mainframe batch voor batch wordt leeggehaald en uiteindelijk uitgezet, met een read-only-archief.

Beheer (optie)

Monitoring, backups, security-patches en doorontwikkeling onder een onderhoudscontract.

Wanneer een Cobol-traject onvermijdelijk wordt.

Vier patronen waarin uitstellen niet langer de veilige keuze is, en waarin wij meestal eerst worden uitgenodigd voor een discovery-gesprek voor er iets concreets gepland wordt.

Kennis

De laatste Cobol-programmeurs gaan met pensioen

Het vakgebied vergrijst en er worden nauwelijks nieuwe Cobol-ontwikkelaars opgeleid. De mensen die de logica van uw systeem nog echt doorgronden zijn vaak dezelfde mensen die binnen afzienbare tijd stoppen. Zodra die kennis vertrekt, wordt elke aanpassing aan het systeem een risicovolle zoektocht in plaats van een routineklus.

Kosten

Licentie- en capaciteitskosten van de mainframe lopen op

Mainframe-verwerking wordt doorgaans afgerekend naar gebruik en capaciteit, en die kosten stijgen terwijl de functionaliteit van het systeem gelijk blijft. Voor organisaties die kritisch naar hun IT-budget kijken, wordt dit op een gegeven moment een terugkerend gespreksonderwerp zonder dat er iets nieuws tegenover staat.

Integratie

Cobol laat zich moeilijk koppelen aan API's en cloud

De batchgeoriënteerde architectuur van een mainframe is niet gebouwd voor realtime koppelingen. Klanten, partners en interne afdelingen verwachten inmiddels directe API's en cloud-integraties. Elke nieuwe koppeling met het oude systeem vraagt een omweg via bestandsexports, tussenlagen of nachtelijke batchverwerking.

Documentatie

Niemand weet meer precies wat het systeem allemaal doet

Na decennia van opeenvolgende aanpassingen door verschillende teams is de oorspronkelijke documentatie achterhaald of volledig afwezig. Aanpassingen worden uitgesteld omdat niemand met zekerheid kan zeggen wat een wijziging elders raakt. Dat is precies het moment waarop het risico van niets doen groter wordt dan het risico van vervangen.

Risico's die we expliciet adresseren.

Een Cobol-vervanging is geen technisch project, het is een verandering die financieel-kritische processen raakt. Vier risico-categorieën die in elk traject bovenaan staan.

Kennis

Business-regels verdwijnen met vertrekkende medewerkers

We beginnen elk traject met discovery en interviews, juist voor de laatste mensen vertrekken die de logica nog kennen. Wat zij weten leggen we vast in een regelscatalogus, zodat kennis niet afhankelijk blijft van één persoon of team.

Data

Fouten bij de migratie van VSAM- en DB2-data

Oude datastructuren bevatten vaak impliciete relaties, ongeldige tekens en uitzonderingen die het mainframe altijd tolereerde. We doen een data-audit vooraf en bouwen een validatiesuite die elke migratie vergelijkt met het origineel, tot op recordniveau.

Continuiteit

Verstoring van bedrijfskritische batchverwerking

We faseren elke overgang zodat één batchjob of module tegelijk overgaat, draaien uitgebreide shadow-runs voor de cut-over en houden een rollback-pad open tot een deelproces meerdere cycli stabiel draait.

Compliance

Financiële en verzekeringsdata onder bewaarplicht

Voor data die onder een wettelijke bewaarplicht valt, houden we een gedocumenteerd, read-only-archief van het oude systeem aan en leggen we de migratie zelf vast met een audit-trail, zodat herleidbaarheid nooit verloren gaat.

Hoe een Cobol-traject loopt.

01Kennismaking→ 02Discovery & documentatie→ 03Bouw & parallel-draaien→ 04Cut-over & decommissioning
Stap 01

Kennismaking

Welk systeem staat er, hoe oud is het, wie kent de logica nog, welke pijn is het meest acuut. Vrijblijvend gesprek met IT en de business.

Stap 02

Discovery & documentatie

We reverse-engineeren de Cobol-code, JCL en datastructuren, interviewen sleutelgebruikers en leggen de business-regels vast in een regelscatalogus.

Stap 03

Bouw & parallel-draaien

Modules in sprints bouwen op functionele gelijkheid, shadow-runs naast de bestaande batch en validatie op recordniveau voor elke module.

Stap 04

Cut-over & decommissioning

Gefaseerde overgang per batchjob, rollback-pad paraat, mainframe leegmaken en uiteindelijk uitzetten, met een read-only-archief.

Van Cobol-mainframe naar moderne stack.

Sommige organisaties draaien naast de Cobol-mainframe ook nog een AS/400-omgeving; voor die combinatie hebben we een aparte aanpak onder AS/400 vervangen. En omdat de batchoutput van Cobol-systemen in de praktijk vaak wordt ontsloten via een verouderde rapportagelaag, raakt dit traject regelmatig ook Crystal Reports vervangen.

Mainframe-stack die we tegenkomen
CobolJCLCICSIMSVSAMDB2PL/IAssemblerRACF
Doelstack, frontend & backend
Java.NET 8PythonNode.jsReactPostgreSQLKafkaREST/GraphQL
Migratie, infra & integratie
Strangler-routeringETL-pipelinesBatch-naar-eventAnti-corruption layerAWS/Azure/GCPTerraformDocker

Veelgestelde vragen.

Hoe blijven de business-regels behouden als er geen documentatie van het Cobol-systeem bestaat?
We reconstrueren de business-regels vanuit de code zelf, niet vanuit documentatie die er vaak niet of nauwelijks is. We lezen de Cobol-programma's en copybooks, volgen de JCL om te zien in welke volgorde batchstappen lopen, analyseren de VSAM- en DB2-structuren om te achterhalen welke velden en referenties er echt toe doen, en interviewen de medewerkers die de dagelijkse werking nog kennen. Wat daaruit komt leggen we vast in een leesbare regelscatalogus. Waar de code zelf dubbelzinnig is, zetten we een shadow-run op waarin het nieuwe systeem dezelfde input verwerkt als de mainframe, zodat afwijkingen zichtbaar worden nog voor er een cut-over plaatsvindt.
Kunnen we de mainframe parallel laten draaien met het nieuwe systeem?
Ja, dat is bij Cobol-trajecten vrijwel altijd de gekozen route. We zetten een koppelvlak voor de mainframe zodat batchverwerking en transacties per module kunnen worden omgeleid naar de nieuwe applicatie zodra die aantoonbaar gelijk presteert. De mainframe blijft draaien zolang er nog onvervangen onderdelen op staan en wordt pas uitgezet als de laatste batchjob is overgenomen. Zo is er nooit een moment waarop de volledige kernverwerking in één keer overgaat.
Wat gebeurt er met de data in de VSAM-bestanden en DB2-tabellen?
We beginnen met een data-audit: welke bestanden en tabellen zijn er, welke velden zijn eigenlijk nog in gebruik, welke referenties tussen VSAM-bestanden en DB2-tabellen zijn impliciet in de code verwerkt in plaats van in een sleutel vastgelegd. Op basis daarvan bouwen we een migratiepad naar een moderne, relationele of gedistribueerde database, met een validatiesuite die elke migratieslag vergelijkt met het origineel op aantallen, sommen en sleutelvelden. Tot ruim na de cut-over houden we het mainframe-archief read-only beschikbaar, onder meer voor data die onder een wettelijke bewaarplicht valt.
Hoe lang duurt de discovery-fase voordat er gebouwd wordt?
Dat hangt af van hoeveel Cobol-programma's, copybooks, JCL-jobs en datastructuren er zijn, en van hoeveel kennis nog aanwezig is bij de mensen die het systeem gebruiken of onderhouden. Bij een compact, redelijk gedocumenteerd systeem is de discovery een kortere fase, bij een uitgebreid mainframe-landschap met tientallen jaren aan opeenvolgende aanpassingen kost het reconstrueren van de logica meer sprints. We geven pas een concrete planning nadat de discovery is afgerond, omdat elke inschatting daarvoor giswerk is.
Is het risico op stilstand van de batchverwerking tijdens het traject beheersbaar?
Beheersbaar, mits er gefaseerd gewerkt wordt in plaats van in één keer omgeschakeld. Batchjobs worden een voor een overgezet, telkens pas nadat de nieuwe versie meerdere cycli stabiel en met identieke uitkomsten heeft gedraaid naast de bestaande verwerking. Het grootste risico is niet de overstap zelf, maar een neveneffect dat niemand had voorzien. Daarom draaien we uitgebreide shadow-runs en houden we een rollback-pad open tot een deelproces aantoonbaar betrouwbaar is.
Werken jullie samen met de laatste Cobol-programmeurs binnen onze organisatie?
Heel graag, en waar mogelijk vanaf de discovery-fase. Zij kennen uitzonderingen en workarounds die nergens zijn opgeschreven en die anders pas na de cut-over aan het licht komen. We plannen de betrokkenheid zo dat het geen fulltime belasting wordt naast hun reguliere werk, en leggen wat zij weten vast in documentatie zodat die kennis niet met hun pensioen verdwijnt. Is er niemand meer intern beschikbaar, dan reconstrueren we de logica volledig uit code, data en interviews met de gebruikersgroepen die er dagelijks mee werken.
Hoe zeker weten we dat de nieuwe applicatie financieel correct rekent?
Door uitgebreide validatie voordat er sprake is van een cut-over. Nieuwe modules worden eerst getoetst op functionele gelijkheid met het bestaande systeem, niet op verbeteringen. Daarna draaien we shadow-runs waarin dezelfde input door zowel de mainframe als de nieuwe applicatie gaat, en vergelijken we de uitkomsten op recordniveau: bedragen, saldi, telsommen en sleutelvelden. Pas wanneer een batch of module meerdere cycli exact overeenkomt, wordt die als gereed voor cut-over beschouwd. Voor financieel-kritische verwerking bouwen we dit validatietraject bewust ruimer dan bij een gemiddeld legacy-traject.
Moeten we het hele mainframe in één keer vervangen?
Nee, en dat raden we ook af. Een volledige Cobol-mainframe in één keer vervangen is bij bedrijfskritische verwerking zelden verantwoord. We kiezen vrijwel altijd voor het strangler-pattern: batchjob voor batchjob, module voor module wordt overgezet zodra die gereed en gevalideerd is, terwijl de rest van de mainframe intussen gewoon doordraait. Dat verlengt het traject in fases, maar verlaagt het risico aanzienlijk ten opzichte van een big-bang-overstap.

Praat met ons over uw Cobol-systeem.

Een kennismaking van een half uur, vrijblijvend. We luisteren naar wat er nu draait, wie de logica nog kent, waar het knelt en wat de aanleiding is om er nu wel naar te kijken, ook als blijkt dat vervanging op dit moment niet de juiste route is.

Plan een kennismakingMail fabian.vandijk@appfront.nl

Edit Content