Modernisering van legacy-mainframes

Uw COBOL verwerkt nog steeds 95% van alle pinautomaattransacties. De ontwikkelaars die het schreven, gaan met pensioen.

70-80% van de mainframe-moderniseringsprojecten mislukt. Niet omdat de technologie verkeerd is, maar omdat de tools code als tekst behandelen in plaats van als topologie. Wij bouwen de kaart van uw codebase voordat we ook maar één regel aanraken, zodat uw migratie slaagt waar anderen miljoenen hebben verbrand en niets hebben opgeleverd.

$1,52 biljoen

Technische schuld VS

Pragmatic Coders, 2025

10%/jaar

Verloop COBOL-personeel

IEEE Spectrum, 2025

70-80%

Faalpercentage modernisering

Brancheoverkoepelende meta-analyse, 2025

Waarom AI-codevertaling op mainframes faalt

De tools die beloven "plak COBOL, krijg Java" produceren code die compileert. Dat is het makkelijke deel. Het moeilijke deel is de code die ze niet kunnen zien.

Het REDEFINES-probleem: een reëel migratiefaalpatroon

Denk aan een verwerkingsprogramma voor overboekingen. Het bevat een COMPUTE-statement dat een variabele gebruikt genaamd TRN-LIMIT. Een AI-codeerassistent vertaalt het statement naar een Java- BigDecimal operatie. De code compileert. Unittests slagen.

In UAT crasht de eerste transactie de databaseconsistentiecontrole.

De autopsie: TRN-LIMIT was niet gedefinieerd in het bronbestand dat de AI vertaalde. Het was duizenden regels eerder in de uitvoeringsketen gedefinieerd in een copybook. Dat copybook bevatte een REDEFINES -clausule, een COBOL-constructie waarmee hetzelfde geheugenadres als twee verschillende datatypes kan worden geïnterpreteerd, afhankelijk van een vlag die in een volledig andere module is gezet.

De AI zag TRN-LIMIT als een eenvoudig numeriek veld en ging uit van een standaard integertype. Op het mainframe bevatte dat geheugenadres een packed decimal (COMP-3). De Java-applicatie schreef beschadigde binaire data naar de databasekolom, wat een schending van de referentiële integriteit veroorzaakte.

De code was syntactisch perfect. De fout was contextuele blindheid. De AI miste een afhankelijkheid die buiten zijn gezichtsveld lag.

VERBORGEN AFHANKELIJKHEID

Copybook-ketens

Eén COBOL-programma kan naar 40+ copybooks verwijzen. Elk copybook kan andere copybooks COPYen. Variabeledefinities kunnen 5 niveaus diep in de inclusieketen zitten. Tekstgebaseerde AI-tools zien hier niets van.

ONZICHTBARE LAAG

JCL-jobnetwerken

Uw COBOL draait niet zelfstandig. CA-7 of TWS plant 2.000-5.000 JCL-jobs met afhankelijkheidsketens. Job A schrijft een dataset die Job B om 2 uur 's nachts leest. Migreer de COBOL maar mis de JCL, en de productie loopt om middernacht vast.

REKENKUNDIGE VALKUIL

Packed-decimal-rekenkunde

COBOL's COMP-3 packed decimal heeft geen Java-equivalent. Een Java- double introduceert afrondingsfouten door drijvende komma. Zelfs BigDecimal vereist een expliciete configuratie van de afrondingsmodus (HALF_EVEN) om overeen te komen met COBOL's ROUNDED-clausule. Eén verkeerde cent stapelt zich op over miljoenen transacties.

Het moderniseringslandschap in 2026

Elke grote technologieleverancier verkoopt nu mainframe-modernisering. Hier is wat elk daadwerkelijk levert, en waar de lacunes blijven.

Leverancier / aanpak Wat het doet Typische kosten Wat het mist
IBM Watsonx Code Assistant for Z Agentic COBOL-naar-Java-vertaling met ADDI-afhankelijkheidsanalyse. Multi-agent-architectuur (Orchestrate-, Architect-, Code-agents). Ondersteunt PL/I en IMS. $2M+ (enterprise-licentie + z/OS-vereiste) ADDI draait op z/OS, wat vendor lock-in creëert tijdens de migratie. De parser worstelt met pre-85-COBOL-constructies (ALTER-statements). Geen testen van gedragsequivalentie. Geen mapping van JCL-afhankelijkheden.
Anthropic Claude Code AI-gestuurde code-analyse, documentatie, afhankelijkheidsmapping. Sterk in de ontdekkings- en verkenningsfasen. Ondersteunt incrementele migratie en API-wrapping. Gebruiksgebaseerde API-prijzen Algemene AI. Geen ingebouwde knowledge graph voor het oplossen van transitieve afhankelijkheden. Adresseert geen JCL-planning, testen van gedragsequivalentie of regelgevende audittrails.
Microsoft Azure Migration Factory Modulaire agentic agents via Semantic Kernel. COBOL Expert- + Java Expert-agents. Richt zich op Java Quarkus. Azure Copilot-migratie-agent in preview. Azure-verbruik + consultancy Azure lock-in voor het doelplatform. Open-source-agents zijn referentie-implementaties, niet productieklaar voor gereguleerde omgevingen. Beperkte CICS/IMS-ondersteuning.
DXC Technology Gepatenteerde automatische codeconversie (COBOL/RPG/JCL naar Java). Decennia aan mainframe-expertise. Hybride cloud- + mainframe-as-a-service-modellen. $1M-$10M+ Propriëtaire tooling, beperkte transparantie over de conversielogica. Focus op grote ondernemingen. Doorlooptijden van 18-36 maanden zijn gebruikelijk.
TCS / Infosys / Accenture Grote systeemintegrator-praktijken met propriëtaire frameworks (MasterCraft, Cobalt). Enorme deliveryteams. End-to-end-programmamanagement. $500K-$5M+ Platformgerichte aanpak. Zij implementeren leverancierstools, bouwen geen maatwerkintelligentie. Overhead van het grote SI-engagementmodel. Eén SI leidde een bankmigratie van $1 miljard AUD die 5 jaar duurde en het budget verdubbelde.
Micro Focus (OpenText) Visual COBOL Draai COBOL native op .NET/JVM. Pragmatisch "strangler fig"-startpunt. Marktleider in COBOL-compilers. $200K-$500K licentie Geen modernisering, maar rehosting. COBOL-logica blijft COBOL. Technische schuld blijft bestaan. Lost het personeelsprobleem niet op.
Doe-het-zelf met open-source AI XMainframe LLM (7B/10,5B params, 30% beter dan DeepSeek op COBOL). Tree-sitter-parsing. Maatwerkpijplijnen. Engineeringtijd + infrastructuur Vereist diepgaande COBOL- + graph-engineering-expertise. Geen productiewaardige COBOL-parser dekt alle IBM Enterprise COBOL v6.x-constructies. Hoog risico op het inbouwen van parserlacunes in het fundament.
Eerlijke kanttekening: Geen enkele tool, de onze inbegrepen, lost organisatorische draagvlak, dataquality-problemen of de politieke uitdaging op om 200 ontwikkelaars te overtuigen hun werkwijze te veranderen. Technologie is noodzakelijk maar niet voldoende. Als uw organisatie geen executive sponsorship voor modernisering heeft, begin daar dan voordat u een leverancier inschakelt.

Wat wij bouwen

Vijf capabilities, elk gericht op een specifieke lacune in de moderniseringstoolchain. Wij zijn vendor-neutraal: de knowledge graph werkt ongeacht of uw doel AWS, Azure, GCP of on-premises Java is.

Knowledge graph van de codebase

Wij nemen uw COBOL-broncode, copybooks, JCL-bibliotheken, DB2-catalogusexports, CICS-transactiedefinities en IMS-segmenthiërarchieën op in een geïntegreerde graph-database. Elke variabele, elke PERFORM-keten, elke REDEFINES-clausule, elke batch-afhankelijkheid wordt een expliciete graph-edge. Wij grijpen naar Neo4j wanneer complexe transitieve-afsluitingsqueries de use case domineren, en naar Memgraph wanneer realtime traversal-snelheid van belang is voor interactieve verkenning.

De graph verwerkt tijdens de ingestie ongeveer 200K-300K regels per dag. Voor een codebase van 2M LOC kunt u 8-12 weken verwachten van de eerste ingestie tot een gevalideerde, queryeerbare graph. De output is een blijvend bezit: uw codebase als doorzoekbare topologie, niet als ondoorzichtige tekstbestanden.

Migratierisicobeoordeling en extractievolgordebepaling

Voordat enige codevertaling begint, voeren wij graph-analyse uit over vier dimensies: koppelingsscore (hoeveel andere modules van deze afhankelijk zijn), REDEFINES/COMP-3-dichtheid (hoeveel datatype-valkuilen er bestaan), percentage dode code (doorgaans 20-30% van de codebase) en kritikaliteit van batch-planning (welke JCL-jobs deze module raken en wanneer).

De output is een gerangschikte extractievolgorde voor strangler-fig-migratie. Modules met de laagste koppeling en eenvoudigste datatypes worden eerst geëxtraheerd. "God programs" die door 50+ andere modules worden aangeroepen, worden als laatste geëxtraheerd. Deze volgordebepaling is het verschil tussen een beheerste uitrol en een cascade-storing.

Graph-versterkte codevertaling

Onze vertaalagents bevragen de knowledge graph voordat ze elke Java-module genereren, en halen de volledige transitieve afsluiting van afhankelijkheden op. De agent ziet de REDEFINES-clausule in het copybook drie mappen verderop. Hij ziet de packed-decimal-definitie die het afrondingsgedrag bepaalt. Hij genereert Java met expliciet parameter passing (dependency injection) in plaats van COBOL's impliciete globale state. Vervolgens compileert hij in een sandbox, voert tests voor gedragsequivalentie uit en corrigeert zichzelf.

Wij gebruiken het foundation-model dat past bij de complexiteit van de module. Voor eenvoudige PERFORM-naar-methode-conversies volstaat een kleiner model prima. Voor modules met geneste REDEFINES, GOTO-spaghetti die afvlakking van de controlestroom vereist, of EXEC CICS-ingebedde transactielogica halen wij het meest capabele beschikbare model erbij en versterken het met de volledige graph-context.

Testharnas voor gedragsequivalentie

Het onderdeel dat de meeste leveranciers overslaan en waarop de meeste migraties stranden. Wij bouwen een validatiesysteem met drie lagen: symbolische unittests gegenereerd uit graph-afgeleide controlestroompaden, replay van een golden dataset met vastgelegde productietransacties die veld-voor-veld worden vergeleken met cent-perfecte nauwkeurigheid, en parallelle productie-runs waarbij beide systemen 30-90 dagen live transacties verwerken voordat de mainframe-module wordt buiten gebruik gesteld.

Financiële berekeningen vereisen BigDecimal met HALF_EVEN-afrondingsmodus om overeen te komen met COBOL's ROUNDED-clausule. Datumberekeningen vereisen verwerking van COBOL's 6-cijferige datumformaat (YYMMDD) met century-windowing-logica. Wij bouwen deze conversieregels in de testharnas in, niet in ad-hoc-patches die tijdens QA worden ontdekt.

Migratie van batch-planning

Wij parsen uw JCL-jobnetwerken, CA-7/TWS/Control-M-afhankelijkheidsketens en batchverwerkingssequenties in de knowledge graph. Elke JCL-job wordt een node met edges naar de COBOL-programma's die hij uitvoert, de datasets die hij leest en schrijft, en de planningsvoorwaarden waarvan hij afhankelijk is (tijdtriggers, dataset-beschikbaarheid, voltooiing van voorgangers).

Wanneer een COBOL-module naar Java migreert, bouwen wij tegelijkertijd de equivalente planning in uw doel-orchestratieplatform (Apache Airflow, AWS Step Functions, Azure Data Factory of Control-M op gedistribueerde systemen). De afhankelijkheidsketen blijft behouden en wordt geverifieerd tegen de oorspronkelijke CA-7/TWS-definitie. Een typische mid-tier-bank heeft 2.000-5.000 JCL-jobs. Wij hebben ze allemaal gezien.

Hoe de knowledge graph een REDEFINES-keten oplost

Een stapsgewijze uitleg van hoe graph-gebaseerde afhankelijkheidsresolutie het meest voorkomende migratiefaalpatroon voorkomt.

1

Parser neemt bron en copybooks op

De parser verwerkt PROG-WIRE-01.cbl, komt COPY CB-ACCT-LIMITStegen en volgt de inclusieketen. Hij bouwt AST-nodes voor elke variabeledeclaratie, inclusief die in copybooks die 3 niveaus diep zijn genest.

* In CB-ACCT-LIMITS.cpy:
01 ACCT-LIMIT-RECORD.
05 TRN-LIMIT PIC S9(9)V99 COMP-3.
05 TRN-LIMIT-ALPHA REDEFINES TRN-LIMIT PIC X(6).
05 LIMIT-TYPE-FLAG PIC X.
2

Graph maakt relatie-edges aan

De graph-engine maakt edges aan: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. Dit legt het feit vast dat het datatype van TRN-LIMIT afhangt van een runtime-vlag in een ander veld.

3

Transitieve afsluiting onthult de volledige impact

De graph traverseert naar buiten: welke andere programma's COPYen CB-ACCT-LIMITSook? Welke programma's zetten LIMIT-TYPE-FLAG? Welke JCL-jobs voeren die programma's uit, en in welke volgorde? Het resultaat is een volledige impactketen. Het wijzigen van hoe TRN-LIMIT wordt vertaald, beïnvloedt elk programma in deze keten.

4

Vertaalagent krijgt de volledige context

Wanneer de vertaalagent PROG-WIRE-01verwerkt, haalt GraphRAG niet alleen het bronbestand op, maar ook de copybook-definitie, de REDEFINES-relatie, het vlagveld en alle programma's die de vlag zetten. De agent genereert een Java-klasse met een type-safe union-patroon: een TransactionLimit -object dat de vlag controleert voordat het de onderliggende bytes interpreteert als ofwel een BigDecimal (packed-decimal-modus) of een String (alfa-modus).

Zonder de graph: gaat de AI ervan uit dat TRN-LIMIT een eenvoudig numeriek veld is, genereert een long in Java, en de eerste overboeking corrumpeert de database. Met de graph: ziet de AI de volledige afhankelijkheidsketen en genereert type-safe code die beide interpretaties correct verwerkt. Dit is het verschil tussen een migratie die werkt in UAT en een die werkt in productie.

Hoe wij werken

Vier fasen, elk met duidelijke deliverables. Wij offreren geen tijdlijn van 3 jaar en verdwijnen niet. Elke fase levert artefacten op die u bezit en onafhankelijk kunt gebruiken.

FASE 1 / 4-6 WEKEN

Beoordeling en ontdekking

  • Broncode-export vanuit z/OS (COBOL, JCL, copybooks, DB2 DDL)
  • Identificatie van COBOL-dialect (IBM Enterprise v4/v5/v6, Micro Focus, Fujitsu)
  • Scan van dode code (typisch resultaat: 20-30% van de LOC onbereikbaar)
  • Analyse van MIPS-verbruik per programma
  • Voorlopige extractievolgorde met koppelingsscores

Deliverable: beoordelingsrapport + voorlopig prototype van de knowledge graph

FASE 2 / 8-12 WEKEN

Constructie van de knowledge graph

  • Volledige ingestie van de codebase met maatwerk-parser-extensies voor uw dialect
  • Entity resolution over alle copybooks, DB2-schema's, CICS-definities
  • Mapping van JCL-jobnetwerk met CA-7/TWS-afhankelijkheidsketens
  • Berekening van transitieve afsluiting met validatie van volledigheid
  • Interactieve query-interface ("Wat breekt er als ik deze variabele wijzig?")

Deliverable: queryeerbare knowledge graph + gerangschikte extractievolgorde + impactanalyse-tool

FASE 3 / DOORLOPEND (STRANGLER FIG)

Incrementele migratie

  • Module-voor-module-vertaling volgens de extractievolgorde
  • Graph-versterkte AI-vertaling met volledige afhankelijkheidscontext
  • Testen van gedragsequivalentie per module (golden dataset + parallelle run)
  • Migratie van batch-planning voor elke geëxtraheerde module
  • Bijhouden van MIPS-reductie (typisch: 20-30% in jaar 1)

Deliverable: gemigreerde Java-modules in productie + bijgewerkte knowledge graph + planningsequivalenten

FASE 4 / PER MODULE

Validatie en buitengebruikstelling

  • Parallelle productie-run van 30-90 dagen per module
  • Vergelijking van differentiële output met cent-perfecte financiële validatie
  • Regelgevende documentatie (audittrail, change control, SOC 2-bewijs)
  • Buitengebruikstelling van mainframe-module na ondertekening
  • Bijwerken van de knowledge graph om de nieuwe architectuur weer te geven

Deliverable: gevalideerde productie-implementatie + pakket met regelgevende documentatie + bijgewerkte graph

Kanttekening bij de tijdlijn: Dit zijn typische bandbreedtes voor een mid-tier-instelling (1-5M LOC). Grotere codebases, meerdere COBOL-dialecten of zwaar CICS-gebruik verlengen fase 2. Wij bepalen de scope precies na de beoordeling in fase 1.

Gereedheidsbeoordeling voor mainframe-modernisering

Beantwoord zeven vragen over uw omgeving. De beoordeling identificeert uw gereedheidsniveau en specifieke blokkades die u moet aanpakken voordat u een migratieopdracht start, met of zonder Veriprajna.

1. Hoeveel regels COBOL draaien er in actieve productie?

2. Welk COBOL-dialect gebruikt uw omgeving?

3. Heeft u actuele documentatie van uw batch-job-afhankelijkheden?

4. Hoeveel COBOL-vaardige ontwikkelaars heeft u momenteel in dienst?

5. Welke regelgevingskaders zijn van toepassing op uw mainframe-systemen?

6. Heeft u eerder een moderniseringsproject geprobeerd?

7. Sponsort de raad van bestuur of de C-suite modernisering actief?

Vragen die wij horen van CTO's en VP Engineering

Hoe lang duurt het om een knowledge graph te bouwen voor een COBOL-codebase van 2 miljoen regels?

Voor een codebase van 2M LOC met typische complexiteit (IBM Enterprise COBOL v6.x, DB2 embedded SQL, 500+ copybooks) duurt de constructie van de graph 8 tot 12 weken. De eerste 3 weken gaan over parserconfiguratie en -validatie. COBOL-dialecten variëren genoeg dat wij moeten verifiëren dat de parser uw specifieke gebruik van REDEFINES, OCCURS DEPENDING ON en EXEC CICS/SQL-blokken aankan voordat we de volledige codebase opnemen.

Week 4 tot en met 8 zijn geautomatiseerde ingestie, entity-extractie en relatie-mapping. De parser verwerkt ongeveer 200K-300K regels per dag, maar het knelpunt is entity resolution, specifiek het vaststellen dat ACCT-NUM in Programma A en ACCT-NUM in Copybook CB-ACCT-01 dezelfde variabele zijn.

Week 9 tot en met 12 zijn de berekening van de transitieve afsluiting en validatie. Wij voeren controles op de volledigheid van de graph uit: elk PERFORM-doel moet naar een paragraaf herleidbaar zijn, elk COPY-statement moet naar een copybook herleidbaar zijn, elke DB2-tabelverwijzing moet aan een schemadefinitie worden gekoppeld. Lacunes worden gemarkeerd voor handmatige beoordeling. De output is een queryeerbare knowledge graph waarin u vragen kunt stellen als "Wat gebeurt er als ik INTEREST-RATE in CB-GLOBAL-01 wijzig?" en een volledige impactketen krijgt over elk programma dat ernaar verwijst, direct of transitief.

Kunnen we incrementeel moderniseren in plaats van een volledige herschrijving uit te voeren?

Ja, en wij raden het sterk aan. Het strangler-fig-patroon is de enige aanpak met een bewezen staat van dienst voor mainframe-migratie. Volledige herschrijvingen mislukken in 70-80% van de gevallen omdat ze proberen alles tegelijk te vervangen, wat één enorm faalpunt creëert.

Met de strangler-fig-aanpak identificeert de knowledge graph welke modules de laagste koppelingsscores hebben, wat betekent de minste inkomende afhankelijkheden van andere modules. Dit zijn uw extractiekandidaten. Wij beginnen doorgaans met batch-rapportagemodules of zelfstandige berekeningsroutines die uit DB2 lezen maar geen gedeelde state bijwerken. De nieuwe Java-service draait naast het mainframe. Productieverkeer wordt voor die specifieke functie naar de nieuwe service gerouteerd, terwijl het mainframe al het andere blijft afhandelen. U valideert gedragsequivalentie op echte productiedata voordat u de COBOL-module buiten gebruik stelt.

De meeste organisaties extraheren in het eerste jaar 15 tot 20 modules, verlagen het MIPS-verbruik met 20-30% en genereren genoeg kostenbesparing om de volgende fase te financieren. De knowledge graph maakt dit veilig omdat hij u de blast radius van elke extractie toont. Als Module A door 47 andere programma's wordt aangeroepen, is dat niet uw eerste extractiekandidaat. Als Module B door 2 programma's wordt aangeroepen en uit 1 DB2-tabel leest, begin daar dan.

Hoe gaat u om met JCL-batch-afhankelijkheden die de meeste AI-tools negeren?

Dit is de laag waar de meeste moderniseringsprojecten 6 tot 12 maanden later op onverwachte fouten stuiten. Uw COBOL-programma's draaien niet geïsoleerd. Ze worden georkestreerd door JCL-jobstreams beheerd door CA-7, TWS (Tivoli Workload Scheduler) of Control-M. Een typische mid-tier-bank heeft 2.000 tot 5.000 JCL-jobs met complexe afhankelijkheidsketens: Job A moet voltooid zijn voordat Job B start, Job C draait alleen op de laatste werkdag van de maand, Job D triggert een CICS-transactie die een VSAM-bestand bijwerkt dat door Job E wordt gelezen.

Wij parsen JCL samen met COBOL in dezelfde knowledge graph. Elke JCL-job wordt een node met edges naar de COBOL-programma's die hij uitvoert, de datasets die hij leest en schrijft, en de planningsvoorwaarden waarvan hij afhankelijk is. Wanneer wij een COBOL-module naar Java migreren, bouwen wij tegelijkertijd de equivalente planning in uw doelplatform, of dat nu Apache Airflow, AWS Step Functions of Azure Data Factory is. De afhankelijkheidsketen blijft behouden en wordt geverifieerd tegen het origineel.

Wij hebben projecten gezien waar de codemigratie perfect slaagde maar de productie vastliep omdat niemand de CA-7-job had gemapt die elke nacht om 2 uur een voorverwerkingsstap uitvoerde.

Wat maakt uw aanpak anders dan IBM Watsonx Code Assistant for Z?

IBM Watsonx Code Assistant for Z (momenteel v2.8.20, met Project Bob dat later in 2026 komt) is een sterk product met diepe mainframe-integratie. Het vereist IBM ADDI (Application Discovery and Delivery Intelligence) om zijn afhankelijkheidsanalyse op te bouwen, en ADDI draait op z/OS. Dit betekent dat uw afhankelijkheidsanalyse-tooling op hetzelfde mainframe leeft als waar u juist vanaf probeert te migreren. Het betekent ook dat IBM de analyselaag beheert, wat vendor lock-in creëert tijdens de meest kritieke fase van de migratie.

Onze knowledge graph draait off-mainframe. Wij nemen broncode-exports, JCL-bibliotheken, DB2-catalogusexports en copybook-repositories op. De graph leeft in uw cloudomgeving of on-premises-infrastructuur, onafhankelijk van IBM-licenties. Ten tweede richt Watsonx zich op COBOL-naar-Java-vertaling. Wij richten ons eerst op begrip, en pas daarna op vertaling. De knowledge graph is een blijvend bezit dat impactanalyse, documentatiegeneratie en architectuurgovernance dient, nog lang nadat de migratie voltooid is.

Ten derde heeft ADDI's COBOL-parser gedocumenteerde beperkingen met pre-85-COBOL-constructies, met name ALTER-statements en bepaalde geneste REDEFINES-patronen. Wij bouwen maatwerk-parser-extensies voor het dialect van elke klant.

Tot slot richt IBM's prijsstelling zich op grote ondernemingen. Ons engagementmodel werkt voor mid-tier-instellingen waar een IBM-opdracht van $2M+ niet in het budget past.

Hoe bewijst u dat de Java-code zich identiek gedraagt aan het COBOL-origineel?

Gedragsequivalentie is waar de meeste AI-ondersteunde migraties uiteenvallen. Code die compileert en unittests doorstaat, kan nog steeds verkeerde resultaten produceren door verschillen in packed-decimal-afronding, EBCDIC-naar-ASCII-coderingsmismatches of REDEFINES-geheugenoverlay-semantiek die niet naar Java-objecten vertaalt.

Wij bouwen een validatieharnas met drie lagen. Laag 1 is symbolische equivalentie: wij genereren unittests uit de knowledge graph die elke vertakking in de oorspronkelijke COBOL-controlestroom dekken, inclusief randgevallen zoals negatieve bedragen, deling-door-nul-bewaking en schrikkeljaar-datumberekeningen. Laag 2 is replay van een golden dataset: wij leggen een representatieve set productietransacties van het mainframe vast (invoerrecords, DB2-leesbewerkingen, CICS-interacties) en spelen ze opnieuw af door de nieuwe Java-service. Outputs worden veld-voor-veld vergeleken. Voor financiële berekeningen verifiëren wij cent-perfecte nauwkeurigheid met BigDecimal en HALF_EVEN-afronding om overeen te komen met het gedrag van COBOL's ROUNDED-clausule.

Laag 3 is een parallelle productie-run: beide systemen verwerken 30 tot 90 dagen tegelijkertijd dezelfde live transacties. Discrepanties worden gelogd, onderzocht en opgelost voordat de mainframe-module wordt buiten gebruik gesteld. Dit is de langste fase, maar ook de fase die de randgevallen opvangt die zich over 30 jaar productie hebben opgehoopt en die geen enkele testsuite volledig kan voorzien.

Wat betekent DORA voor onze mainframe-systemen, en helpt modernisering bij compliance?

DORA (Digital Operational Resilience Act) is sinds 17 januari 2025 volledig van kracht en heeft directe impact op elke EU-gereguleerde financiële entiteit die mainframe-systemen draait. Artikel 11 vereist ICT-risicobeheerkaders die regelmatige weerbaarheidstests en threat-led penetratietests op basis van realistische aanvalsscenario's omvatten. De meeste mainframe-omgevingen waren niet voor dit soort testen ontworpen. U kunt niet eenvoudig een replica z/OS-omgeving optuigen om penetratietests uit te voeren zonder aanzienlijke licentie- en infrastructuurkosten.

DORA vereist ook gedetailleerde ICT-activa-inventarissen, incidentrapportage binnen specifieke termijnen en third-party-risicobeheer voor kritieke ICT-dienstverleners, waaronder uw mainframe-leverancier. Modernisering helpt op twee manieren. Ten eerste dient de knowledge graph zelf als de ICT-activa-inventaris die DORA vereist. Hij mapt elk programma, elke gegevensstroom, elke externe afhankelijkheid. Toezichthouders kunnen hem direct bevragen.

Ten tweede zijn gemigreerde componenten die op cloudinfrastructuur draaien inherent eenvoudiger op weerbaarheid te testen. U kunt testomgevingen on-demand optuigen, chaos-engineering-scenario's uitvoeren en herstelprocedures valideren zonder de productie te beïnvloeden. Wij hebben instellingen de knowledge graph zien gebruiken als bewijs bij regelgevende onderzoeken om aan te tonen dat ze hun technologielandschap begrijpen, zelfs voordat de migratie voltooid is.

Technisch onderzoek

De methodologie achter deze oplossingspagina is gegrond in ons gepubliceerde onderzoek naar legacy-modernisering en knowledge-graph-architecturen.

De architectuur van begrip: voorbij syntax in modernisering van enterprise-legacy

Hoe repository-bewuste knowledge graphs en GraphRAG het "Lost in the Middle"-syndroom overwinnen dat AI-codevertaling op enterprise-COBOL-systemen doet falen.

Uw mainframe kost $1.000-$2.000 per MIPS per jaar. Wij kunnen exact in kaart brengen welke MIPS u als eerste moet elimineren.

Een MIPS-reductie van 20-30% in jaar 1 bespaart een mid-tier-instelling doorgaans $500K-$2M per jaar.

De knowledge-graph-beoordeling duurt 4-6 weken. U krijgt een volledige afhankelijkheidskaart van uw codebase, een rapport van dode code en een gerangschikte extractievolgorde, of u nu met de migratie doorgaat of niet. De beoordeling zelf is een blijvend bezit.

Beoordeling van de codebase

  • ✓ Prototype van de knowledge graph van uw COBOL-landschap
  • ✓ Identificatie van dode code (typisch 20-30% van de LOC)
  • ✓ Analyse van MIPS-verbruik per programma
  • ✓ Gerangschikte extractievolgorde van modules met koppelingsscores

Volledige migratieopdracht

  • ✓ Volledige knowledge graph met JCL/DB2/CICS-dekking
  • ✓ Incrementele migratie via het strangler-fig-patroon
  • ✓ Testen van gedragsequivalentie per module
  • ✓ Regelgevende documentatie en audittrail