Come passo al nuovo sistema senza fermare il lavoro?

Si cambia sistema senza fermare il lavoro se non si spegne il vecchio prima che il nuovo abbia dato prova di sé: fate girare entrambi sulle stesse transazioni reali e confrontate i risultati, testate i casi rari indicati dai responsabili dei processi, pretendete un'approvazione umana di ogni modulo prima della messa in esercizio e tenete il vecchio sistema pronto per tornarci. Nella sua guida all'esecuzione della migrazione, Microsoft raccomanda di monitorare il nuovo sistema nelle prime 24-48 ore dopo il passaggio e di conservare l'ambiente di origine come ripiego durante la stabilizzazione.

Nella parte 5 avete scelto un percorso per ogni sistema. Questa parte non ripete il metodo generale di passaggio descritto in Modernizzare i sistemi legacy senza fermi. Si concentra su ciò che è nuovo: cosa testare quando è stata l'IA a scrivere o convertire il nuovo codice.

Perché il codice convertito dall'IA richiede test diversi

Il codice prodotto dagli strumenti di conversione sembra ordinato e funziona al primo colpo, ed è proprio questo a rendere difficili da vedere i suoi errori. L'errore non compare nei casi quotidiani; compare nel caso che si presenta una volta al mese o una volta all'anno. Amazon spiega nella sua guida alla trasformazione delle applicazioni mainframe che la prima conversione da COBOL a Java mantiene lo stesso comportamento e che poi un passaggio chiamato Reforge usa grandi modelli linguistici per ristrutturare il codice nello stile moderno di Java. COBOL è un vecchio linguaggio di programmazione che fa ancora funzionare molti sistemi bancari e mainframe; il mainframe è il grande server centrale su cui girano i sistemi chiave delle grandi organizzazioni.

Ogni passaggio che riscrive il codice può cambiare un piccolo dettaglio. Non basta quindi che uno sviluppatore legga il nuovo codice e dica che sembra corretto. La direzione ha una sola domanda: il nuovo sistema dà lo stesso risultato del vecchio sugli stessi dati? La risposta viene dal confronto dei risultati, non dalla lettura del codice.

Confrontate i risultati sulle stesse transazioni reali

Prendete un periodo chiuso della vostra attività, come un mese con i conti già chiusi, fate passare le sue transazioni nel nuovo sistema e confrontate ciò che esce con ciò che aveva prodotto il vecchio. Cosa confrontare:

• Cifre finali: totali fatturati, saldi e giacenze a fine periodo.
• Report: i report mensili su cui si basa la direzione, riga per riga.
• Ciò che va ad altri sistemi: i file e i messaggi inviati alla banca, alla contabilità o ai portali della pubblica amministrazione.
• Rifiuti ed errori: una transazione che il vecchio sistema rifiuta deve essere rifiutata anche dal nuovo, per lo stesso motivo.

Alcuni strumenti aiutano a preparare, non a giudicare. AWS Transform per mainframe, per esempio, costruisce un piano di test a partire dalle caratteristiche del codice, dalla complessità dei job e dai percorsi dello scheduler in 3 fasi (configurazione, definizione dell'ambito e revisione), poi genera script per raccogliere i dati di test dal mainframe in 4 fasi. Ma Amazon avverte nella stessa guida che questi script vanno eseguiti sul vostro mainframe, con i permessi del vostro team. Lo strumento prepara; il vostro team esegue e decide. Per verificare i dati stessi, Microsoft suggerisce di confrontare il numero di righe come controllo rapido e poi i checksum come controllo più approfondito: un checksum è un numero calcolato dai dati che cambia se cambia anche un solo carattere.

I casi rari: chiedete a chi li conosce

Un mese di transazioni reali non contiene tutto. I casi che mandano in crisi i sistemi li conoscono i responsabili dei processi, non gli sviluppatori: la chiusura di fine esercizio, un reso parziale su una vecchia fattura, un cliente con prezzi speciali, una fattura annullata dopo la registrazione, lo stipendio di chi è stato assunto a metà mese. Chiedete a ogni responsabile di processo l'elenco dei casi che lo preoccupano e trasformate ciascuno in un test con un risultato atteso scritto prima dell'esecuzione.

Qui tornano le regole confermate nella parte 4: ogni regola confermata diventa almeno un caso di test. Una regola senza test è una regola di cui non potete dire che sia sopravvissuta alla conversione. Sui tipi di test in sé, vedete la nostra guida ai test del software e al controllo qualità.

Un'approvazione umana per ogni modulo

L'esempio pubblicato più chiaro di questo principio è la pipeline di migrazione bancaria annunciata da Thought Machine con Amazon il 29 settembre 2026. Si articola in 4 fasi: estrazione della logica di business dalle applicazioni legacy con AWS Transform, consolidamento delle varianti ridondanti in specifiche unificate, generazione dei nuovi prodotti finanziari e delle relative suite di test con agenti di IA, e una fase di validazione che dà ai team di ingegneria e di rischio della banca un'autorità di approvazione esplicita prima che qualcosa venga accettato. Anche dopo l'approvazione, il risultato passa in un ambiente di prova isolato per un'ulteriore valutazione, non direttamente in produzione.

La lezione per la vostra azienda non richiede né una banca né Amazon: ogni modulo del sistema, come fatturazione, paghe o magazzino, riceve due firme prima della messa in esercizio. Una tecnica, che conferma che tutti i test sono stati eseguiti, e una del responsabile del processo, che conferma che i risultati sono corretti in termini di business. Microsoft chiede lo stesso dopo il passaggio: che i responsabili dell'applicazione confermino il corretto funzionamento di tutte le funzioni principali.

Esercizio in parallelo e piano di rientro

Esercizio in parallelo significa che i due sistemi lavorano fianco a fianco per un periodo definito, con il vecchio che resta il riferimento ufficiale. Decidete prima di iniziare quando finisce questo periodo e quale condizione permette di chiuderlo, per esempio risultati coincidenti per un intero ciclo della vostra attività. Poi organizzate il passaggio così:

Un piano di rientro non è un'ammissione di fallimento; è un'assicurazione. Scrivete in anticipo cosa vi farebbe tornare indietro, come un errore nelle fatture o il blocco di un processo chiave, chi prende la decisione e come gli utenti tornano al vecchio sistema. Non spegnete definitivamente il vecchio sistema prima della fine del periodo di stabilizzazione. Ciò che di solito non funziona nelle prime settimane dopo un cambio è trattato in I primi trenta giorni dopo la migrazione.

Il punto di vista di Origami

Trattiamo il passaggio come una decisione della direzione, non come un evento tecnico. Per questo costruiamo il confronto tra i due sistemi prima di costruire il nuovo sistema, e concordiamo presto con i responsabili dei processi i casi rari e i risultati attesi, così che la definizione di successo sia scritta prima che qualcuno veda i risultati.

Usiamo l'IA per accelerare la conversione e generare i test, ma l'approvazione di ogni modulo resta a persone con nome e cognome del vostro team. Per vedere come lavoriamo, date un'occhiata ai nostri servizi.

L'esercizio di questa settimana: una scheda di passaggio per modulo

Per ogni sistema che avete deciso di convertire o ricostruire nella parte 5, compilate questa scheda con i responsabili dei processi prima di fissare qualsiasi data di passaggio:

Sono esempi illustrativi; la vostra scheda sarà diversa. L'importante è non fissare alcuna data di passaggio finché ogni modulo non ha due firmatari con nome e una condizione di rientro scritta.

Cosa viene dopo

Resta una domanda che ogni dirigente si pone prima di inviare codice e dati a uno strumento di IA: dove vanno i miei dati durante la modernizzazione? La parte 7, l'ultima, risponde e raccoglie gli esercizi di tutta la serie in un piano di 90 giorni.

Fonti

• Microsoft: Eseguire la migrazione, Cloud Adoption Framework — riunione sui criteri di rientro, blocco delle modifiche, validazione dei dati, 24-48 ore di monitoraggio e conservazione dell'ambiente di origine come ripiego.
• Amazon: Trasformazione delle applicazioni mainframe in AWS Transform — piani di test, script di raccolta dei dati di test e il passaggio Reforge.
• Amazon: annuncio di Thought Machine e AWS sulle migrazioni bancarie legacy — le quattro fasi e l'approvazione dei team di ingegneria e di rischio.
• AWS Transform: pagina ufficiale.