Pubblicato il 11 Ottobre 2026 · di Ismail Nasry

In breve: Una migrazione dati affidabile si progetta intorno a compatibilità, verifiche e rollback, non al solo trasferimento dei record.

Il rischio non sta nel trasferimento dei record

Una migrazione dati non consiste solo nel copiare tabelle da un sistema a un altro. La difficoltà nasce quando il vecchio sistema continua a ricevere modifiche, il nuovo usa uno schema diverso e l’applicazione deve restare disponibile.

La migrazione va quindi progettata come un percorso di compatibilità e controllo del rischio. Export e import sono solo una parte del lavoro. Servono una strategia per le scritture durante la transizione, verifiche tra le due copie e un rollback con istruzioni chiare.

Questo approccio non coincide con la scelta tra riscrivere un sistema legacy e modernizzarlo a pezzi. Qui la domanda è più precisa: come cambiare il sistema dei dati senza perdere la capacità di capire cosa è successo?

Compatibilità prima della copia

Il primo controllo riguarda il significato dei dati, non il formato del file. Un campo obbligatorio nel nuovo schema può non avere un equivalente nel vecchio. Un identificativo può seguire regole diverse. Una relazione prima implicita può diventare esplicita. Anche date, stati e valori predefiniti possono cambiare comportamento.

Per ogni area coinvolta conviene descrivere la corrispondenza tra entità, campi e identificativi. Vanno annotate anche le trasformazioni, i valori mancanti e le regole che rendono valido un record nel sistema di destinazione.

Il team deve sapere chi decide quando i due modelli non coincidono. Deve anche sapere come riconoscere una modifica già trasferita. Avere lo stesso numero di righe nei due database non dimostra che la migrazione sia corretta. Il controllo deve verificare il significato operativo dei dati.

La doppia scrittura può aiutare quando una lunga indisponibilità non è accettabile. Aggiorna il sistema sorgente e quello di destinazione durante una fase della migrazione. Non rende però coerenti le due copie in modo automatico. Una scrittura può riuscire nel primo database e fallire nel secondo. Se entrambi i sistemi accettano modifiche indipendenti, possono nascere conflitti difficili da risolvere con un semplice confronto testuale.

Prima di adottarla, il team deve decidere quale sistema è autorevole per ogni tipo di dato. Deve stabilire cosa accade se la seconda scrittura fallisce, come rendere le operazioni ripetibili e dove registrare errori, ritardi e tentativi.

Una replica continua può essere più adatta quando gli aggiornamenti sono frequenti e il codice applicativo non deve gestire due destinazioni. Un accesso centralizzato può ridurre le trasformazioni duplicate, se il modello dati lo consente.

La doppia scrittura ha senso soprattutto quando servono continuità e trasformazioni sotto controllo. Richiede però che il team sappia gestire il rischio aggiunto nel codice e nelle procedure operative.

Riconciliazione e cutover fanno parte dello stesso controllo

Una verifica utile non si limita a dire che la copia è terminata. Deve mostrare le differenze e separare quelle attese da quelle che indicano un errore.

Il controllo può partire da conteggi e intervalli di identificativi. Deve però arrivare a record mancanti, duplicati, valori trasformati, relazioni spezzate e aggiornamenti rimasti indietro. Per dataset grandi, il confronto può avvenire per partizioni o finestre temporali. L’esito di ogni segmento va conservato.

La riconciliazione serve prima del cutover e dopo il cambio delle letture. Va ripetuta finché le due copie restano disponibili. Prima di iniziare, conviene stabilire cosa significa essere pronti: nessun record non spiegato, nessun errore aperto oltre una soglia concordata, ritardo di sincronizzazione osservabile e test applicativi superati.

Le soglie concrete dipendono dal dominio. Vanno definite dal team responsabile.

Il cutover è il momento in cui il nuovo sistema diventa il riferimento per le letture e, di solito, per le scritture. La sequenza deve essere osservabile. Può includere la riduzione o il blocco temporaneo delle modifiche, l’applicazione degli ultimi cambiamenti, una nuova riconciliazione, il cambio del percorso del traffico e il controllo dei primi risultati.

Serve anche una condizione di stop. Se il ritardo di sincronizzazione cresce o una funzione critica restituisce dati incoerenti, qualcuno deve sapere chi decide e quale azione può autorizzare. Senza criteri di uscita, un problema tecnico diventa una discussione improvvisata durante l’incidente.

Rollback e scenario ipotetico

Il rollback più semplice è quello deciso prima che il nuovo sistema riceva modifiche. Dopo il cutover, però, l’applicazione può aver creato o aggiornato dati nella destinazione. Tornare a leggere dal vecchio sistema non basta: potrebbe essere ormai indietro.

Il piano deve distinguere almeno tre casi. Se l’interruzione avviene prima delle nuove scritture, si può ripristinare il percorso precedente e conservare l’evidenza del passaggio annullato.

Se ci sono già nuove scritture nella destinazione, bisogna decidere se replicarle indietro, recuperarle in modo controllato o procedere con un fail-forward. Se i dati sono stati trasformati in modo non reversibile, occorre sapere in anticipo quali informazioni si possono ricostruire e quali richiedono una copia conservata o una procedura manuale.

Questa scelta non è solo tecnica. Un rollback può perdere modifiche recenti, duplicarle o introdurre conflitti. Va quindi provato in un ambiente rappresentativo, con tempi e responsabilità chiari. Un backup non equivale a un rollback verificato. Bisogna sapere quanto richiede il ripristino e come riallineare le scritture successive.

Immaginiamo uno scenario ipotetico. Un servizio gestisce ordini. Il caricamento iniziale è completato e la doppia scrittura sembra funzionare. Dopo il passaggio delle letture, però, alcuni ordini mostrano il cliente corretto ma non le righe di dettaglio.

Un conteggio totale degli ordini non avrebbe rilevato il problema. La causa potrebbe essere l’ordine di caricamento, una relazione trasformata male o un aggiornamento arrivato dopo il controllo iniziale. Servono verifiche sulle relazioni e una procedura per risalire alla causa. Correggere il record visibile non basta.

Quando la migrazione è davvero conclusa

Spegnere il vecchio sistema non è il criterio principale di successo. Prima di farlo, il team dovrebbe poter rispondere a domande concrete: i dati critici sono riconciliati? Le scritture fallite sono recuperabili? Il nuovo percorso applicativo è osservabile? Il rollback è ancora praticabile oppure è già stato sostituito da un piano di correzione in avanti?

Una migrazione ben progettata riduce l’incertezza a ogni passaggio. Compatibilità, scritture, riconciliazione, cutover e rollback sono prove successive. Insieme verificano che il sistema conservi il significato dei dati mentre cambia la tecnologia che li ospita.