Modernizzazione dei Mainframe Legacy
Il 70-80% dei progetti di modernizzazione dei mainframe fallisce. Non perché la tecnologia sia sbagliata, ma perché gli strumenti trattano il codice come testo anziché come topologia. Costruiamo la mappa del tuo codebase prima di toccare una sola riga, così la tua migrazione riesce dove altri hanno bruciato milioni senza ottenere nulla.
1,52 trilioni di dollari
Debito Tecnico negli USA
Pragmatic Coders, 2025
10%/anno
Attrito della Forza Lavoro COBOL
IEEE Spectrum, 2025
70-80%
Tasso di Fallimento della Modernizzazione
Meta-Analisi di Settore, 2025
Gli strumenti che promettono "incolla il COBOL, ottieni Java" producono codice che compila. Questa è la parte facile. La parte difficile è il codice che non riescono a vedere.
Considera un programma per l'elaborazione dei bonifici. Contiene un'istruzione COMPUTE che utilizza una variabile chiamata TRN-LIMIT. Un assistente di codifica IA traduce l'istruzione in un'operazione Java BigDecimal . Il codice compila. Gli unit test passano.
In UAT, la prima transazione manda in crash il controllo di coerenza del database.
L'autopsia: TRN-LIMIT non era definita nel file sorgente che l'IA ha tradotto. Era definita in un copybook incluso migliaia di righe prima nella catena di esecuzione. Quel copybook conteneva una clausola REDEFINES , un costrutto COBOL che consente di interpretare lo stesso indirizzo di memoria come due diversi tipi di dato a seconda di un flag impostato in un modulo completamente diverso.
L'IA ha visto TRN-LIMIT come un semplice campo numerico e ha assunto un tipo intero standard. Sul mainframe, quell'indirizzo di memoria conteneva un decimale impacchettato (COMP-3). L'applicazione Java ha scritto dati binari corrotti nella colonna del database, innescando una violazione dell'integrità referenziale.
Il codice era sintatticamente perfetto. Il fallimento era cecità contestuale. L'IA ha mancato una dipendenza che esisteva al di fuori del suo campo visivo.
Un singolo programma COBOL può fare riferimento a oltre 40 copybook. Ogni copybook può fare COPY di altri copybook. Le definizioni delle variabili possono trovarsi a 5 livelli di profondità nella catena di inclusione. Gli strumenti IA basati su testo non vedono nulla di tutto ciò.
Il tuo COBOL non gira in modo autonomo. CA-7 o TWS schedulano 2.000-5.000 job JCL con catene di dipendenze. Il Job A scrive un dataset che il Job B legge alle 2 del mattino. Migra il COBOL ma trascura il JCL, e la produzione si rompe a mezzanotte.
Il decimale impacchettato COMP-3 del COBOL non ha equivalente in Java. Un double Java introduce errori di arrotondamento in virgola mobile. Persino BigDecimal richiede la configurazione esplicita della modalità di arrotondamento (HALF_EVEN) per corrispondere alla clausola ROUNDED del COBOL. Un solo centesimo sbagliato si accumula su milioni di transazioni.
Ogni grande fornitore di tecnologia vende ora la modernizzazione dei mainframe. Ecco cosa offre effettivamente ciascuno e dove permangono le lacune.
| Fornitore / Approccio | Cosa Fa | Costo Tipico | Cosa Tralascia |
|---|---|---|---|
| IBM Watsonx Code Assistant for Z | Traduzione agentica da COBOL a Java con analisi delle dipendenze ADDI. Architettura multi-agente (agenti Orchestrate, Architect, Code). Supporta PL/I e IMS. | Oltre 2 milioni di dollari (licenze enterprise + requisito z/OS) | ADDI gira su z/OS, creando vendor lock-in durante la migrazione. Il parser fatica con i costrutti COBOL pre-85 (istruzioni ALTER). Nessun test di equivalenza comportamentale. Nessuna mappatura delle dipendenze JCL. |
| Anthropic Claude Code | Analisi del codice basata su IA, documentazione, mappatura delle dipendenze. Forte nelle fasi di scoperta ed esplorazione. Supporta la migrazione incrementale e il wrapping delle API. | Prezzi API basati sull'utilizzo | IA generica. Nessun knowledge graph integrato per la risoluzione delle dipendenze transitive. Non affronta la schedulazione JCL, i test di equivalenza comportamentale o le tracce di audit regolatorie. |
| Microsoft Azure Migration Factory | Agenti agentici modulari tramite Semantic Kernel. Agenti COBOL Expert + Java Expert. Punta a Java Quarkus. Agente di migrazione Azure Copilot in anteprima. | Consumo Azure + consulenza | Lock-in Azure per la piattaforma di destinazione. Gli agenti open-source sono implementazioni di riferimento, non pronte per la produzione in ambienti regolamentati. Supporto CICS/IMS limitato. |
| DXC Technology | Conversione automatica brevettata del codice (da COBOL/RPG/JCL a Java). Decenni di esperienza sui mainframe. Modelli cloud ibrido + mainframe-as-a-service. | 1-10+ milioni di dollari | Strumenti proprietari, trasparenza limitata sulla logica di conversione. Focus sulle grandi imprese. Sono comuni tempistiche di ingaggio di 18-36 mesi. |
| TCS / Infosys / Accenture | Practice di grandi system integrator con framework proprietari (MasterCraft, Cobalt). Team di delivery enormi. Gestione del programma end-to-end. | 500K-5+ milioni di dollari | Approccio incentrato sulla piattaforma. Implementano strumenti di fornitori, non costruiscono intelligenza su misura. Overhead del modello di ingaggio dei grandi SI. Un SI ha guidato la migrazione di una banca da 1 miliardo di dollari australiani che ha richiesto 5 anni e ha raddoppiato il budget. |
| Micro Focus (OpenText) Visual COBOL | Esegui il COBOL nativamente su .NET/JVM. Punto di partenza pragmatico in stile "strangler fig". Leader di mercato nei compilatori COBOL. | 200K-500K dollari di licenze | Non è modernizzazione, è rehosting. La logica COBOL resta COBOL. Il debito tecnico persiste. Non risolve il problema della forza lavoro. |
| Fai-da-te con IA open-source | LLM XMainframe (7B/10.5B parametri, 30% migliore di DeepSeek sul COBOL). Parsing Tree-sitter. Pipeline personalizzate. | Tempo di ingegneria + infrastruttura | Richiede una profonda competenza in COBOL + graph engineering. Nessun parser COBOL di livello produttivo copre tutti i costrutti di IBM Enterprise COBOL v6.x. Alto rischio di incorporare lacune del parser nelle fondamenta. |
Cinque capacità, ciascuna mirata a una specifica lacuna nella toolchain di modernizzazione. Siamo neutrali rispetto ai fornitori: il knowledge graph funziona indipendentemente dal fatto che il tuo target sia AWS, Azure, GCP o Java on-premise.
Acquisiamo il tuo sorgente COBOL, i copybook, le librerie JCL, gli export del catalogo DB2, le definizioni delle transazioni CICS e le gerarchie dei segmenti IMS in un database a grafo unificato. Ogni variabile, ogni catena PERFORM, ogni clausola REDEFINES, ogni dipendenza batch diventa un arco esplicito del grafo. Optiamo per Neo4j quando query complesse di chiusura transitiva dominano il caso d'uso, per Memgraph quando la velocità di traversata in tempo reale è importante per l'esplorazione interattiva.
Il grafo elabora circa 200K-300K righe al giorno durante l'acquisizione. Per un codebase da 2 milioni di LOC, prevedi 8-12 settimane dalla prima acquisizione a un grafo validato e interrogabile. L'output è un asset permanente: il tuo codebase come topologia ricercabile, non file di testo opachi.
Prima che inizi qualsiasi traduzione del codice, eseguiamo un'analisi del grafo lungo quattro dimensioni: punteggio di accoppiamento (quanti altri moduli dipendono da questo), densità di REDEFINES/COMP-3 (quante trappole di tipo di dato esistono), percentuale di codice morto (tipicamente il 20-30% del codebase) e criticità della schedulazione batch (quali job JCL toccano questo modulo e quando).
L'output è una sequenza di estrazione classificata per la migrazione strangler fig. I moduli con l'accoppiamento più basso e i tipi di dato più semplici vengono estratti per primi. I "programmi divinità" richiamati da oltre 50 altri moduli vengono estratti per ultimi. Questo sequenziamento è la differenza tra un rilascio controllato e un fallimento a cascata.
I nostri agenti di traduzione interrogano il knowledge graph prima di generare ciascun modulo Java, recuperando l'intera chiusura transitiva delle dipendenze. L'agente vede la clausola REDEFINES nel copybook tre directory più in là. Vede la definizione del decimale impacchettato che determina il comportamento dell'arrotondamento. Genera Java con passaggio esplicito dei parametri (dependency injection) invece dello stato globale implicito del COBOL. Poi compila in una sandbox, esegue test di equivalenza comportamentale e si autocorregge.
Usiamo il foundation model più adatto alla complessità del modulo. Per le semplici conversioni da PERFORM a metodo, un modello più piccolo funziona benissimo. Per i moduli con REDEFINES annidate, spaghetti di GOTO che richiedono l'appiattimento del flusso di controllo o logica transazionale incorporata EXEC CICS, ricorriamo al modello più capace disponibile e lo potenziamo con il contesto completo del grafo.
La parte che la maggior parte dei fornitori salta e su cui la maggior parte delle migrazioni fallisce. Costruiamo un sistema di validazione a tre livelli: unit test simbolici generati da percorsi di flusso di controllo derivati dal grafo, replay di golden dataset utilizzando transazioni di produzione catturate e confrontate campo per campo con accuratezza al centesimo, ed esecuzioni in parallelo in produzione in cui entrambi i sistemi elaborano transazioni live per 30-90 giorni prima che il modulo mainframe venga dismesso.
I calcoli finanziari richiedono BigDecimal con modalità di arrotondamento HALF_EVEN per corrispondere alla clausola ROUNDED del COBOL. I calcoli sulle date richiedono la gestione del formato data a 6 cifre del COBOL (YYMMDD) con logica di century windowing. Incorporiamo queste regole di conversione nell'harness di test, non in patch ad-hoc scoperte durante il QA.
Analizziamo le tue reti di job JCL, le catene di dipendenze CA-7/TWS/Control-M e le sequenze di elaborazione batch, inserendole nel knowledge graph. Ogni job JCL diventa un nodo con archi verso i programmi COBOL che esegue, i dataset che legge e scrive e le condizioni di schedulazione da cui dipende (trigger temporali, disponibilità dei dataset, completamento dei predecessori).
Quando un modulo COBOL viene migrato a Java, costruiamo contemporaneamente la schedulazione equivalente nella tua piattaforma di orchestrazione di destinazione (Apache Airflow, AWS Step Functions, Azure Data Factory o Control-M su distribuito). La catena di dipendenze viene preservata e verificata rispetto alla definizione originale CA-7/TWS. Una tipica banca di fascia media ha 2.000-5.000 job JCL. Li abbiamo visti tutti.
Una guida passo passo su come la risoluzione delle dipendenze basata sul grafo previene lo schema di fallimento della migrazione più comune.
Il parser elabora PROG-WIRE-01.cbl, incontra COPY CB-ACCT-LIMITSe segue la catena di inclusione. Costruisce nodi AST per ogni dichiarazione di variabile, comprese quelle nei copybook annidati a 3 livelli di profondità.
Il motore del grafo crea archi: PROG-WIRE-01 → IMPORTS → CB-ACCT-LIMITS. TRN-LIMIT → REDEFINES → TRN-LIMIT-ALPHA. LIMIT-TYPE-FLAG → CONTROLS_TYPE_OF → TRN-LIMIT. Questo cattura il fatto che il tipo di dato di TRN-LIMIT dipende da un flag a runtime in un campo diverso.
Il grafo si estende verso l'esterno: quali altri programmi fanno anch'essi COPY di CB-ACCT-LIMITS? Quali programmi impostano LIMIT-TYPE-FLAG? Quali job JCL eseguono quei programmi, e in quale sequenza? Il risultato è una catena di impatto completa. Cambiare il modo in cui TRN-LIMIT viene tradotto influisce su ogni programma in questa catena.
Quando l'agente di traduzione elabora PROG-WIRE-01, GraphRAG recupera non solo il file sorgente ma anche la definizione del copybook, la relazione REDEFINES, il campo flag e tutti i programmi che impostano il flag. L'agente genera una classe Java con uno schema di union type-safe: un oggetto TransactionLimit che controlla il flag prima di interpretare i byte sottostanti come un BigDecimal (modalità decimale impacchettato) o una String (modalità alfanumerica).
Senza il grafo: l'IA assume che TRN-LIMIT sia un semplice campo numerico, genera un long in Java, e il primo bonifico corrompe il database. Con il grafo: l'IA vede l'intera catena di dipendenze e genera codice type-safe che gestisce correttamente entrambe le interpretazioni. Questa è la differenza tra una migrazione che funziona in UAT e una che funziona in produzione.
Quattro fasi, ciascuna con deliverable chiari. Non preventiviamo una tempistica di 3 anni per poi sparire. Ogni fase produce artefatti che possiedi e puoi utilizzare in modo indipendente.
Deliverable: Report di Valutazione + prototipo preliminare di knowledge graph
Deliverable: Knowledge graph interrogabile + sequenza di estrazione classificata + strumento di analisi d'impatto
Deliverable: Moduli Java migrati in produzione + knowledge graph aggiornato + equivalenti di schedulazione
Deliverable: Deployment in produzione validato + pacchetto di documentazione regolatoria + grafo aggiornato
Rispondi a sette domande sul tuo ambiente. La valutazione identifica il tuo livello di prontezza e i blocchi specifici da affrontare prima di avviare un ingaggio di migrazione, con o senza Veriprajna.
Per un codebase da 2M LOC con complessità tipica (IBM Enterprise COBOL v6.x, SQL incorporato DB2, oltre 500 copybook), la costruzione del grafo richiede da 8 a 12 settimane. Le prime 3 settimane sono dedicate alla configurazione e alla validazione del parser. I dialetti COBOL variano abbastanza da richiedere la verifica che il parser gestisca il tuo uso specifico di REDEFINES, OCCURS DEPENDING ON e blocchi EXEC CICS/SQL prima di acquisire l'intero codebase.
Dalla settimana 4 alla 8 si svolgono l'acquisizione automatizzata, l'estrazione delle entità e la mappatura delle relazioni. Il parser elabora circa 200K-300K righe al giorno, ma il collo di bottiglia è la risoluzione delle entità, in particolare determinare che ACCT-NUM nel Programma A e ACCT-NUM nel Copybook CB-ACCT-01 sono la stessa variabile.
Dalla settimana 9 alla 12 si svolgono il calcolo della chiusura transitiva e la validazione. Eseguiamo controlli di completezza del grafo: ogni target PERFORM deve risolversi in un paragrafo, ogni istruzione COPY deve risolversi in un copybook, ogni riferimento a tabella DB2 deve mappare a una definizione di schema. Le lacune vengono segnalate per revisione manuale. L'output è un knowledge graph interrogabile in cui puoi porre domande come "Cosa succede se cambio INTEREST-RATE in CB-GLOBAL-01?" e ottenere una catena di impatto completa su ogni programma che vi fa riferimento, direttamente o transitivamente.
Sì, e lo raccomandiamo vivamente. Lo schema strangler fig è l'unico approccio con un comprovato track record per la migrazione dei mainframe. Le riscritture complete falliscono nel 70-80% dei casi perché tentano di sostituire tutto simultaneamente, creando un unico, enorme punto di fallimento.
Con l'approccio strangler fig, il knowledge graph identifica quali moduli hanno i punteggi di accoppiamento più bassi, ovvero il minor numero di dipendenze in entrata da altri moduli. Questi sono i tuoi candidati all'estrazione. Tipicamente iniziamo con moduli di reporting batch o routine di calcolo autonome che leggono da DB2 ma non aggiornano lo stato condiviso. Il nuovo servizio Java gira affiancato al mainframe. Il traffico di produzione viene instradato verso il nuovo servizio per quella specifica funzione mentre il mainframe continua a gestire tutto il resto. Validi l'equivalenza comportamentale su dati di produzione reali prima di dismettere il modulo COBOL.
La maggior parte delle organizzazioni estrae da 15 a 20 moduli nel primo anno, riducendo il consumo di MIPS del 20-30% e generando risparmi sui costi sufficienti a finanziare la fase successiva. Il knowledge graph rende tutto questo sicuro perché ti mostra il raggio d'azione di ciascuna estrazione. Se il Modulo A è richiamato da altri 47 programmi, non è il tuo primo candidato all'estrazione. Se il Modulo B è richiamato da 2 programmi e legge da 1 tabella DB2, parti da lì.
Questo è il livello in cui la maggior parte dei progetti di modernizzazione incontra fallimenti inaspettati dopo 6-12 mesi. I tuoi programmi COBOL non girano in isolamento. Sono orchestrati da flussi di job JCL gestiti da CA-7, TWS (Tivoli Workload Scheduler) o Control-M. Una tipica banca di fascia media ha da 2.000 a 5.000 job JCL con catene di dipendenze complesse: il Job A deve completarsi prima che il Job B inizi, il Job C gira solo nell'ultimo giorno lavorativo del mese, il Job D innesca una transazione CICS che aggiorna un file VSAM letto dal Job E.
Analizziamo il JCL insieme al COBOL nello stesso knowledge graph. Ogni job JCL diventa un nodo con archi verso i programmi COBOL che esegue, i dataset che legge e scrive e le condizioni di schedulazione da cui dipende. Quando migriamo un modulo COBOL a Java, costruiamo contemporaneamente la schedulazione equivalente nella tua piattaforma di destinazione, che sia Apache Airflow, AWS Step Functions o Azure Data Factory. La catena di dipendenze viene preservata e verificata rispetto all'originale.
Abbiamo visto progetti in cui la migrazione del codice è riuscita perfettamente ma la produzione si è rotta perché nessuno aveva mappato il job CA-7 che eseguiva un passo di pre-elaborazione ogni notte alle 2 del mattino.
IBM Watsonx Code Assistant for Z (attualmente v2.8.20, con Project Bob in arrivo più avanti nel 2026) è un prodotto solido con una profonda integrazione mainframe. Richiede IBM ADDI (Application Discovery and Delivery Intelligence) per costruire la sua analisi delle dipendenze, e ADDI gira su z/OS. Questo significa che il tuo strumento di analisi delle dipendenze risiede sullo stesso mainframe da cui stai cercando di migrare. Significa anche che IBM controlla il livello di analisi, il che crea vendor lock-in durante la fase più critica della migrazione.
Il nostro knowledge graph gira al di fuori del mainframe. Acquisiamo export del codice sorgente, librerie JCL, export del catalogo DB2 e repository di copybook. Il grafo risiede nel tuo ambiente cloud o nell'infrastruttura on-premise, indipendente dalle licenze IBM. In secondo luogo, Watsonx si concentra sulla traduzione da COBOL a Java. Noi ci concentriamo prima sulla comprensione, poi sulla traduzione. Il knowledge graph è un asset permanente che serve l'analisi d'impatto, la generazione di documentazione e la governance architetturale molto tempo dopo il completamento della migrazione.
In terzo luogo, il parser COBOL di ADDI presenta limitazioni documentate con i costrutti COBOL pre-85, in particolare le istruzioni ALTER e certi schemi di REDEFINES annidate. Costruiamo estensioni del parser personalizzate per il dialetto di ciascun cliente.
Infine, il pricing di IBM è rivolto alle grandi imprese. Il nostro modello di ingaggio funziona per le istituzioni di fascia media dove un ingaggio IBM da oltre 2 milioni di dollari non rientra nel budget.
L'equivalenza comportamentale è il punto in cui la maggior parte delle migrazioni assistite dall'IA va in pezzi. Il codice che compila e supera gli unit test può comunque produrre risultati errati a causa di differenze di arrotondamento dei decimali impacchettati, disallineamenti di codifica da EBCDIC ad ASCII o semantiche di sovrapposizione di memoria REDEFINES che non si traducono in oggetti Java.
Costruiamo un harness di validazione a tre livelli. Il Livello 1 è l'equivalenza simbolica: generiamo unit test dal knowledge graph che coprono ogni ramo del flusso di controllo COBOL originale, compresi casi limite come importi negativi, protezioni dalla divisione per zero e calcoli di date per anni bisestili. Il Livello 2 è il replay del golden dataset: catturiamo un insieme rappresentativo di transazioni di produzione dal mainframe (record di input, letture DB2, interazioni CICS) e le rieseguiamo attraverso il nuovo servizio Java. Gli output vengono confrontati campo per campo. Per i calcoli finanziari, verifichiamo l'accuratezza al centesimo utilizzando BigDecimal con arrotondamento HALF_EVEN per corrispondere al comportamento della clausola ROUNDED del COBOL.
Il Livello 3 è l'esecuzione in parallelo in produzione: entrambi i sistemi elaborano le stesse transazioni live simultaneamente per 30-90 giorni. Le discrepanze vengono registrate, indagate e corrette prima che il modulo mainframe venga dismesso. Questa è la fase più lunga, ma è anche la fase che cattura i casi limite accumulati in 30 anni di produzione che nessuna suite di test può anticipare completamente.
Il DORA (Digital Operational Resilience Act) è pienamente in vigore dal 17 gennaio 2025 e impatta direttamente qualsiasi entità finanziaria regolamentata dall'UE che opera sistemi mainframe. L'articolo 11 richiede framework di gestione del rischio ICT che includano test di resilienza regolari e penetration test guidati dalle minacce basati su scenari di attacco reali. La maggior parte degli ambienti mainframe non è stata progettata per questo tipo di test. Non puoi facilmente avviare un ambiente z/OS replica per eseguire penetration test senza significativi costi di licenza e infrastruttura.
Il DORA richiede inoltre inventari dettagliati degli asset ICT, la segnalazione degli incidenti entro tempistiche specifiche e la gestione del rischio di terze parti per i fornitori critici di servizi ICT, il che include il tuo fornitore mainframe. La modernizzazione aiuta in due modi. Primo, il knowledge graph stesso funge da inventario degli asset ICT richiesto dal DORA. Mappa ogni programma, ogni flusso di dati, ogni dipendenza esterna. Le autorità di vigilanza possono interrogarlo direttamente.
Secondo, i componenti migrati che girano su infrastruttura cloud sono intrinsecamente più facili da testare per la resilienza. Puoi avviare ambienti di test su richiesta, eseguire scenari di chaos engineering e validare le procedure di ripristino senza impattare la produzione. Abbiamo visto istituzioni utilizzare il knowledge graph come prova negli esami regolatori per dimostrare di comprendere il proprio patrimonio tecnologico, anche prima che la migrazione sia completata.
La metodologia alla base di questa pagina di soluzione è radicata nella nostra ricerca pubblicata sulla modernizzazione dei sistemi legacy e sulle architetture dei knowledge graph.
Come i knowledge graph repository-aware e GraphRAG superano la sindrome "Lost in the Middle" che fa fallire la traduzione del codice tramite IA sui sistemi COBOL enterprise.
Una riduzione dei MIPS del 20-30% nel Primo Anno fa risparmiare tipicamente 500K-2M di dollari all'anno per un'istituzione di fascia media.
La valutazione del knowledge graph richiede 4-6 settimane. Ottieni una mappa completa delle dipendenze del tuo codebase, un report del codice morto e una sequenza di estrazione classificata, che tu proceda con la migrazione o meno. La valutazione stessa è un asset permanente.