Risposta.

Storia della questione:

La migrazione dei dati è una fase critica dei grandi progetti IT, specialmente quando si passa da sistemi informatici obsoleti (legacy) a nuove soluzioni. Errori nella formalizzazione dei requisiti possono portare alla perdita di informazioni importanti o a prolungati tempi di inattività durante il lancio di un nuovo sistema (soprattutto durante implementazioni su larga scala). Nella storia ci sono casi sfortunati di fallimenti bancari proprio a causa di insuccessi nella migrazione!

Problema:

L'incertezza nei formati di origine e destinazione, le differenze nella struttura dei dati, l'incongruenza dei registri, errori nel mapping e aspettative opposte tra il team di business e l'integratore tecnico sono le principali cause di migrazioni problematiche. Documentazione fittizia o insufficientemente dettagliata porta all'impossibilità di tracciare quali dati siano critici, quali possano essere aggregati e quali non possano essere trasferiti affatto.

Soluzione:

L'analista di sistema effettua una revisione dei dati sul lato sorgente insieme ai proprietari dei processi di business; elabora una mappa dettagliata dei dati (data mapping), definendo quali attributi debbano essere migrati obbligatoriamente e quali no. Documenta le assunzioni sulla qualità dei dati (pulizia, completezza), definisce le regole di trasformazione (ad esempio, modifica del formato delle date, valute, codifiche). Per i campi critici viene attuata una migrazione campionaria di prova e scenari di controllo inverso (reconciliation). In ogni fase vengono redatte contemporaneamente istruzioni per il rollback e criteri di successo della migrazione.

Caratteristiche chiave:

Attenta revisione e gestione delle incongruenze nei formati tra il sistema di origine e quello di destinazione
Identificazione dei campi critici e loro priorizzazione
Documentazione degli scenari di rollback e verifica dell'integrità dei dati (data reconciliation)

Domande insidiose.

È sufficiente confrontare i formati dei dati tra i sistemi per una migrazione riuscita?

No. Anche in caso di coincidenza dei formati, possono esserci incongruenze nel significato commerciale dei dati, validità dei registri, semantica dei valori. È necessaria un'audit di business e tecnico per ogni campo.

È possibile limitarsi a migrare solo i dati "più richiesti"?

No. Dati "rari" possono essere critici per determinati processi utente (ad esempio, per vecchi contratti, assicurazioni). Tutto deve essere documentato nei requisiti.

È necessario prevedere la possibilità di rollback della migrazione?

Assolutamente: anche con test al 100% possono verificarsi errori critici dopo il go-live, i rollback sono una parte obbligatoria della documentazione.

Errori tipici e anti-pattern

Insufficiente dettaglio nella mappa dei dati e degli attributi di business
Mancanza di criteri di successo della migrazione e scenari di rollback
Trascurare migrazioni di prova su dati di test
Ignorare incidenti negli snodi di integrazione (salti di dipendenze non ovvie)

Esempio dalla vita reale

Caso negativo: Durante la migrazione di un sistema bancario ereditato, l'analista ha approvato il trasferimento solo delle tabelle principali, senza chiarire il significato commerciale dei registri non utilizzati. Di conseguenza, dopo il lancio, i clienti hanno riscontrato problemi con la storia delle transazioni degli anni precedenti.

Vantaggi:

Rapido avvio del nuovo sistema

Svantaggi:

Perdita di dati
Rischi reputazionali per la banca

Caso positivo:

L'analista, insieme al business e all'IT, ha effettuato una revisione di tutti i dataset, ha redatto requisiti separati per il trasferimento di dati "rari", ha concordato scenari di validazione e rollback. La migrazione è stata un successo, non ci sono state lamentele critiche.