Perché la modernizzazione di COBOL costa più di quanto il budget ammetta di solito

La modernizzazione di COBOL raramente è solo una migrazione del codice. È un progetto di recupero della conoscenza con il software alla fine.

Questa è la parte che molti budget di modernizzazione sottovalutano. La stima presume che l'organizzazione stia sostituendo il vecchio codice con codice moderno. In realtà, il team spesso cerca di riscoprire decenni di regole di business, eccezioni operative, convenzioni sui dati, processi batch, dipendenze di reporting e conoscenza istituzionale che ora esiste principalmente all'interno del sistema legacy stesso.

Esempi recenti di modernizzazione federale mostrano entrambi i lati del problema. Nell'aprile 2026, il Dipartimento della Salute e dei Servizi Umani ha annunciato di aver sostituito un sistema di stipendi legacy basato su COBOL con una piattaforma cloud sicura, destinata a ridurre l'onere amministrativo e migliorare l'erogazione dei servizi. Nel frattempo, il GAO ha riferito nel 2025 che l'IRS aveva sospeso i programmi di modernizzazione nel marzo 2025 mentre rivalutava le priorità e sviluppava un nuovo framework di modernizzazione.

Entrambi gli esempi puntano alla stessa lezione: la modernizzazione legacy ha successo o si blocca in base a quanto bene l'organizzazione comprende cosa fa effettivamente il sistema legacy prima di provare a sostituirlo.

COBOL non è solo vecchio codice

COBOL è ancora importante perché continua a supportare sistemi importanti in banche, assicurazioni, governo, logistica, stipendi e altri ambienti ad alta intensità di transazioni. Le stime del settore citano comunemente COBOL come supporto di una grande quota di transazioni ATM e di pagamento, e IBM ha stimato che centinaia di miliardi di righe di COBOL rimangono in uso produttivo in settori principali.

Il motivo per cui questi sistemi persistono non è semplicemente la negligenza. Molti di loro sono affidabili, profondamente integrati e legati a processi critici per il business che non tollerano interruzioni casuali. Spesso gestiscono stipendi, elaborazione fiscale, benefici, sinistri, transazioni finanziarie, regole di idoneità, regolamento batch e altri flussi di lavoro in cui la correttezza è più importante della novità.

Ecco perché la modernizzazione di COBOL è diversa dalla sostituzione di un vecchio sito di marketing o dal refactoring di un'applicazione web familiare. Un team non sta solo aggiornando la tecnologia. Sta traducendo la logica istituzionale da un'era dell'informatica a un'altra.

Il vero problema è la logica di business nascosta

La parte più difficile della modernizzazione di COBOL spesso non è la sintassi. È la semantica.

Un sistema legacy può contenere regole aggiunte nel corso dei decenni: cambiamenti di politica, logica fiscale, gestione delle eccezioni, regole di idoneità, stranezze di reporting, logica di riconciliazione e condizioni una tantum create per soddisfare requisiti che potrebbero non essere documentati da nessun'altra parte.

Quelle regole non sono sempre isolate in moduli puliti. Potrebbero essere incorporate in routine di convalida, lavori batch, layout di file, processi di reporting, flussi di schermata o copybook condivisi. Una condizione che sembra un dettaglio di implementazione potrebbe in realtà rappresentare un requisito normativo, una regola contabile o un'eccezione operativa critica per la missione.

È qui che i progetti di modernizzazione diventano costosi. Se il team riscrive un comportamento che non comprende, rischia di rompere il business. Se preserva ogni comportamento ciecamente, potrebbe portare decenni di debito tecnico nel nuovo sistema. Il lavoro consiste nel decidere quali comportamenti legacy sono essenziali, quali sono accidentali e quali dovrebbero essere riprogettati.

Perché le stime software normali si sbriciolano

Una stima software tipica presume che il team comprenda i requisiti abbastanza bene da costruire. La modernizzazione di COBOL spesso inizia da un punto diverso. Il primo compito principale è scoprire i requisiti leggendo il sistema.

Quella scoperta può essere lenta perché i sistemi legacy sono solitamente accoppiati in modi che i team moderni potrebbero non aspettarsi.

Strutture dati condivise: Più programmi potrebbero dipendere dagli stessi copybook, layout di record o convenzioni di campo.
Dipendenze batch: Un processo potrebbe dipendere da file creati da lavori eseguiti ore prima in una sequenza specifica.
Codifica e formati numerici: EBCDIC, decimali impacchettati, record a lunghezza fissa e convenzioni specifiche per mainframe potrebbero richiedere una traduzione attenta.
Contratti informali: I sistemi potrebbero scambiare dati tramite file, code o lavori programmati senza il tipo di contratto API che un team moderno si aspetta.
Eccezioni non documentate: Le regole di business potrebbero esistere solo come condizioni all'interno di vecchi programmi.

Gli strumenti di analisi statica possono aiutare a identificare le dipendenze, ma non dicono automaticamente al team perché quelle dipendenze esistono o quali sono importanti per il business.

Tre driver di costo che vengono sottovalutati

1. Regole di business non documentate

I sistemi COBOL spesso contengono regole di business che sono state implementate direttamente nel codice perché era il percorso più veloce o pratico al momento. Nel corso degli anni, quelle regole si accumulano. La documentazione rimane indietro. Gli sviluppatori originali vanno in pensione. Il codice diventa la fonte di verità.

I team di modernizzazione devono estrarre quelle regole con cura. Ciò potrebbe richiedere analisi del codice, revisione dei dati di test, confronto del comportamento di produzione, interviste agli stakeholder, sessioni con esperti di dominio e riconciliazione rispetto alla politica attuale o ai requisiti operativi.

Questo non è opzionale. Perdere una regola può creare conseguenze finanziarie, di conformità o di erogazione del servizio.

2. Mappatura e trasformazione dei dati

Passare dai formati dati dell'era mainframe a database moderni, API o sistemi guidati da eventi non è un semplice esportazione. Record a lunghezza fissa, decimali impacchettati, sovraccarico di campi, codifiche legacy, problemi di qualità dei dati storici e relazioni implicite possono tutti creare rischi di migrazione.

Un modello di dati moderno impone anche decisioni. Il nuovo sistema dovrebbe preservare la vecchia struttura dei record? Dovrebbe normalizzare i dati? Dovrebbe esporre API? Le stranezze storiche dovrebbero essere mantenute per compatibilità? Come si riconcilieranno i report tra vecchi e nuovi sistemi durante la transizione?

La migrazione dei dati è spesso dove i progetti di modernizzazione scoprono che il vecchio sistema stava facendo più traduzione e pulizia di quanto chiunque si rendesse conto.

3. Convalida del comportamento

Nella modernizzazione di COBOL, testare il nuovo sistema significa dimostrare che si comporta correttamente attraverso scenari legacy, non solo che il nuovo codice passa i test unitari.

Ciò può richiedere esecuzioni parallele, confronto batch, riproduzione delle transazioni, suite di regressione, report di riconciliazione e una revisione attenta dei casi limite. Il team deve sapere se il sistema modernizzato produce lo stesso risultato dove è richiesto lo stesso risultato e un risultato deliberatamente diverso dove il comportamento legacy viene corretto o riprogettato.

La convalida può consumare tanto sforzo quanto l'implementazione perché il costo di un errore sottile può essere alto.

Dove l'IA può aiutare e dove non può

L'analisi del codice assistita dall'IA sta cambiando parti del processo di modernizzazione di COBOL. Gli strumenti possono aiutare a analizzare il sorgente COBOL, riassumere i programmi, identificare le dipendenze, generare documentazione, spiegare costrutti non familiari e proporre trasformazioni candidate.

Federal News Network ha riferito nel 2024 che l'OPM ha ricevuto il supporto del Technology Modernization Fund per un progetto di due anni che inizia nel 2025 per modernizzare il codice COBOL che supporta il suo sistema di pensionamento, incluso l'uso dell'IA per aiutare ad analizzare e trasformare l'ambiente legacy. Quel tipo di lavoro mostra dove l'IA può essere preziosa: ridurre il tempo necessario per comprendere il vecchio codice e accelerare la documentazione.

Ma l'IA non rimuove la necessità di una revisione umana del dominio.

Un modello può aiutare a spiegare cosa una sezione di COBOL sembra fare. Non può garantire che il comportamento sia ancora legalmente richiesto, operativamente necessario o sicuro da cambiare. Può suggerire un equivalente moderno. Non può assumersi la responsabilità delle conseguenze se la migrazione cambia come vengono elaborati benefici, stipendi, tasse, sinistri o transazioni finanziarie.

L'IA è meglio trattata come un acceleratore per la scoperta e la documentazione, non come un sostituto dell'esperienza di dominio, del giudizio architetturale o della convalida.

Cosa funziona davvero

La modernizzazione di COBOL funziona meglio quando i team la trattano come recupero incrementale della conoscenza e riduzione del rischio.

Inizia con la scoperta del sistema: Inventario programmi, file, lavori, integrazioni, strutture dati, report, utenti e processi di business prima di impegnarsi in un percorso di migrazione.
Recupera le regole di business: Estrai e documenta le regole dal codice, lavori batch, layout dei dati e comportamento di produzione. Validale con esperti di dominio ovunque possibile.
Costruisci una mappa del comportamento: Comprendi cosa fa il sistema, non solo come è organizzato il codice.
Modernizza in modo incrementale: Usa pattern come strangler fig, wrapping API, estrazione di servizi o sostituzione modulare a fasi invece di scommettere tutto su una riscrittura big-bang.
Convalida continuamente: Confronta gli output tra vecchi e nuovi sistemi attraverso scenari realistici, casi limite, cicli batch e dati storici.
Decommissiona deliberatamente: Mantieni il sistema legacy disponibile fino a quando la sostituzione non è stata convalidata e il rischio operativo è abbastanza basso da ritirare il vecchio percorso.

L'approccio è più lento di quanto vorrebbe una presentazione. È anche più sicuro che scoprire dopo il lancio che il team ha sostituito il codice senza preservare il comportamento essenziale.

Il budget che ha più senso

Un budget realistico per la modernizzazione di COBOL non dovrebbe trattare la scoperta come un piccolo compito preliminare. La scoperta è una fase principale del lavoro.

Una struttura più onesta di solito è simile a questa:

Fase uno: scoperta e documentazione. Recupera la mappa del sistema, le regole di business, le strutture dati, le dipendenze batch, i punti di integrazione e i rischi di modernizzazione. L'analisi assistita dall'IA può aiutare qui, ma la convalida umana rimane essenziale.
Fase due: migrazione incrementale. Sposta la funzionalità a fette, partendo da aree a basso rischio o ad alto valore dove il team può dimostrare l'approccio prima di espandersi.
Fase tre: convalida e decommissioning. Esegui confronti, riconcilia gli output, conferma la prontezza operativa, addestra gli utenti, ritira con cura i componenti legacy e preserva le prove di audit.

Se un piano di modernizzazione dedica alla scoperta solo poche settimane e presume che l'implementazione sarà semplice, il piano probabilmente trasporta un rischio nascosto. L'organizzazione potrebbe non essere in budget per il problema reale.

Come Ridiculous Engineering pensa alla modernizzazione legacy

In Ridiculous Engineering, affrontiamo la modernizzazione legacy come un problema di conoscenza di dominio e architettura prima di trattarla come un problema di conversione del codice.

Questo è importante perché il sistema legacy spesso sa cose che l'organizzazione ha dimenticato. Regole di business, logica di conformità, flussi di lavoro, report e percorsi di eccezione potrebbero esistere solo nel sistema in esecuzione. Prima di scegliere una piattaforma di sostituzione o riscrivere il codice, il team deve comprendere cosa deve essere preservato, cosa dovrebbe cambiare e cosa può essere ritirato.

Aiutiamo le organizzazioni a strutturare il lavoro di modernizzazione attorno a quella realtà. Ciò può includere valutazione dello stato attuale, inventario del sistema, scoperta delle regole di business, mappatura dei flussi di dati, pianificazione dell'architettura, strategia API, progettazione della migrazione incrementale, pianificazione dei test, documentazione e supporto all'implementazione.

Per COBOL e altri sistemi a lunga vita, l'obiettivo non è il teatro della modernizzazione. L'obiettivo è ridurre il rischio operativo preservando il comportamento di business che è ancora importante.

Budget per l'archeologia

La modernizzazione di COBOL costa più del previsto quando le organizzazioni budgettano per cambiamenti di codice e ignorano il recupero della conoscenza.

Il codice è vecchio, ma il vero rischio non è l'età di per sé. Il vero rischio è sostituire un sistema critico per la missione senza comprendere la logica di business incorporata al suo interno.

Se la tua organizzazione sta valutando la modernizzazione di COBOL, la sostituzione di sistemi legacy o l'analisi del codice assistita dall'IA, Ridiculous Engineering può aiutarti a pianificare il lavoro in modo realistico. Possiamo aiutare a valutare cosa hai, recuperare le regole che contano, progettare un approccio di migrazione e costruire un percorso che riduca il rischio invece di fingere che il vecchio sistema sia più semplice di quanto sia.

La modernizzazione non è solo tradurre il codice. È tradurre decenni di realtà di business in sistemi che l'organizzazione può mantenere, operare e fidarsi.

Fonti e letture aggiuntive: HHS: HHS sostituisce il sistema di stipendi legacy, GAO: IRS sta sviluppando un nuovo framework di modernizzazione, Rapporto GAO: framework di modernizzazione IRS, Federal News Network: premio TMF per aiutare OPM a modernizzare il codice COBOL tramite IA, FedTech: Il dilemma COBOL del governo’, Forbes India: COBOL, IBM e rischio di sistemi legacy

Perché il tuo progetto di modernizzazione COBOL costerà 3 volte il budget previsto (e come risolverlo)