Una nuova applicazione può essere tecnicamente pronta senza che l'azienda sia pronta a migrare. I dati devono essere recuperati, gli utenti formati, le integrazioni sincronizzate e gli incidenti gestiti. La strategia di transizione è quindi un prodotto a sé stante, con la sua architettura, i suoi test e i suoi criteri di successo.
Due approcci dominano le discussioni. Il passaggio big bang sostituisce il vecchio sistema in una data specifica. La migrazione progressiva sposta funzioni, popolazioni o flussi a tappe. Nessuna è superiore in assoluto. La scelta dipende dalla possibilità di coesistenza, dalla qualità dei dati e dalla tolleranza all'interruzione.
Ciò che significa realmente un cambiamento in stile big bang
Il big bang concentra la migrazione in una finestra definita. Il vecchio sistema viene fermato o messo in sola lettura, i dati finali vengono trasferiti, le verifiche eseguite e poi il nuovo diventa il riferimento.
Questa strategia semplifica la governance dopo il passaggio: un'unica applicazione, un'unica fonte di verità e meno sincronizzazione temporanea. È adatta quando il perimetro è compatto, l'interruzione è accettabile, i dati possono essere migrati rapidamente e esiste un ritorno indietro credibile.
Il suo rischio deriva dalla concentrazione. Un errore di trasformazione, un volume sottovalutato o un'integrazione mancante influenzano immediatamente tutti gli utenti. Le prove generali e la qualità del piano di emergenza diventano indispensabili.
Ciò che copre una migrazione progressiva
La migrazione progressiva può assumere diverse forme:
- per popolazione: un sito, una filiale o un gruppo pilota;
- per capacità: ricerca, fatturazione, reporting o gestione documentale;
- per percorso: nuove richieste nel sistema nuovo, storico in quello vecchio;
- per dati: categorie o periodi trasferiti a ondate;
- per traffico: una quota crescente delle richieste instradata verso il nuovo componente.
Questo approccio riduce il raggio d’impatto e permette di imparare. Impone invece di gestire la coesistenza: sincronizzazione, scritture doppie, identità, supporto, reporting e responsabilità dei dati.
I sette criteri di decisione
1. Tolleranza all'interruzione
Se il mestiere può fermare il sistema durante una finestra nota, il big bang rimane possibile. Se ogni minuto ha un impatto importante, deve essere studiata una transizione graduale o un'architettura active-active.
2. Capacità di segmentare
Una migrazione progressiva richiede un confine: utenti, funzioni, paesi, prodotti o flussi. Senza una separazione netta, il sistema temporaneo può diventare più complesso della ristrutturazione stessa.
3. Fonte di verità
Durante la coesistenza, ogni dato deve avere un padrone. Le scritture doppie non controllate creano divergenze difficili da riconciliare. Una strategia deve precisare chi può modificare cosa, dove e fino a quando.
4. Volume e qualità dei dati
I dati devono essere profilati prima della decisione. Un volume elevato non vieta il big bang se la trasformazione è rapida e testata. Dati incoerenti possono invece imporre una migrazione progressiva con correzione del business.
5. Numero di integrazioni
Ogni partner deve essere migrato, duplicato o adattato. Un passaggio globale può semplificare il contratto, ma aumenta il numero di dipendenze da coordinare nello stesso giorno.
6. Capacità di ritorno indietro
Il rollback non significa solo riavviare la vecchia applicazione. Bisogna ripristinare i dati creati durante la finestra e gestire le operazioni inviate a terzi. Più il nuovo sistema scrive, più il rollback diventa un progetto.
7. Disponibilità dei team aziendali
Una migrazione a ondate richiede diverse procedure, formazioni e periodi di supporto. Il big bang richiede un forte impegno concentrato. La scelta deve riflettere la reale capacità dell’organizzazione.
Confrontare gli approcci
| Criterio | Grande esplosione | Migrazione progressiva |
|---|---|---|
| Durata della coesistenza | Corta | Media a lunga |
| Complessità temporanea | Limitata ma intensa | Allevata e distribuita |
| Raggio d'impatto | Globale | Limitato da onda |
| Apprendimento in produzione | Basso prima del ribaltamento | Importante |
| Sincronizzazione | Spesso puntuale | Spesso continua |
| Mobilitazione professionale | Concentrata | Ripetuta |
| Indietro | Semplice solo prima delle scritture | Possibile per perimetro, ma da concepire |
Lo schema inizia con la continuità del business. Un'interruzione accettabile, un perimetro compatto, una migrazione dei dati ripetuta e un ritorno indietro credibile rendono possibile un passaggio 'big bang'. Quando l'interruzione non è accettabile, la capacità di segmentazione orienta verso una migrazione progressiva. Una popolazione rappresentativa permette un pilota; moduli isolabili permettono una migrazione per funzione o per traffico; una suddivisione per sito, filiale, periodo o categoria di dati permette una migrazione a onde. Quando la segmentazione non è possibile, bisogna prima ridurre il perimetro o progettare esplicitamente una coesistenza e la sua sincronizzazione. In tutti i casi, l'assenza di prove sui dati o sul ritorno indietro impone una ripetizione prima della decisione. La lista seguente costituisce una versione testuale equivalente.
- Verificare se un'interruzione del lavoro è accettabile e limitata.
- Se sì, confermare che il perimetro è compatto, la migrazione ripetibile e il rollback testato prima di optare per un big bang.
- Se no, cercare un confine per popolazione, funzione, percorso, dati o traffico.
- Se questo confine esiste, scegliere un pilota o una migrazione progressiva a ondate.
- Se non esiste, ridurre prima il perimetro o progettare una coesistenza con una fonte di verità esplicita.
- In ogni scenario, raccogliere le prove sui dati, le integrazioni, la sincronizzazione e il rollback prima del go/no-go.
Progettare un'architettura di transizione
Una migrazione progressiva richiede componenti temporanei espliciti: router, facciata API, sincronizzazione, registro eventi, adattatori e schermi di riconciliazione. Ognuno deve avere un responsabile, una tracciabilità e una data di ritiro.
L’anti-pattern consiste à ajouter des passarelle senza ridurre il perimetro antico. La complessità aumenta allora a ogni ondata. Un indicatore utile segue la parte di funzioni, dati e traffico effettivamente rimossa dal vecchio sistema.
Preparare i dati
La migrazione inizia con una profilazione: volumi, duplicati, valori mancanti, codifica, allegati, relazioni e regole di conservazione. Le trasformazioni devono essere versionate e riproducibili. I controlli confrontano totali, campioni, vincoli e risultati aziendali.
Una ripetizione completa su una copia realistica misura il tempo e rivela le operazioni manuali. La finestra finale deve includere un margine, dei punti di decisione e una soglia oltre la quale il cambio viene annullato.
Definire criteri di go/no-go
La decisione non può basarsi su un'impressione generale. I criteri includono:
- zero anomalie critica aperta;
- percorsi critici convalidati;
- prestazione misurata con il volume previsto;
- backup e ripristino testati;
- integrazioni confermate;
- supporto e comunicazione pronti;
- piano di rollback ripetuto;
- responsabilità di crisi attribuite.
Ogni criterio possiede una prova, un proprietario e una scadenza per la decisione.
Organizzare il pilota
Un pilota utile è rappresentativo senza essere vitale. Deve testare i veri flussi, i permessi, i dati e il supporto. I feedback sono classificati tra difetto del prodotto, mancanza di formazione, dati errati e procedura incompleta.
Il pilota non deve diventare una versione parallela permanente. La data di generalizzazione e le condizioni di arresto devono essere definite fin dall'inizio.
Preparare il giorno del cambiamento
Il runbook descrive le fasi minuto per minuto: congelamento, estrazione, trasformazione, caricamento, controlli, apertura, supervisione e comunicazione. Specifica i comandi, le prove attese, i responsabili e i punti di decisione.
Un canale di crisi distinto dal supporto corrente centralizza le informazioni. I team tecnici, di settore, infrastrutturali e i partner vi dispongono di un linguaggio comune e di un'autorità decisionale chiara.
Stabilizzare dopo il lancio
Le prime ore seguono indicatori specifici: errori, code, tempi di risposta, volumi, variazioni dei dati e richieste di supporto. Le modifiche non essenziali sono limitate fino alla fine del periodo di hypercare.
Il ritorno d'esperienza deve documentare le discrepanze tra il piano e la realtà. Migliora le ondate successive o i prossimi progetti, invece di scomparire una volta che la pressione è scemata.
Scegliere il rischio che si sa controllare
Il big bang riduce la complessità della coesistenza ma concentra l’impatto. La migrazione progressiva limita ogni ondata ma aggiunge un’architettura temporanea. La decisione giusta è quella i cui rischi possono essere testati, osservati e invertiti.
Partitech accompagna la progettazione tecnica, la verifica e la messa in produzione di piattaforme complesse. Noi integriamo la strategia di transizione fin dall'architettura affinché la revisione non diventi una scommessa il giorno del passaggio.
Per approfondire l'approccio, definite una traiettoria per modernizzare un'applicazione legacy senza riscrivere tutto, preparateli aggiornamenti di versione senza interruzione e inquadralo PRA, il PCA e la continuità operativa. Consultate anche le prestazioni Partitech.
Riferimenti ufficiali
Riferimenti verificati il 17 agosto 2026 :