Migrazione Da COBOL a C#: Guida UK 2026

COBOL è ancora alla base di una quantità enorme del software che gira nelle banche britanniche, nelle compagnie assicurative, negli enti del settore pubblico e nei grandi rivenditori. Gran parte di questo software elabora denaro, e gran parte funziona da molto prima che gli sviluppatori che oggi lo mantengono entrassero in azienda. Man mano che le competenze COBOL vanno in pensione, la pressione a modernizzare cresce di anno in anno, e una migrazione da COBOL a C# è una delle strade che le organizzazioni britanniche prendono in considerazione più spesso.

Per le organizzazioni già investite nello stack Microsoft, C# su .NET è uno dei più solidi obiettivi di migrazione disponibili. È un linguaggio moderno, tipizzato staticamente e orientato agli oggetti, gira in modo multipiattaforma su .NET 8 e versioni successive e possiede una caratteristica che lo rende particolarmente adatto a COBOL: un tipo decimal nativo, pensato per l’aritmetica finanziaria esatta.

Questa guida spiega cosa comporta davvero una migrazione da COBOL a C#, gli approcci a disposizione delle aziende britanniche, quanto costa e come gestire il rischio.

TL;DR

• C# è l’obiettivo di migrazione COBOL più adatto per le organizzazioni già su .NET o Azure, e il suo tipo decimal nativo a 128 bit mappa direttamente i campi packed-decimal COBOL senza librerie di terze parti
• I tre approcci principali (conversione automatizzata, riscrittura in parallelo e migrazione incrementale “strangler fig”) comportano profili di rischio e costo diversi; la maggior parte delle aziende britanniche adotta un ibrido
• Una migrazione di medie dimensioni costa in genere da 200.000 £ a 800.000 £ e richiede da uno a due anni; sottovalutare la portata è la modalità di fallimento più comune
• Gli strumenti di conversione automatizzata producono codice C# strutturalmente corretto ma non un sistema finito; il livello di accesso ai dati, il testing e la validazione di business restano lavoro manuale a prescindere dagli strumenti

Perché C# è un obiettivo solido per la migrazione da COBOL

C# non è l’unica destinazione sensata per COBOL. Python, Java, Go, C++ e Rust sono tutti validi a seconda del contesto. C# si distingue per ragioni precise:

Precisione decimal nativa. È di gran lunga l’argomento tecnico più forte a favore di C#. I campi finanziari COBOL usano il packed decimal (COMP-3) e le clausole numeriche PIC 9, che rappresentano valori esatti in base 10. Il tipo decimal integrato di C# è un tipo a 128 bit, a precisione fissa e in base 10, progettato specificamente per i calcoli finanziari e monetari. I campi decimal COBOL vi si mappano direttamente, preservando l’aritmetica esatta senza sorprese di arrotondamento e senza librerie esterne. Java può ottenere la stessa correttezza con BigDecimal, ma solo attraverso un’API a oggetti più verbosa; i linguaggi che si affidano alla virgola mobile binaria (double in Java, float64 in Go, f64 in Rust) sono poco adatti al denaro senza lavoro aggiuntivo.

L’ecosistema .NET. Molte aziende britanniche eseguono già Windows Server, SQL Server, Active Directory e Azure. Per queste organizzazioni, migrare COBOL a C# mantiene il sistema modernizzato all’interno di uno stack che i loro team già gestiscono, monitorano e mettono in sicurezza. L’accesso ai dati si mappa in modo pulito su ADO.NET, Entity Framework Core o Dapper.

Runtime moderno e multipiattaforma. Il .NET moderno non è più solo per Windows. Il codice C# 12 compila e gira su .NET 8 o versioni successive (una release Long Term Support) su Windows, Linux e macOS, e si distribuisce naturalmente come container su Azure, AWS o GCP. Migrare a C# non ti vincola più a un solo sistema operativo.

Tipizzazione statica e strumenti. La forte tipizzazione statica di C# intercetta intere categorie di errori in fase di compilazione, il che conta quando si traduce logica di business vecchia di decenni. Visual Studio, Rider e la .NET CLI offrono un supporto maturo per debugging, profiling e refactoring.

Disponibilità di sviluppatori. C# è costantemente tra i linguaggi aziendali più diffusi nel Regno Unito, quindi il bacino per assunzioni e manutenzione a lungo termine è ampio.

Capire da cosa stai migrando

I sistemi COBOL nel contesto aziendale britannico rientrano di solito in poche categorie, e il carattere della migrazione cambia con ciascuna:

Sistemi di elaborazione batch. Il classico carico di lavoro COBOL: grandi volumi di record letti da file, elaborati in sequenza e riscritti. Sono in genere i più semplici da migrare e si mappano bene su servizi in background C# e I/O in streaming.

Sistemi di elaborazione delle transazioni. Elaborazione delle transazioni online, spesso gestita da CICS o IMS su mainframe IBM. Comportano il rischio maggiore, perché i confini delle transazioni, il comportamento di rollback e la gestione delle connessioni devono essere tutti mappati con cura sugli equivalenti .NET.

Sistemi di generazione di report. La reportistica COBOL viene comunemente migrata su pipeline C# che producono formati moderni: PDF, Excel o dashboard web.

Livelli di interfaccia e middleware. I programmi COBOL che si trovano tra sistemi più datati e database diventano spesso servizi C# nell’architettura modernizzata.

I costrutti COBOL che richiedono una vera traduzione

Una migrazione sicura dipende dalla traduzione della semantica COBOL, non da una sostituzione di testo riga per riga. I costrutti che richiedono una mappatura autentica includono:

• I range PERFORM diventano chiamate a metodi C#, con paragrafi e sezioni scomposti in metodi.
• EVALUATE / WHEN si mappa su istruzioni switch di C# o sul pattern matching.
• I nomi di condizione 88-level diventano proprietà booleane o metodi di supporto.
• MOVE CORRESPONDING, REDEFINES e OCCURS richiedono una mappatura attenta su campi tipizzati, unioni di intento e array o collezioni.
• Le clausole PIC si mappano sul tipo C# appropriato: string per i valori alfanumerici, short / int / long per gli interi dimensionati e decimal per i campi packed-decimal con precisione preservata.
• Le direttive COPY e REPLACE (copybook) devono essere risolte prima o durante il parsing, compresi i copybook annidati.
• EXEC SQL (DB2), EXEC CICS e l’accesso ai file VSAM non hanno un equivalente C# immediato e sono le parti che con maggiore probabilità richiedono una riprogettazione deliberata su ADO.NET / Entity Framework Core e pattern di servizio moderni.
• La codifica EBCDIC e i layout di record a larghezza fissa necessitano di una conversione esplicita in Unicode e in modelli tipizzati.

Approcci alla migrazione

Esistono tre approcci principali, ciascuno con un diverso profilo di rischio e di costo.

1. Conversione automatizzata

Gli strumenti effettuano il parsing del COBOL e generano codice C# equivalente. Fatto bene, l’output è codice C# 12 strutturalmente corretto, con namespace, classi e mappatura decimal corretta. Fatto in modo ingenuo, produce un’unica classe imbottita di metodi statici, più difficile da mantenere del COBOL originale.

Ideale per: codebase di grandi dimensioni in cui la priorità è eliminare rapidamente la dipendenza da COBOL, seguita da un refactoring incrementale.

Rischio: nessuno strumento produce un sistema finito e pronto per la produzione. SQL incorporato, interazioni CICS e chiamate dinamiche richiedono comunque decisioni umane.

Il tool Mecanik di migrazione da COBOL a C# illustra come si presenta una buona conversione automatizzata. Esegue una pipeline di compilazione completa (lexer, parser, analizzatore semantico, generatore di codice) anziché una sostituzione di testo, scompone sezioni e paragrafi COBOL in metodi C#, mappa i campi COMP-3 su decimal nativo, risolve le direttive COPY / REPLACE inclusi i copybook annidati e produce un Migration Report che segnala ogni EXEC SQL, EXEC CICS e CALL dinamico che richiede attenzione manuale. Si occupa anche dei dettagli pratici, come l’aggiunta di prefissi agli identificatori che collidono con le parole riservate di C# e la conversione di nomi in stile ACCOUNT-RECORD in PascalCase.

2. Riscrittura in parallelo

Il sistema C# viene costruito accanto al sistema COBOL esistente. Entrambi girano sugli stessi input, e gli output vengono validati l’uno rispetto all’altro finché il sistema C# non supera i controlli, momento in cui COBOL viene dismesso.

Ideale per: sistemi mission-critical in cui la continuità non può essere messa a rischio, come pagamenti, buste paga e prestazioni sociali.

Rischio: eseguire due sistemi in parallelo raddoppia i costi operativi durante la migrazione e richiede una riconciliazione disciplinata.

3. Migrazione incrementale (Strangler Fig)

I singoli programmi COBOL vengono sostituiti uno alla volta con equivalenti C#. Il sistema diventa un ibrido e infine, col tempo, C# puro.

Ideale per: grandi sistemi COBOL monolitici in cui una riscrittura completa è impraticabile. Consente al team di apprendere e iterare mantenendo l’operatività del business.

Rischio: lo stato ibrido può protrarsi più a lungo del previsto e richiede una progettazione attenta delle interfacce tra i componenti COBOL e C#.

Per la maggior parte delle migrazioni aziendali britanniche, l’approccio strangler fig combinato con una conversione automatizzata selettiva per le sezioni ricche di boilerplate offre il miglior equilibrio tra rischio e velocità.

Costi di una migrazione da COBOL a C# nel Regno Unito

Il costo dipende fortemente dalla dimensione della codebase, dalla complessità e dall’approccio. Intervalli indicativi per i progetti aziendali britannici:

Queste cifre coprono analisi, migrazione, testing e supporto al go-live. Escludono i costi operativi correnti, la formazione e il lavoro di integrazione a valle che spesso emerge a metà progetto.

Il servizio Mecanik di migrazione da COBOL a C# è specializzato nelle migrazioni aziendali britanniche e copre valutazione, conversione, implementazione del livello di accesso ai dati con Entity Framework e test di parità degli output. Per le organizzazioni che stanno valutando più linguaggi di destinazione, la panoramica sulla migrazione COBOL espone l’intera gamma di opzioni, tra cui Python, Java, Go, C++ e Rust, e la guida alla migrazione da COBOL a Python tratta l’alternativa più popolare con la stessa profondità di questa.

Per le migrazioni in cui il COBOL gira su IBM z/OS o su infrastrutture simili, il servizio Mecanik di migrazione da mainframe legacy copre la dismissione dell’infrastruttura insieme alla migrazione del codice.

Rischi principali e come gestirli

Le migrazioni da COBOL a C# sforano o falliscono per ragioni prevedibili:

Logica di business non documentata. I sistemi COBOL portano spesso con sé 30-40 anni di regole di business incorporate nel codice senza alcuna documentazione esterna. Scoprire e documentare quella logica è la parte più dispendiosa in termini di tempo e più esposta al rischio di qualsiasi migrazione.

Dipendenze dai formati dei dati. Il packed decimal (COMP-3), la codifica EBCDIC e i layout a larghezza fissa non hanno un equivalente C# automatico. Il tipo decimal di C# risolve in modo pulito il lato aritmetico, ma ogni campo va comunque mappato e testato con dati reali prima del passaggio in produzione.

Il livello di accesso ai dati. Convertire la logica COBOL è spesso più semplice che sostituire il suo accesso ai dati. EXEC SQL su DB2 e la gestione dei file VSAM devono essere riprogettati su ADO.NET, Entity Framework Core o Dapper, e questo è di frequente la singola voce di lavoro più consistente.

Aspettative sulle prestazioni. Un job batch COBOL che elabora 10 milioni di record nell’arco di una notte fissa un’asticella che una riscrittura C# ingenua potrebbe non raggiungere. Sono necessari profiling, ottimizzazione e talvolta modifiche architetturali.

Copertura dei test di regressione. L’unico modo affidabile per dimostrare che l’output C# corrisponde a quello COBOL è un testing di regressione completo con dati reali (anonimizzati dove richiesto). Costruire quella suite di test prima dell’inizio della migrazione non è facoltativo.

Rischio di cut-over. Il passaggio a C# in produzione è il momento a più alto rischio. Un piano di cut-over dettagliato, con procedure di rollback e controlli di riconciliazione, è obbligatorio.

Punti chiave

• C# è l’obiettivo di migrazione COBOL più solido per le organizzazioni sullo stack .NET o Azure, in gran parte perché il suo tipo decimal nativo a 128 bit mappa direttamente i campi packed-decimal COBOL con precisione esatta e senza librerie esterne.
• I tre approcci principali sono conversione automatizzata, riscrittura in parallelo e migrazione incrementale; la maggior parte dei progetti aziendali britannici adotta l’approccio strangler fig con automazione selettiva.
• I costi vanno da circa 80.000 £ per i sistemi piccoli fino a programmi da diversi milioni di sterline per le dismissioni complete di mainframe.
• I rischi maggiori sono la logica di business non documentata, le dipendenze dai formati dei dati e la riprogettazione del livello di accesso ai dati. Affrontare tutti e tre prima dell’inizio della migrazione è essenziale.

Domande frequenti (FAQ)

Perché migrare da COBOL a C# anziché a Java o Python? Scegli C# quando la tua organizzazione gira sull’ecosistema .NET o su infrastruttura Windows e Azure. Il suo tipo decimal nativo è particolarmente adatto ai campi finanziari di COBOL. Java è la scelta naturale per i team sulla JVM, e Python si presta alle organizzazioni che danno priorità alla leggibilità e all’integrazione con l’IA.

Cosa rende il tipo decimal di C# migliore per la migrazione da COBOL? Il decimal di C# è un tipo a 128 bit, in base 10 e a precisione fissa, costruito per i calcoli finanziari, quindi i campi decimal COBOL COMP-3 e PIC 9 vi si mappano direttamente con aritmetica esatta e senza librerie di terze parti. I linguaggi che usano la virgola mobile binaria per i numeri richiedono lavoro aggiuntivo per replicare il comportamento decimal di COBOL.

Il codice C# migrato gira su Linux o solo su Windows? Gira su entrambi. C# 12 ha come target .NET 8 o versioni successive, che è multipiattaforma su Windows, Linux e macOS, e si distribuisce come applicazione standard o container su Azure, AWS o GCP.

La logica COBOL può essere convertita automaticamente in C#? Sì, con gli strumenti adatti. Un buon convertitore produce codice C# strutturalmente corretto con una struttura di classi appropriata e una mappatura decimal corretta, ma segnala SQL incorporato, interazioni CICS e chiamate dinamiche per il lavoro manuale invece di tirare a indovinare. Il livello di accesso ai dati e la validazione di business restano compiti umani.

Cosa succede ai formati dati COBOL come COMP-3 ed EBCDIC? I campi COMP-3 si mappano in modo pulito su decimal di C#. Il testo EBCDIC e i layout a larghezza fissa richiedono una conversione esplicita in Unicode e in modelli tipizzati, e ogni struttura andrebbe testata con dati reali prima dell’uso in produzione.

Quanto dura una migrazione da COBOL a C#? I sistemi piccoli e ben documentati richiedono da tre a nove mesi. I sistemi aziendali di medie dimensioni durano da dodici a ventiquattro mesi. I grandi programmi mainframe possono richiedere da tre a cinque anni per una dismissione completa.