Data Migration — essence, méthodes et processus de transfert de données

Qu'est-ce que Data Migration

Data Migration est le processus de transfert de données d'une source à une autre en garantissant leur intégrité, leur cohérence et leur disponibilité après l'achèvement. Contrairement à une simple copie, la migration comprend la transformation de formats, la suppression de doublons, la vérification de l'intégrité référentielle et la validation des résultats.

Le besoin de Data Migration survient lors de la mise à jour d'un SGBD (par exemple, de MySQL 5.7 à MySQL 8.0), du changement de fournisseur de cloud, de la migration d'un monolithe vers des microservices ou du passage à un schéma NoSQL. Selon Stripe (2024), 89 % des entreprises sont confrontées à une migration de données au moins une fois tous les deux ans, et 43 % la considèrent comme l'étape la plus difficile d'une mise à jour technique.

Principaux objectifs de la migration de données

Le premier objectif est d'améliorer les performances en passant à une solution de stockage plus moderne. Le deuxième est de réduire les coûts opérationnels lors du changement de fournisseur d'infrastructure. Le troisième est d'assurer la conformité réglementaire (RGPD, 152-FZ), lorsque les données doivent être stockées dans une juridiction spécifique.

En quoi la migration diffère de l'intégration

L'intégration implique une synchronisation continue entre deux systèmes en fonctionnement. La migration est un transfert unique suivi du décommissionnement de la source. L'intégration ne supprime pas les données à la source ; la migration se termine par la transition du système cible en état primaire. Cette différence fondamentale détermine le choix des outils et des approches de validation.

Modèle ETL de migration de données

L'architecture de base de toute Data Migration repose sur le modèle ETL (Extract, Transform, Load). Extract — extraction des données de la source. Transform — conversion vers le schéma cible. Load — chargement dans la destination. Chaque phase a ses propres méthodes de contrôle qualité.

Extract : extraction de données

Lors de la phase d'extraction, les données sont lues à partir de la base de données source, du stockage de fichiers ou de l'API. L'extraction incrémentielle (CDC — Change Data Capture) permet de transférer uniquement les enregistrements modifiés, réduisant ainsi le volume de trafic. Le vidage complet convient aux petits volumes, mais pour les bases de données de plusieurs téraoctets, la réplication en streaming via Debezium ou Kafka Connect est préférable.

Transform : transformation du schéma

La transformation comprend le renommage de colonnes, le changement de types de données, la normalisation de valeurs et l'agrégation. Par exemple, lors de la migration de MySQL vers PostgreSQL, le type numérique DECIMAL doit être converti en NUMERIC et le format de date en ISO 8601. Selon Talend (2024), 70 % du temps de migration est consacré à la transformation, pas au transfert.

Load : chargement dans la destination

Le chargement est effectué par lots (batch insert) ou en streaming. Une clé d'idempotence est utilisée pour éliminer les doublons. Après le chargement, une étape de validation est obligatoire : comparaison du nombre d'enregistrements, calcul des sommes de contrôle et vérification des règles métier. Sans validation, la migration de données est considérée comme incomplète.

Stratégies de migration de données

Le choix de la stratégie de Data Migration détermine le temps d'arrêt du système, la complexité de la restauration et la quantité de travail préparatoire. Les principales stratégies sont Big Bang, Trickle et Parallel Run. Chacune est applicable dans différents scénarios.

Migration Big Bang

Big Bang est l'arrêt unique de l'ancien système, le transfert de données et le démarrage du nouveau. Convient aux petits volumes et aux schémas simples. Risque : en cas d'échec, le système est indisponible jusqu'à la restauration complète à partir de la sauvegarde. En 2024, GitLab a utilisé Big Bang pour migrer 5 To de données d'AWS RDS vers GCP Cloud SQL avec une fenêtre d'arrêt de 14 heures.

Migration Trickle

Trickle est une synchronisation en streaming par petites portions. Les systèmes ancien et nouveau fonctionnent en parallèle, les modifications sont répliquées en temps réel. Après la stabilisation des données, l'ancienne source est arrêtée. Cette approche nécessite une synchronisation bidirectionnelle et une résolution de conflits. Elle est utilisée en Continuous Delivery lors de la mise à jour du schéma de base de données sans temps d'arrêt.

Parallel Run

Parallel Run — les deux systèmes fonctionnent simultanément, l'application écrit et lit sur les deux sources. Après vérification des données sur la destination, l'ancienne source est arrêtée. C'est la stratégie la plus sûre, mais aussi la plus coûteuse — elle nécessite la maintenance de deux infrastructures. Elle est utilisée lors de la migration de systèmes financiers critiques.

Types de migration de données

Dans le développement d'applications, plusieurs types de Data Migration sont distingués selon l'objet de transfert et le contexte. Chaque type a sa propre méthodologie et ses propres outils. Comprendre le type est la première étape vers le choix de la stratégie correcte.

Migration de base de données (Database Migration)

Database Migration est le transfert entre SGBD de différents fournisseurs : d'Oracle à PostgreSQL, de SQL Server à MySQL, de MongoDB à DynamoDB. La complexité réside dans l'incompatibilité des types de données, des dialectes SQL et des mécanismes d'indexation. Outils : AWS DMS, Debezium, Liquibase.

Migration de données d'application (Application Data Migration)

Transfert de données entre différentes versions d'une même application — par exemple, lors de la mise à jour du code avec des modifications de la structure des entités. Souvent accompagné de l'exécution de scripts de migration dans le langage de l'application : Active Record Migrations en Ruby on Rails, Flyway pour Java, Entity Framework Migrations en .NET. Ces scripts transforment séquentiellement le schéma et les données.

Migration cloud (Cloud Data Migration)

Cloud Data Migration est le transfert de données de l'infrastructure sur site vers le cloud ou entre clouds. AWS Snowball, Azure Data Box et Google Transfer Appliance sont utilisés pour le transport physique d'ensembles de téraoctets. Pour la migration en ligne, des tunnels VPN et la réplication sont utilisés. Selon Gartner, d'ici 2027, 70 % des migrations seront effectuées dans un environnement cloud hybride.

Planification de la migration de données

Data Migration sans plan est un échec garanti. La planification comprend l'audit du schéma actuel, le profilage des données, le choix de la stratégie, la préparation de l'environnement, les tests et l'approbation du plan de restauration. Selon une étude de McKinsey (2024), 54 % des migrations échouées sont dues à l'absence d'un plan formel.

Audit et profilage

Avant la migration, il est nécessaire d'auditer le système source : déterminer le volume de données, le nombre de tables, les dépendances entre entités, les types de champs nullables et la présence de doublons. Le profilage identifie les anomalies — valeurs NULL dans les champs clés, décalages de format, liens brisés. Ces données constituent la base de référence du vidage complet.

Préparation de l'environnement de test

Une migration de test est effectuée sur une copie des données de production avant le lancement principal. L'objectif est de vérifier les performances du pipeline ETL, l'exactitude de la transformation et la vitesse de chargement. Un minimum de trois cycles de test complets est recommandé avant Big Bang. Chaque cycle comprend un transfert complet, une validation et une restauration.

Plan de restauration (Rollback)

La restauration est le retour au système d'origine lorsque des erreurs critiques sont détectées. Le plan de restauration comprend : une sauvegarde complète de la source avant le début, des scripts de récupération du schéma, une instruction étape par étape pour réactiver l'ancien système et un plan de communication pour la notification des utilisateurs. Sans plan de restauration approuvé, la migration de données ne doit pas être lancée en production.

Exemples de code de migration de données

Considérons un exemple pratique de Data Migration en Kotlin combiné avec Flyway. Le script de migration V1 crée une table utilisateurs et transfère les données d'un format legacy. Flyway suit automatiquement les migrations appliquées et garantit l'idempotence.

// V1__Migrate_Users.kt — migration de données depuis le format 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 exemple de migration en Python utilisant SQLAlchemy pour transférer des données de CSV vers PostgreSQL. Le script extrait du fichier, convertit les types et charge les tables cibles.

# migrate_data.py — chargement du CSV dans PostgreSQL avec transformation
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("Migration de données terminée")