Google Cloud Rifiuta il Big Bang del Mainframe per un Percorso di Migrazione Guidato dall'IA

Google Cloud ha illustrato un'alternativa in quattro fasi alle rischiose migrazioni dei mainframe, basata su analisi tramite IA, generazione di codice, conversione dei dati e validazione parallela prima del passaggio.

La proposta mette in discussione una scelta consolidata. Le aziende possono continuare a mantenere sistemi obsoleti oppure tentare una migrazione su vasta scala, le cui dipendenze diventano visibili solo dopo l'avvio dei lavori. Google sostiene che nessuna delle due opzioni affronti il problema più difficile: capire cosa faccia realmente il sistema esistente.

La sua risposta collega Mainframe Assessment Tool, Gemini CLI, Mainframe Connector e Dual Run in un unico processo continuo. I team prima ricostruiscono regole aziendali e dipendenze. Quindi sviluppano applicazioni cloud attorno a requisiti verificati, spostano i dati pertinenti e confrontano entrambi gli ambienti su carichi di lavoro reali.

Questa sequenza rende l'iniziativa più di un semplice annuncio sulla conversione del codice. Il confronto principale è tra modernizzazione iterativa e migrazione big bang, non tra infrastruttura cloud e hardware mainframe.

Google deve inoltre confrontarsi con alternative consolidate. IBM applica l'IA preservando al contempo un ruolo centrale per IBM Z. AWS promuove un servizio agentico che riconduce requisiti e codice generati alle fonti mainframe. Ogni fornitore riconosce che la sola generazione del codice non può stabilire se un sistema sostitutivo sia corretto.

La domanda critica, pertanto, non è se Gemini sia in grado di tradurre COBOL. È se il workflow connesso di Google possa preservare decenni di comportamenti aziendali nascosti, consentendo al contempo alle aziende di modernizzarsi in componenti gestibili.

Google Cloud Trasforma Quattro Strumenti in un Unico Percorso di Migrazione

Il cambiamento importante è il collegamento tra valutazione, generazione, spostamento dei dati e validazione in produzione.

Il framework di modernizzazione di Google parte dal reverse engineering. Mainframe Assessment Tool esamina codice sorgente, strutture di database, monitor delle transazioni, configurazioni degli scheduler e relazioni tra le risorse.

Supporta programmi COBOL, copybook, job JCL, procedure, include e artefatti correlati. Lo strumento usa Gemini per generare riepiloghi, specifiche tecniche e regole aziendali proposte a partire da quel materiale.

Le regole aziendali sono le politiche codificate all'interno di un'applicazione, come condizioni di idoneità, calcoli degli interessi o decisioni di instradamento delle transazioni. Sono importanti perché il comportamento osservabile di un vecchio programma spesso supera quanto documentato.

Google afferma che i team possano rivedere, filtrare e convalidare le regole estratte prima di esportarle. Questo controllo umano distingue la proposta da una semplice istruzione di tradurre ogni riga in Java o in un altro linguaggio moderno.

La valutazione può anche suddividere un parco applicativo in domini aziendali e unità migrabili più piccole. Un'unità migrabile è una raccolta delimitata di programmi, dati e dipendenze che può essere spostata insieme senza compromettere i servizi adiacenti.

Questa suddivisione crea la base per un programma iterativo. Una banca potrebbe isolare un flusso di reporting prima di intervenire sull'autorizzazione dei pagamenti. Una compagnia assicurativa potrebbe spostare un servizio di elaborazione documenti lasciando la liquidazione dei sinistri sul mainframe.

Dopo la valutazione, Gemini CLI supporta il forward engineering. Ciò significa che i team usano requisiti convalidati per pianificare un'architettura di destinazione e generare nuovo codice, anziché considerare la base di codice esistente come il progetto di riferimento.

Il workflow può proporre modelli di dati e servizi su Cloud Run, Google Kubernetes Engine, Compute Engine, BigQuery, Spanner, AlloyDB e Cloud SQL. Queste proposte richiedono comunque una revisione architetturale, perché una raccomandazione generata non è una decisione operativa.

Mainframe Connector gestisce un altro problema spesso sottovalutato. Copia e converte i dati mainframe, inclusi record codificati in EBCDIC, in formati utilizzabili dai servizi Google.

EBCDIC è una codifica di caratteri associata agli ambienti mainframe IBM. Convertirla correttamente richiede più di un cambiamento nella rappresentazione del testo, perché i record possono contenere decimali packed, layout di copybook e convenzioni specifiche dell'applicazione.

Dual Run completa il ciclo proposto. Esegue i carichi di lavoro nell'ambiente mainframe esistente e nell'ambiente cloud, quindi ne confronta i risultati prima del passaggio in produzione.

Il processo connesso cambia il punto in cui i team ripongono la propria fiducia. Anziché affidarsi a una conversione una tantum, accumulano evidenze lungo scoperta, revisione delle regole, implementazione, test dei dati ed esecuzione parallela.

Questa è l'affermazione centrale dell'evento. Google presenta la modernizzazione come un sistema controllato di evidenze, non come un singolo progetto di trasformazione.

Perché la Modernizzazione dei Mainframe Non È un Lavoro di Traduzione del Codice

Una conversione sintatticamente corretta può comunque riprodurre il sistema aziendale sbagliato.

I grandi parchi mainframe raramente si comportano come raccolte ordinate di applicazioni indipendenti. Un job batch notturno può aggiornare dati usati da una transazione online la mattina successiva. Un copybook condiviso può definire record utilizzati in diverse unità aziendali.

Alcune dipendenze risiedono nel codice. Altre si trovano negli scheduler, nelle convenzioni dei database, nei runbook operativi o nella conoscenza dei dipendenti che hanno gestito un carico di lavoro per decenni.

Questo rende la traduzione diretta del codice un modello incompleto. Un modello linguistico può produrre Java plausibile a partire da una routine COBOL, senza però cogliere perché quella routine venga eseguita dopo un altro job. Può anche preservare una logica che l'azienda non desidera più.

Il rischio opposto è altrettanto serio. Un sostituto generato potrebbe semplificare un comportamento apparentemente ridondante che invece gestisce un'eccezione normativa poco comune. Il problema potrebbe emergere solo durante una transazione rara o una procedura di fine trimestre.

Il design di Google, che parte dalla valutazione, mira a rendere queste relazioni ispezionabili. La sua documentazione indica che lo strumento produce alberi delle chiamate, report sulle dipendenze, riepiloghi delle regole aziendali e unità migrabili proposte.

Il sistema di valutazione supporta anche un server MCP, che consente agli agenti IA di interrogare i dati di valutazione tramite il Model Context Protocol. MCP è un'interfaccia standard per collegare i modelli a strumenti esterni e contesto strutturato.

Questa architettura offre a Gemini più di una cartella di file sorgente. Può lavorare con relazioni rilevate, specifiche riviste e regole aziendali associate a uno specifico dominio applicativo.

Tuttavia, un contesto più ricco non garantisce un'interpretazione accurata. Le specifiche generate possono omettere casi limite e l'analisi statica non può osservare ogni dipendenza creata tramite configurazione runtime o operazioni esterne.

La revisione umana rimane quindi parte del meccanismo. Gli esperti di dominio devono decidere se una regola aziendale proposta sia valida, obsoleta, incompleta o fraintesa.

Questo crea un vincolo pratico per le aziende alle prese con il ricambio del personale. Il workflow ha bisogno di operatori esperti proprio quando la loro conoscenza è più difficile da sostituire. L'IA può organizzarne la revisione, ma non può ricostruire retroattivamente una memoria istituzionale mancante.

L'approccio di Google cambia anche lo scopo del codice legacy. Anziché considerare ogni istruzione come qualcosa da preservare, i team possono trattare il parco applicativo come evidenza del comportamento aziendale previsto.

Questa distinzione favorisce una riprogettazione cloud-native. Un monitor delle transazioni non necessita di un equivalente letterale se un servizio gestito può soddisfare lo stesso requisito verificato. Un processo batch potrebbe diventare un servizio guidato dagli eventi quando i vincoli di tempistica e coerenza lo consentono.

Tuttavia, la riprogettazione amplia l'onere della validazione. Quanto più l'architettura di destinazione si allontana dall'implementazione originale, tanto meno utile diventa il confronto riga per riga.

I team devono confrontare risultati, effetti collaterali, tempistiche, integrità dei dati e ripristino dagli errori. Per questo Dual Run è centrale, non opzionale, nella narrativa di Google.

La promessa non è una traduzione perfetta. È una catena tracciabile che va dalle evidenze legacy alle regole riviste, all'implementazione generata e all'equivalenza misurata.

Il Vero Confronto È tra Modernizzazione Iterativa e Big Bang

L'argomento più forte di Google è organizzativo: unità di migrazione più piccole limitano le conseguenze dell'incertezza.

Una migrazione big bang concentra molte ipotesi in un unico passaggio. I team devono comprendere le dipendenze, trasformare il codice, spostare i dati, testare le interfacce, formare gli operatori e preparare procedure di rollback su un perimetro ampio.

Una sola dipendenza errata può ritardare l'intero programma. Peggio ancora, un difetto può raggiungere la produzione solo dopo che il ripristino dell'ambiente originale è diventato difficile.

La modernizzazione iterativa riduce questo raggio d'impatto. I team possono scegliere un dominio delimitato, documentarne le relazioni, sviluppare un'implementazione di destinazione e convalidarla mentre i carichi di lavoro vicini restano invariati.

Questo non rende semplice la modernizzazione. Cambia il modo in cui si manifesta il fallimento.

Un problema scoperto durante un'unità di migrazione può migliorare le regole di valutazione per l'unità successiva. Le discrepanze nei test possono rivelare comportamenti non documentati prima che l'azienda si impegni in un passaggio più ampio.

Dual Run fornisce il ponte operativo. Il precedente modello di test parallelo di Google mantiene il mainframe come sistema primario, mentre una copia cloud esegue lo stesso carico di lavoro come sistema secondario.

L'output cloud può quindi essere confrontato con il risultato consolidato. Differenze ripetute mettono in luce difetti nella logica trasformata, nella conversione dei dati o nelle ipotesi ambientali.

Questo è particolarmente rilevante per i sistemi ad alta intensità transazionale. Un test unitario può verificare un calcolo noto, ma non può riprodurre ogni interazione tra schemi di input reali, condizioni di pianificazione e integrazioni a valle.

L'esecuzione parallela fornisce evidenze più ampie senza attribuire immediatamente al nuovo sistema l'autorità di produzione. I team possono fissare soglie di accettazione, indagare le differenze e ripetere i test prima di trasferire la responsabilità.

Il compromesso è una coesistenza prolungata. Gestire due ambienti richiede sincronizzazione, monitoraggio, controlli contro l'elaborazione duplicata e una decisione chiara su quale sistema sia responsabile di ciascun output.

Anche i costi possono sovrapporsi durante la transizione. Google non elimina questo onere operativo. Sostiene che tale onere offra un percorso più sicuro rispetto a un evento tutto o niente.

Il modello incrementale introduce anche questioni di governance. I team hanno bisogno di regole per scegliere le unità di migrazione e decidere quando un'applicazione abbia dimostrato un'equivalenza sufficiente.

Devono tracciare quali regole aziendali siano state accettate, chi le abbia approvate, quali evidenze di test le supportino e cosa sia cambiato dopo la validazione. Senza tale registro, il lavoro iterativo può creare un parco ibrido frammentato.

Qui conta la disciplina architetturale. Una sequenza di progetti cloud isolati può riprodurre la complessità del mainframe attraverso nuovi servizi, code, database e interfacce non documentate.

Gli strumenti di Google possono mappare e generare artefatti, ma un'azienda necessita comunque di un'architettura di destinazione coerente. Ha inoltre bisogno di un piano di ritiro per ogni componente mainframe sostituito dal cloud.

L'approccio riesce quando l'iterazione produce una semplificazione cumulativa. Fallisce quando ogni unità migrata aggiunge un altro ponte permanente verso il parco legacy.

Per questo il confronto non è tra velocità e cautela. Un big bang affrettato può fallire in modo spettacolare, mentre un programma incrementale senza fine può fallire silenziosamente.

La misura significativa è la capacità aziendale completata. Ogni unità di migrazione dovrebbe raggiungere un funzionamento in produzione convalidato ed eliminare la corrispondente responsabilità legacy.

Google Cloud affronta IBM e AWS a condizioni diverse

Tutti e tre i fornitori usano ormai l'AI, ma differiscono su dove debba risiedere il carico di lavoro modernizzato e su come venga stabilita l'equivalenza.

La posizione di IBM parte dal valore ancora attuale del mainframe. Il suo watsonx Code Assistant for Z supporta discovery, spiegazione, refactoring, generazione di codice, ottimizzazione e trasformazione, mantenendo IBM Z come importante ambiente di esecuzione.

IBM afferma che il suo assistente può spiegare COBOL, PL/I, REXX, Assembler e JCL. Può inoltre rifattorizzare programmi selezionati in servizi modulari o trasformare COBOL in Java orientato agli oggetti.

Gli strumenti di modernizzazione AI dell'azienda includono test unitari automatizzati per l'equivalenza semantica. Il termine indica che il nuovo codice dovrebbe produrre lo stesso comportamento previsto dell'originale, anche quando la sua struttura cambia.

Questo percorso può essere adatto alle imprese che desiderano migliori pratiche di sviluppo senza impegnare ogni carico di lavoro in un cloud hyperscale. Consente inoltre ai team di modernizzare attorno a un mainframe, anziché trattare la piattaforma come una scadenza.

AWS adotta una posizione più vicina alla destinazione cloud di Google, ma il suo messaggio attuale pone l'accento sull'esecuzione agentica e sulla tracciabilità. AWS Transform for mainframe copre valutazione, estrazione delle regole di business, requisiti, generazione del codice, test e distribuzione.

AWS afferma che ogni output generato può essere ricondotto, attraverso i requisiti, al codice sorgente originale. Il suo workflow agentico si integra inoltre con agenti di coding come Kiro e con gli ambienti di sviluppo esistenti tramite protocolli aperti.

Questa tracciabilità mira allo stesso divario di fiducia affrontato da Dual Run di Google. Offre ai revisori un percorso di audit che mostra l'origine di un requisito o di un componente generato.

La differenziazione di Google consiste nel combinare la valutazione contestuale con la conversione dei dati e la convalida parallela a livello di carico di lavoro. Gemini aiuta nella comprensione e nella generazione, mentre Dual Run verifica il comportamento rispetto al sistema operativo di riferimento.

Non si tratta di categorie di prodotto nettamente separate. Anche IBM offre discovery e testing. Anche AWS dichiara la convalida automatizzata dell'equivalenza funzionale. Ogni fornitore sta ampliando la propria offerta lungo l'intero ciclo di vita.

La pressione competitiva si sposterà quindi verso le evidenze di implementazione. Gli acquirenti devono sapere quali linguaggi, scheduler, database, sistemi transazionali e formati di dati ciascun workflow gestisce nel proprio parco applicativo.

Devono inoltre distinguere la capacità del prodotto dall'erogazione del servizio. I programmi mainframe coinvolgono spesso system integrator, esperti interni, specialisti del fornitore e anni di storia applicativa.

Nessun modello opera in modo indipendente da questa struttura di erogazione. L'AI può ridurre l'analisi manuale, redigere specifiche e generare codice, ma le decisioni di integrazione restano specifiche di ciascun ambiente.

Il vendor lock-in rappresenta un'altra considerazione. Un'architettura generata può favorire i database, le piattaforme di calcolo, i sistemi di monitoraggio e i servizi AI di un singolo fornitore.

Questo allineamento può semplificare la distribuzione. Può però anche aumentare i costi di passaggio quando un'azienda modifica in seguito la propria strategia cloud o mantiene carichi di lavoro in più ambienti.

Le imprese dovrebbero quindi valutare gli artefatti, non solo le dimostrazioni. Regole esportabili, specifiche leggibili, test portabili e approvazioni tracciabili sono importanti oltre la trasformazione iniziale.

Il mercato sta convergendo sulla modernizzazione assistita dall'AI. La competizione irrisolta riguarda dove gli esseri umani verifichino il lavoro, come i fornitori misurino l'equivalenza e quale piattaforma detenga il risultato.

Cosa il workflow AI di Google Cloud non può ancora garantire

Il workflow riduce rischi specifici di migrazione, ma non stabilisce che le regole di business o il codice di destinazione generati siano corretti.

La prima incertezza emerge durante la discovery. L'analisi statica può identificare le relazioni nel codice sorgente e le chiamate dichiarate, ma il comportamento dinamico potrebbe dipendere da valori di runtime, scelte degli operatori o sistemi esterni.

Anche un riepilogo generato dall'AI può apparire più certo di quanto consentano le sue evidenze. I revisori potrebbero approvare una spiegazione chiara perché leggibile, anche quando omette un ramo poco frequente.

Ciò crea un bias di automazione, che si verifica quando le persone ripongono eccessiva fiducia nella raccomandazione di un sistema. Una specifica rifinita può aumentare questo rischio perché nasconde l'ambiguità presente nel parco applicativo sottostante.

Il workflow di Google conserva un passaggio di revisione per le regole estratte. Le imprese dovrebbero trattarlo come un controllo, non come un passaggio amministrativo.

La revisione richiede responsabili nominati, evidenze collegate e disposizioni esplicite. Una regola dovrebbe essere contrassegnata come accettata, rifiutata, rivista o irrisolta prima di guidare il codice generato.

La sicurezza aggiunge un ulteriore livello. Google afferma che il Mainframe Assessment Tool mantiene i dati di valutazione raccolti all'interno della macchina virtuale su cui è distribuito. La sua documentazione afferma inoltre che il codice sorgente viene caricato sulla Gemini Enterprise Agent Platform.

La stessa documentazione dichiara che il modello non viene arricchito con informazioni estratte da quel codice. Le organizzazioni devono comunque verificare i controlli regionali, le policy di accesso, il comportamento di conservazione e i requisiti contrattuali relativi ai propri carichi di lavoro.

Anche i test hanno dei limiti. Dual Run può rilevare differenze tra gli output osservati, ma l'equivalenza dipende dalla copertura e dalla qualità del confronto.

Se entrambi gli ambienti ricevono solo transazioni comuni, i casi rari restano non testati. Se la logica di confronto ignora tempi, ordinamento o effetti collaterali a valle, due output possono apparire uguali mentre i sistemi si comportano diversamente.

I test paralleli possono anche riprodurre un comportamento legacy errato. Corrispondere al mainframe è utile durante la migrazione, ma non dimostra che ogni regola ereditata sia desiderabile o conforme alla policy corrente.

I team devono separare due domande. L'implementazione cloud si comporta come l'originale, e il comportamento originale dovrebbe sopravvivere?

La seconda domanda richiede valutazioni aziendali, legali, di sicurezza e operative. La sola analisi del codice non può rispondervi.

Anche le affermazioni sulle prestazioni richiedono evidenze simili alla produzione. Un servizio generato potrebbe superare i test funzionali, creando però latenza inaccettabile, consumo di infrastruttura o contesa sul database nei picchi di volume.

Il ripristino operativo merita la stessa attenzione. I team dovrebbero testare ritenti, guasti parziali, messaggi ritardati, transazioni duplicate e procedure di rollback prima di trasferire la responsabilità.

Infine, il workflow non può garantire il completamento del programma. Un'impresa può produrre valutazioni e prototipi eccellenti senza dismettere un singolo carico di lavoro mainframe.

Il successo richiede criteri di uscita per ogni unità di migrazione. Tali criteri dovrebbero coprire evidenze funzionali, prontezza operativa, riconciliazione dei dati, approvazione della sicurezza, aspettative di costo e l'effettiva dismissione del legacy.

La strategia di Google è più sicura perché rende visibile l'incertezza prima. Non è sicura semplicemente perché vi partecipa l'AI.

Cosa osservare mentre Google Cloud passa dal metodo alle evidenze

Il prossimo banco di prova sarà se il metodo per fasi produrrà passaggi in produzione ripetibili, non codice generato più convincente.

Il primo segnale è rappresentato dalle evidenze dei clienti legate a unità di migrazione completate. Gli acquirenti dovrebbero cercare carichi di lavoro in produzione nominati che abbiano superato i test paralleli e trasferito la responsabilità del sistema di riferimento.

Un caso di studio utile dovrebbe spiegare ambito, artefatti supportati, dipendenze individuate, durata della convalida, gestione delle discrepanze e i componenti mainframe infine dismessi. Le affermazioni generiche su un'analisi più veloce rivelano meno.

Cutover ripetuti rafforzerebbero l'argomentazione di Google secondo cui il workflow scala oltre un'applicazione accuratamente selezionata. Valutazioni senza dismissione in produzione la indebolirebbero.

Il secondo segnale è una tracciabilità più profonda lungo l'intera toolchain. La cronologia delle versioni di Google mostra un lavoro continuo su estrazione delle regole di business, accesso MCP, copertura dei linguaggi e analisi di grandi parchi applicativi.

L'avanzamento importante collegherebbe ogni regola approvata alle evidenze sorgente, ai componenti generati, ai test, ai risultati dei confronti e alle approvazioni umane. Questa catena renderebbe più semplice la revisione durante gli audit e la manutenzione successiva.

Aiuterebbe inoltre i team a identificare dove un errore sia entrato nel processo. Una discrepanza potrebbe ricondurre a un'estrazione difettosa, a un requisito modificato, al codice generato, ai dati convertiti o al framework di convalida.

Una chiara tracciabilità rafforzerebbe il modello iterativo perché la conoscenza si accumulerebbe tra le unità di migrazione. Artefatti frammentati farebbero sembrare ogni unità un progetto separato.

Il terzo segnale è il modo in cui IBM e AWS risponderanno con evidenze di convalida comparabili. Gli elenchi di funzionalità già si sovrappongono, quindi i fornitori dovranno mostrare come i loro metodi affrontino dipendenze reali e cutover difficili.

IBM può sostenere che la modernizzazione non richieda l'abbandono di IBM Z. AWS può enfatizzare la tracciabilità dal sorgente all'output e i test automatizzati. Google deve dimostrare che la valutazione contestuale unita a Dual Run offra un migliore confine di rischio.

Questa competizione dovrebbe favorire gli acquirenti aziendali. Sposta la discussione dalle dimostrazioni di pura generazione di codice verso evidenze, governance, portabilità e risultati completati.

Per i leader tecnologici, l'azione immediata non consiste nell'approvare una migrazione dell'intero parco applicativo. Consiste nel selezionare un dominio significativo e testare l'intera catena.

Il dominio dovrebbe contenere dipendenze reali e conseguenze aziendali senza diventare una prima mossa irreversibile. La sua valutazione dovrebbe includere codice, dati, pianificazioni, interfacce e conoscenza operativa.

I team dovrebbero registrare quante regole estratte richiedono correzioni, con quale frequenza i risultati paralleli divergono e quanto tempo richiede la risoluzione di ogni discrepanza. Queste misure rivelano più del volume di codice generato.

Dovrebbero inoltre decidere cosa termina dopo un cutover riuscito. Un'unità di migrazione è incompleta se il carico di lavoro originale, l'onere delle licenze, il processo operativo e la responsabilità del supporto rimangono tutti in essere.

Google Cloud offre alle imprese una strada tra manutenzione indefinita e un rischioso big bang. La strada è credibile perché tratta la modernizzazione come discovery, ricostruzione e prova.

Il suo valore dipenderà dalla capacità dei clienti di ripetere quel ciclo in parchi applicativi complessi senza creare un labirinto ibrido permanente. I prossimi cutover in produzione conteranno più della prossima demo generata dall'AI.