La migrazione COBOL che si compilava alla perfezione — e corruppe comunque il libro mastro

Il codice era perfetto. E questo era esattamente il problema.

Un programma per bonifici bancari era stato tradotto dal COBOL a Java. Si compilava. Gli unit test passavano. Superava ogni controllo che avevamo costruito per intercettare gli errori. Poi, durante lo user-acceptance testing, la primissima transazione fece scattare il controllo di coerenza del database e tutto crollò.

L'autopsia richiese più tempo del dovuto, perché nel codice Java nulla sembrava sbagliato. Il colpevole era una variabile chiamata TRN-LIMIT. Lo strumento di traduzione l'aveva interpretata come un numero ordinario e le aveva assegnato un tipo intero standard. Ma TRN-LIMIT non era mai definita dove lo strumento stava guardando. Era dichiarata in un copybook — un file header condiviso — incluso migliaia di righe prima nella catena di esecuzione, e quel copybook portava con sé una clausola REDEFINES: un costrutto COBOL che consente di leggere la stessa cella di memoria come due tipi di dato completamente diversi a seconda di un flag impostato da tutt'altra parte. Sul mainframe, quell'indirizzo conteneva un packed decimal. Il nuovo codice Java scrisse dati binari corrotti nella colonna del database, e l'integrità referenziale del libro mastro cedette.

Il codice era sintatticamente impeccabile. Il guasto era contestuale. Lo strumento aveva mancato una dipendenza che viveva al di fuori del suo campo visivo — e nella modernizzazione del COBOL legacy, è quasi sempre così che spariscono i soldi.

I progetti di modernizzazione di solito non muoiono sul codice che vedi. Muoiono sul codice che lo strumento non poteva vedere.

Questa è la storia del perché ho smesso di credere che una traduzione migliore fosse la risposta, e di cosa abbiamo costruito in Veriprajna al suo posto.

Perché "Incolla il COBOL, ottieni Java" fa sempre una bella figura nelle demo?

Se hai partecipato a una qualsiasi riunione sulla modernizzazione dei mainframe negli ultimi due anni, hai sentito la promessa: incolla il tuo COBOL, ricevi Java. È seducente perché la demo funziona sempre. Qualcuno inserisce un ordinato programma di 200 righe, il modello restituisce Java pulito e idiomatico, e tutti nella stanza tirano un sospiro di sollievo. Finalmente.

Ci ho creduto anch'io, per un po'. Quando il mio team ci si mise per la prima volta, facemmo la cosa ovvia — provammo a rendere la traduzione migliore. Fornimmo ai modelli più contesto, li ottimizzammo per le stranezze del COBOL, misurammo la qualità dell'output. Esiste persino un modello open fine-tuned chiamato XMainframe, costruito appositamente per questo, che ottiene circa il 30% in più rispetto ai modelli di codice generici nei compiti in COBOL. Le traduzioni diventarono più pulite. Il Java diventò più leggibile.

E continuava comunque a rompersi in UAT. Ripetutamente, proprio sul tipo di dipendenza nascosta che aveva affondato quel programma di bonifici. Fu il mese in cui capii che stavamo lucidando la cosa sbagliata. La qualità della traduzione non è mai stata il collo di bottiglia. Il codice che si compila è la parte facile. La parte difficile è il codice che lo strumento non riesce a vedere.

I numeri attorno a tutto questo sono brutali e coerenti: dal 70 all'80% dei progetti di modernizzazione dei mainframe non riesce a raggiungere i propri obiettivi. Non il 70% va in ritardo — il 70% fallisce. La diagnosi consueta dà la colpa al testing sottostimato o a una migrazione dei dati caotica, e sono cause reali. Ma sotto quasi tutte c'è la stessa causa radice che avevo appena visto in diretta: gli strumenti trattano una base di codice come testo da convertire, quando in realtà è una topologia da comprendere.

Cosa non riesce a vedere "Incolla il COBOL, ottieni Java"

Una volta che inizi a cercare la cecità contestuale, la vedi ovunque. Tre schemi ci hanno mandato in crisi più spesso, e nessuno di essi è visibile nel file sorgente che un traduttore sta fissando.

Partiamo dal problema dei copybook che ho già descritto. Un singolo programma COBOL può fare riferimento a più di quaranta copybook, e quei copybook includono altri copybook, quindi la vera definizione di una variabile può trovarsi diversi livelli in profondità nella catena di inclusione. Uno strumento basato sul testo legge l'istruzione che ha davanti e ne deduce un tipo. Non ha modo di sapere che, in un campo packed-decimal, quella deduzione è silenziosamente errata.

Poi c'è l'aritmetica. Il packed decimal COMP-3 del COBOL non ha un equivalente nativo in Java. Ricorri a un double e hai appena introdotto arrotondamenti in virgola mobile in un sistema che movimenta denaro. Persino BigDecimal, lo strumento corretto, di default non corrisponde al COBOL — devi fissare esplicitamente la sua modalità di arrotondamento su HALF_EVEN per rispecchiare la clausola ROUNDED del COBOL. Sbagliala e ti ritrovi con un centesimo di scarto per transazione. Quel centesimo si accumula su milioni di transazioni finché, settimane dopo, un report di riconciliazione segnala una discrepanza che nessuno sa spiegare.

Lo schema che quasi tutti dimenticano è quello che davvero manda giù la produzione: il tuo COBOL non gira da solo. Uno scheduler — CA-7 o TWS — orchestra tra i duemila e i cinquemila job batch, con catene di dipendenze intrecciate tra loro. Il Job A scrive un dataset all'1 di notte che il Job B legge alle 2. Puoi migrare ogni riga di COBOL alla perfezione e comunque mandare a terra la banca a mezzanotte, perché nessuno ha mappato la rete dei job. Il grafo di produzione non è mai stato nel codice sorgente. Era nel JCL.

Il job che rompe la produzione alle 2 di notte non è mai quello che stavi guardando.

È questo che intendo per topologia. L'artefatto che effettivamente fa funzionare la tua azienda è una rete di relazioni — programmi, copybook, dataset, job schedulati, tabelle DB2, transazioni CICS — e il sorgente COBOL ne è soltanto un filo.

Perché ho smesso di fidarmi del traduttore e ho iniziato a disegnare la mappa

Il punto di svolta per noi fu decidere che la mappa è il prodotto.

Prima di tradurre una singola riga, costruiamo un knowledge graph dell'intera base di codice — ogni programma, ogni arco di copybook, ogni dipendenza JCL, ogni passaggio di dataset, ogni punto di contatto con DB2 — e risolviamo le relazioni transitive che i file sorgente nascondono. Quando puoi vedere che un programma ha oltre quaranta archi di copybook e che uno di essi porta un REDEFINES a due moduli di distanza, il disastro TRN-LIMIT semplicemente non accade, perché sapevi che il campo era packed decimal prima ancora di digitare un solo carattere di Java.

Voglio essere preciso sul perché questo è diverso da ciò che vende il resto del settore, perché il settore è affollato e gran parte di esso è genuinamente bravo nella parte che risolve.

watsonx Code Assistant for Z di IBM è l'incumbent più serio — un sistema agentico, con agenti di orchestrazione, architettura e codice, che gestisce il COBOL-verso-Java e persino PL/I e IMS, e analizza il consumo di CPU fin dentro i copybook. È anche un impegno da oltre 2 milioni di dollari che gira su z/OS e si appoggia al tooling ADDI di IBM, il quale ti vincola silenziosamente al mainframe durante la migrazione che dovrebbe liberartene. Non esegue test di equivalenza comportamentale, e non mappa la tua rete di job JCL.

Poi c'è il momento che ha ridisegnato l'intero mercato. Nel febbraio 2026, Anthropic ha pubblicato un playbook di modernizzazione del COBOL per Claude Code; il titolo IBM è crollato del 13,2% il giorno dell'annuncio, e a marzo è seguita una rete di partner da 100 milioni di dollari. Claude Code è eccellente nel discovery, nella documentazione e nella lettura di codice sconosciuto — genuinamente utile nelle fasi iniziali. Ma è uno strumento generico. Non ha un knowledge graph integrato per risolvere le dipendenze transitive, e non pretende di risolvere lo scheduling JCL, l'equivalenza comportamentale o gli audit trail che una banca regolamentata deve produrre.

La migration factory Azure di Microsoft punta a Java Quarkus e vincola la tua piattaforma di destinazione ad Azure. I grandi system integrator — DXC con il suo motore di conversione brevettato, TCS con MasterCraft, Infosys con Cobalt, Accenture — gestiscono ingaggi da 500.000 a oltre 5 milioni di dollari e implementano strumenti di terzi anziché costruire intelligenza sul tuo sistema; Accenture ha guidato la migrazione del core della Commonwealth Bank of Australia, costata circa 749,9 milioni di dollari e durata cinque anni. E Visual COBOL di Micro Focus, spesso presentato come punto di partenza, non è affatto modernizzazione — è rehosting. Il tuo COBOL continua a essere COBOL, solo su un nuovo runtime. Il debito tecnico e il problema della forza lavoro sono esattamente dove li avevi lasciati.

Ognuno di questi fa qualcosa di reale. Ciò che nessuno di essi fa è costruire la topologia completa delle dipendenze — JCL, CICS, DB2, copybook e tutto il resto — per prima cosa, indipendente da qualsiasi piattaforma di destinazione, e trattare quella mappa come la fondazione su cui poggia tutto il resto.

La maggior parte dei vendor ti vende un traduttore migliore. La traduzione non è mai stata la parte che falliva.

L'orologio che nessuno può fermare

Ecco la parte che trasforma tutto questo da problema ingegneristico in emergenza.

Le persone che comprendono questi sistemi se ne stanno andando. L'età media di uno sviluppatore COBOL negli Stati Uniti si aggira intorno ai 55 anni. Circa il 10% di quella forza lavoro va in pensione ogni anno, e l'85% delle università ha eliminato il COBOL dai propri programmi già negli anni '90, quindi quasi nessuno li sta rimpiazzando. Il sessanta percento delle organizzazioni ora afferma che trovare sviluppatori COBOL qualificati è la loro più grande sfida di modernizzazione — e il 58% degli sviluppatori che ancora conoscono questi stack dice di valutare di lasciare proprio a causa loro.

Mi sono trovato di fronte alla versione di questo che mi perseguita: la festa di pensionamento dell'unica persona che davvero capiva la finestra batch. Tutti sorridono, c'è una torta, e da qualche parte in fondo alla mia testa una voce dice quella conoscenza è appena uscita dalla porta e non è scritta da nessuna parte. Un knowledge graph è, tra le altre cose, un modo per catturare ciò che c'è nella testa di quella persona prima della festa — per far sopravvivere la mappa delle dipendenze alle persone che l'avevano memorizzata.

E la posta in gioco non è piccola né astratta. Circa 220 miliardi di righe di COBOL sono ancora in produzione attiva. Fa girare il 95% delle transazioni ATM e movimenta circa 3.000 miliardi di dollari al giorno. Il quarantatré percento dei sistemi bancari si basa su di esso. Il debito tecnico statunitense è stimato in 1.520 miliardi di dollari, e l'azienda media brucia circa 370 milioni di dollari all'anno in inefficienze legacy, con le società di servizi finanziari che spendono dal 70 al 75% dei loro budget IT solo per tenere in vita i vecchi sistemi. I team che portano a termine bene la migrazione riportano ritorni dal 114 al 225% e circa 25 milioni di dollari di risparmi all'anno — ma quel vantaggio esiste solo al di là di una migrazione che non è fallita. Questa è la rara modernizzazione in cui non fare nulla è l'opzione costosa.

I nuovi strumenti di IA non risolveranno semplicemente tutto questo?

È la domanda che mi viene posta più spesso, ed è legittima, soprattutto dopo che l'annuncio di Anthropic ha fatto sembrare che il problema fosse appena stato dichiarato risolto.

La mia risposta onesta: i nuovi strumenti hanno reso la fase di discovery enormemente più veloce, ed è un progresso reale — li uso. Ma il fatto che l'IA agentica diventi brava a leggere il COBOL non cambia la cosa che davvero uccide i progetti. Gartner prevede che il 40% delle applicazioni aziendali includerà agenti IA specifici per compito entro il 2026; più agenti che traducono codice più velocemente non serve a nulla se sono tutti ciechi di fronte alla stessa dipendenza JCL. La velocità sul problema sbagliato è solo un modo più rapido per arrivare all'UAT e fallire lì.

L'altra domanda che mi viene posta riguarda la regolamentazione, ed è quella che le banche di fascia media sottovalutano. Il Digital Operational Resilience Act dell'UE — DORA — è entrato in vigore a gennaio 2025 e richiede resilienza operativa e penetration test guidati dalle minacce, per superare i quali i sistemi legacy semplicemente non sono mai stati progettati. Gli esaminatori statunitensi di FFIEC e OCC trattano le infrastrutture obsolete come una lacuna di conformità attiva, e i sistemi più vecchi di dieci anni comportano una probabilità di violazione circa tre volte maggiore. Una migrazione che non è in grado di produrre un audit trail che dimostri che il nuovo sistema si comporta in modo identico al vecchio non è una modernizzazione — è una nuova passività con una sintassi migliore.

Ecco perché il test di equivalenza comportamentale conta tanto quanto la mappa. La tecnica è semplice da descrivere e difficile da fare bene: catturare input e output reali dal sistema legacy — un golden dataset — e riprodurli sul nuovo sistema finché il comportamento non coincide, caso limite per caso limite. Quei casi limite, accumulati nel corso di decenni, spesso codificano logica normativa che non esiste da nessun'altra parte — non in una specifica, non nella testa di una persona, solo nel codice in esecuzione. Ho visto questo colpire un assicuratore più duramente di una banca: la regola di tariffazione che scatta solo per un'appendice di polizza del 1998, il calcolo della riserva sinistri il cui arrotondamento nessun vivente sa spiegare ma da cui dipende ogni audit. Perdili silenziosamente e scoprirai quali contavano il giorno in cui un regolatore lo chiede.

Quale mattone togli per primo?

Una volta che hai la mappa, ti dice qualcosa che nessun traduttore può dirti: dove è sicuro iniziare.

La strategia dominante ora — a ragion veduta — è lo strangler fig: invece di una riscrittura big-bang, estrai una capacità alla volta, fai girare il vecchio e il nuovo fianco a fianco, e mantieni il sistema legacy come fallback attivo finché il nuovo pezzo non ha conquistato fiducia. Ma ogni vendor che raccomanda lo strangler fig tralascia la domanda più difficile — quale modulo strangoli per primo? Scegline uno fortemente accoppiato e hai ricreato il rischio big-bang con qualche passaggio in più.

Il knowledge graph risponde direttamente. Fa emergere i moduli a più basso accoppiamento — quelli con il minor numero di dipendenze in ingresso — così puoi estrarre un pezzo reale del sistema, dimostrare l'approccio e costruire fiducia organizzativa prima di toccare il nucleo pericoloso. La mappa non è solo un'assicurazione contro il fallimento TRN-LIMIT. È il piano di sequenziamento.

Abbiamo costruito tutto questo — il knowledge graph delle dipendenze, il sequenziamento strangler-fig, l'harness di equivalenza comportamentale, deliberatamente indipendenti da qualsiasi piattaforma di destinazione — nella practice di modernizzazione del COBOL legacy di Veriprajna, puntando dritto alle banche e agli assicuratori di fascia media che gli incumbent con soglia da 2 milioni di dollari e i SI da sette cifre considerano troppo piccoli per occuparsene.

Su cosa sono onesto

Non fingerò che la tecnologia risolva tutto, perché i fallimenti più costosi che ho visto non erano affatto tecnici.

Nessuno strumento — incluso il nostro — risolve il consenso organizzativo, ripulisce anni di dati cattivi o vince la battaglia politica di convincere duecento sviluppatori a cambiare il loro modo di lavorare. Si prevede che il mercato crescerà da circa 9 miliardi di dollari nel 2026 verso il doppio entro la fine del decennio proprio perché gran parte della spesa va allo strato umano e organizzativo, non al compilatore. E nessun parser sulla terra, open-source o commerciale, copre perfettamente ogni costrutto di IBM Enterprise COBOL — gli statement ALTER pre-1985, i REDEFINES più profondi. Chiunque ti dica il contrario ti sta vendendo la lacuna. La tecnologia è necessaria. Non è mai stata sufficiente.

Ma la parte che la tecnologia può possedere, deve possederla completamente. Il motivo per cui le migrazioni bruciano milioni e non producono nulla raramente è che qualcuno ha scritto del cattivo Java. È che hanno tradotto un sistema che non avevano mai realmente mappato — convertendo i fili di una rete mentre la rete stessa restava invisibile fino alla notte in cui si è strappata.

Disegna prima la mappa. Un sistema sopravvissuto alle persone che lo hanno scritto non perdona una dipendenza mancata, e non esiste una versione di questo lavoro che sia sicura prima di poter vedere cosa è connesso a cosa. Lo abbiamo imparato da un libro mastro mandato in rovina da un singolo campo packed-decimal di cui nessuno sapeva l'esistenza. Trova quei campi prima che siano loro a trovare te.