Data Migration — essenza, metodi e processo di trasferimento dati

Cos'è Data Migration

Data Migration è il processo di trasferimento dei dati da una fonte all'altra garantendone l'integrità, la coerenza e la disponibilità dopo il completamento. A differenza di una semplice copia, la migrazione include la trasformazione dei formati, la rimozione dei duplicati, la verifica dell'integrità referenziale e la convalida dei risultati.

La necessità di Data Migration sorge quando si aggiorna un DBMS (ad esempio, da MySQL 5.7 a MySQL 8.0), si cambia fornitore cloud, si migra da un monolite a microservizi o si passa a uno schema NoSQL. Secondo Stripe (2024), l'89% delle aziende affronta una migrazione dati almeno una volta ogni due anni e il 43% la considera la fase più impegnativa di un aggiornamento tecnico.

Obiettivi principali della migrazione dati

Il primo obiettivo è migliorare le prestazioni passando a una soluzione di archiviazione più moderna. Il secondo è ridurre i costi operativi cambiando fornitore di infrastruttura. Il terzo è garantire la conformità normativa (GDPR, 152-FZ), quando i dati devono essere archiviati in una giurisdizione specifica.

Come la migrazione differisce dall'integrazione

L'integrazione comporta una sincronizzazione continua tra due sistemi in esecuzione. La migrazione è un trasferimento unico seguito dalla dismissione della fonte. L'integrazione non elimina i dati nella fonte; la migrazione termina con il passaggio del sistema di destinazione allo stato primario. Questa differenza fondamentale determina la scelta degli strumenti e degli approcci di convalida.

Modello ETL di migrazione dati

L'architettura di base di qualsiasi Data Migration si basa sul modello ETL (Extract, Transform, Load). Extract — estrazione dei dati dalla fonte. Transform — conversione nello schema di destinazione. Load — caricamento nella destinazione. Ogni fase ha i propri metodi di controllo qualità.

Extract: estrazione dati

Nella fase di estrazione, i dati vengono letti dal database sorgente, dall'archiviazione file o dall'API. L'estrazione incrementale (CDC — Change Data Capture) consente di trasferire solo i record modificati, riducendo il volume di traffico. Il dump completo è adatto per volumi piccoli, ma per database di terabyte è preferibile la replica in streaming tramite Debezium o Kafka Connect.

Transform: trasformazione dello schema

La trasformazione include la ridenominazione delle colonne, il cambio dei tipi di dati, la normalizzazione dei valori e l'aggregazione. Ad esempio, durante la migrazione da MySQL a PostgreSQL, il tipo numerico DECIMAL deve essere convertito in NUMERIC e il formato della data in ISO 8601. Secondo Talend (2024), il 70% del tempo di migrazione viene speso per la trasformazione, non per il trasferimento.

Load: caricamento nella destinazione

Il caricamento viene eseguito in batch (batch insert) o in streaming. Una chiave di idempotenza viene utilizzata per eliminare i duplicati. Dopo il caricamento, una fase di convalida è obbligatoria: confronto del numero di record, calcolo dei checksum e verifica delle regole aziendali. Senza convalida, la migrazione dati è considerata incompleta.

Strategie di migrazione dati

La scelta della strategia di Data Migration determina il tempo di inattività del sistema, la complessità del rollback e la quantità di lavoro preparatorio. Le strategie principali sono Big Bang, Trickle e Parallel Run. Ciascuna è applicabile in diversi scenari.

Migrazione Big Bang

Big Bang è lo spegnimento unico del vecchio sistema, il trasferimento dei dati e l'avvio del nuovo. Adatto per volumi piccoli e schemi semplici. Rischio: in caso di errore, il sistema non è disponibile fino al completo ripristino dal backup. Nel 2024, GitLab ha utilizzato Big Bang per migrare 5 TB di dati da AWS RDS a GCP Cloud SQL con una finestra di inattività di 14 ore.

Migrazione Trickle

Trickle è una sincronizzazione in streaming in piccole porzioni. I sistemi vecchio e nuovo funzionano in parallelo, le modifiche vengono replicate in tempo reale. Dopo la stabilizzazione dei dati, la vecchia fonte viene disattivata. Questo approccio richiede sincronizzazione bidirezionale e risoluzione dei conflitti. Viene utilizzato in Continuous Delivery durante l'aggiornamento dello schema del database senza tempi di inattività.

Parallel Run

Parallel Run — entrambi i sistemi operano simultaneamente, l'applicazione scrive e legge da entrambe le fonti. Dopo la verifica dei dati sulla destinazione, la vecchia fonte viene disattivata. È la strategia più sicura, ma anche la più costosa — richiede la manutenzione di due infrastrutture. Viene utilizzata durante la migrazione di sistemi finanziari critici.

Tipi di migrazione dati

Nello sviluppo di applicazioni, si distinguono diversi tipi di Data Migration in base all'oggetto di trasferimento e al contesto. Ogni tipo ha la propria metodologia e strumenti. Comprendere il tipo è il primo passo per scegliere la strategia corretta.

Migrazione del database (Database Migration)

Database Migration è il trasferimento tra DBMS di diversi fornitori: da Oracle a PostgreSQL, da SQL Server a MySQL, da MongoDB a DynamoDB. La complessità risiede nell'incompatibilità dei tipi di dati, dei dialetti SQL e dei meccanismi di indicizzazione. Strumenti: AWS DMS, Debezium, Liquibase.

Migrazione dei dati dell'applicazione (Application Data Migration)

Trasferimento di dati tra diverse versioni della stessa applicazione — ad esempio, durante l'aggiornamento del codice con modifiche alla struttura delle entità. Spesso accompagnato dall'esecuzione di script di migrazione nel linguaggio dell'applicazione: Active Record Migrations in Ruby on Rails, Flyway per Java, Entity Framework Migrations in .NET. Questi script trasformano sequenzialmente lo schema e i dati.

Migrazione cloud (Cloud Data Migration)

Cloud Data Migration è il trasferimento di dati dall'infrastruttura on-premise al cloud o tra cloud. AWS Snowball, Azure Data Box e Google Transfer Appliance vengono utilizzati per il trasporto fisico di array di terabyte. Per la migrazione online vengono utilizzati tunnel VPN e replica. Secondo Gartner, entro il 2027, il 70% delle migrazioni verrà eseguito in un ambiente cloud ibrido.

Pianificazione della migrazione dati

Data Migration senza un piano è un fallimento garantito. La pianificazione include l'audit dello schema corrente, la profilazione dei dati, la scelta della strategia, la preparazione dell'ambiente, i test e l'approvazione del piano di rollback. Secondo uno studio di McKinsey (2024), il 54% delle migrazioni fallite è causato dall'assenza di un piano formale.

Audit e profilazione

Prima della migrazione, è necessario eseguire un audit del sistema sorgente: determinare il volume dei dati, il numero di tabelle, le dipendenze tra entità, i tipi di campi nullable e la presenza di duplicati. La profilazione identifica le anomalie — valori NULL nei campi chiave, discrepanze di formato, collegamenti interrotti. Questi dati formano la baseline del dump completo.

Preparazione dell'ambiente di test

Una migrazione di test viene eseguita su una copia dei dati di produzione prima del lancio principale. L'obiettivo è verificare le prestazioni della pipeline ETL, la correttezza della trasformazione e la velocità di caricamento. Si raccomanda un minimo di tre cicli di test completi prima di Big Bang. Ogni ciclo include un trasferimento completo, convalida e rollback.

Piano di rollback

Il rollback è il ritorno al sistema originale quando vengono rilevati errori critici. Il piano di rollback include: backup completo della fonte prima dell'inizio, script di ripristino dello schema, istruzioni passo-passo per riattivare il vecchio sistema e un piano di comunicazione per la notifica degli utenti. Senza un piano di rollback approvato, la migrazione dati non dovrebbe essere avviata in produzione.

Esempi di codice di migrazione dati

Consideriamo un esempio pratico di Data Migration in Kotlin combinato con Flyway. Lo script di migrazione V1 crea una tabella utenti e trasferisce i dati da un formato legacy. Flyway tiene traccia automaticamente delle migrazioni applicate e garantisce l'idempotenza.

// V1__Migrate_Users.kt — migrazione dati dal formato legacy
import org.flywaydb.core.api.migration.BaseJavaMigration
import java.sql.Connection
import java.sql.PreparedStatement

class V1__MigrateUsers : BaseJavaMigration() {
    override fun migrate(connection: Connection) {
        val legacyUsers = connection.prepareStatement(
            "SELECT id, name, legacy_role FROM users_legacy"
        ).executeQuery()

        val insertStmt: PreparedStatement = connection.prepareStatement(
            "INSERT INTO users (id, name, role, migrated_at) VALUES (?, ?, ?, NOW())"
        )

        while (legacyUsers.next()) {
            insertStmt.setInt(1, legacyUsers.getInt("id"))
            insertStmt.setString(2, legacyUsers.getString("name"))
            val role = mapLegacyRole(legacyUsers.getString("legacy_role"))
            insertStmt.setString(3, role)
            insertStmt.executeUpdate()
        }
    }
}

Un esempio di migrazione in Python che utilizza SQLAlchemy per trasferire dati da CSV a PostgreSQL. Lo script estrae dal file, converte i tipi e carica le tabelle di destinazione.

# migrate_data.py — caricamento CSV in PostgreSQL con trasformazione
import pandas as pd
from sqlalchemy import create_engine

engine = create_engine("postgresql://user:pass@host/db")
df = pd.read_csv("legacy_orders.csv")

df["order_date"] = pd.to_datetime(df["order_date"])
df["amount"] = df["amount"].astype("float")
df.to_sql("orders", engine, if_exists="append", index=False)

print("Migrazione dati completata")