Il rischio non è che il COBOL smetta di funzionare domani. È trasformare codice stabile senza conoscere tutte le regole di business che contiene, spostando il debito tecnico da un mainframe a una nuova piattaforma. L’AI accelera l’analisi e la conversione, ma non decide quale strategia riduca davvero il rischio: refactor automatizzato oppure migrazione incrementale per domini.

Il criterio di confronto è operativo: quanto ciascun approccio conserva il comportamento esistente, quanto cambia l’architettura, come gestisce i test e quando produce valore utilizzabile. La scelta riguarda grandi sistemi COBOL, ma il principio vale anche per una PMI con un gestionale storico, un portale WordPress molto personalizzato o automazioni cresciute senza documentazione.

Approccio A: refactor assistito dall’AI

Nel refactor automatizzato, strumenti specializzati analizzano COBOL, JCL, transazioni e dipendenze, poi convertono il codice verso uno stack moderno. AWS descrive il proprio percorso come una trasformazione verso Java che punta a mantenere l’equivalenza funzionale; IBM include analisi, spiegazione, refactor, trasformazione COBOL-Java e validazione semantica nel flusso di watsonx Code Assistant for Z.

Il vantaggio è la velocità industriale. Inventario, documentazione, classificazione delle dipendenze e una parte della generazione dei test possono essere automatizzati. Se l’applicazione soddisfa ancora il business e il problema principale è il rischio di competenze, il costo operativo o l’uscita da una tecnologia legacy, conservare il comportamento è una scelta sensata.

Il limite è altrettanto concreto: convertire il linguaggio non equivale a correggere l’architettura. AWS distingue esplicitamente il refactor, che conserva l’impianto monolitico, dal “reimagine”, che estrae regole e domini per costruire nuovi servizi. Un monolite tradotto bene resta un monolite. Cambiano runtime e strumenti, ma accoppiamenti, flussi batch e confini sbagliati possono sopravvivere.

Approccio B: migrazione incrementale

La migrazione incrementale parte da un’altra domanda: quale capacità di business conviene separare per prima? Un layer di API o integrazione espone le funzioni legacy a nuovi consumer; poi interfacce e domini vengono sostituiti a ondate. Microsoft propone il pattern Strangler Fig per instradare capacità selezionate verso il nuovo layer, mantenendo il resto sul sistema host finché dipendenze e comportamento non sono stati verificati.

Qui l’AI non è una macchina di conversione totale. Serve a ricostruire documentazione, mappare dipendenze, estrarre regole e preparare specifiche. Il codice nuovo nasce per un confine preciso, con test di regressione confrontati con il sistema esistente. È lo stesso motivo per cui, in un progetto web, conviene mettere un gateway davanti a servizi diversi invece di distribuire chiamate dirette ovunque: il confine rende sostituibile ciò che sta dietro. Ne ho parlato anche nel confronto su FDE e API nell’adozione dell’AI.

Tempo: consegna unica o valore a ondate

Il refactor può comprimere la fase di conversione, ma concentra il valore verso il collaudo e il cutover. Prima di spostare traffico reale servono equivalenza funzionale, migrazione dati, integrazione e prove operative. Il team può avanzare rapidamente sul codice e restare comunque bloccato sull’ultimo tratto.

Il percorso incrementale richiede più disciplina iniziale: osservabilità, catalogo delle dipendenze, contratti API, gestione della doppia esecuzione e responsabilità chiare sui dati. In cambio, un dominio circoscritto può arrivare prima in produzione. Il progresso si misura su capacità trasferite, non su righe convertite.

Rischio: equivalenza o convivenza

Nel refactor il rischio principale è l’equivalenza. Le regole implicite, gli arrotondamenti, l’ordine dei job e gli effetti collaterali devono produrre gli stessi risultati. La revisione umana resta necessaria: anche i flussi ufficiali di AWS prevedono validazione delle specifiche, code review, test d’integrazione e accettazione prima della produzione.

Nella migrazione incrementale il rischio si sposta sulla convivenza. Per un periodo esistono due mondi: identità, dati, code, monitoraggio e gestione degli errori devono attraversare il confine senza creare doppie scritture o stati incoerenti. È meno spettacolare di una conversione completa, ma consente rollback più piccoli e rende visibile dove il sistema si rompe davvero.

Cosa cambia per PMI, WordPress e automazioni

Una PMI raramente ha un mainframe, ma possiede spesso un “legacy invisibile”: plugin WordPress non più mantenuti, fogli di calcolo usati come database, webhook senza log e automazioni affidate alla memoria di una persona. Anche qui la conversione totale assistita dall’AI è allettante. Generare un nuovo plugin o riscrivere un workflow è facile; dimostrare che gestisca permessi, retry, email, pagamenti e casi limite come prima è la parte costosa.

Per questo applicherei lo stesso criterio. Se il processo è corretto, ben testabile e deve soprattutto cambiare stack, il refactor assistito è efficace. Se il processo deve cambiare, ha molte integrazioni o non è documentato, partirei da un confine: API, coda, modulo WordPress o singolo workflow. Prima si misura il comportamento corrente, poi si migra una capacità. Anche il ROI di un workflow AI va letto sul risultato operativo, non sul volume di codice prodotto.

La scelta netta

Per un sistema stabile, con test affidabili e obiettivo principale di uscire dal COBOL, sceglierei il refactor assistito dall’AI. Riduce il lavoro meccanico e conserva più facilmente il comportamento.

Negli altri casi sceglierei la migrazione incrementale per domini. È più lenta da progettare, ma evita di automatizzare una decisione architetturale sbagliata. La mia regola è semplice: l’AI può accelerare la traduzione del codice; il confine di migrazione deve ancora deciderlo chi risponde del processo.

Fonti

Approfondimenti