Data Migration — essentie, methoden en het proces van gegevensoverdracht

Wat is Data Migration

Data Migration is het proces van het overbrengen van gegevens van de ene bron naar de andere, met waarborging van hun integriteit, consistentie en beschikbaarheid na voltooiing. In tegenstelling tot eenvoudig kopiëren omvat migratie transformatie van formaten, opschonen van duplicaten, controleren van referentiële integriteit en validatie van het resultaat.

De behoefte aan Data Migration ontstaat bij het updaten van een DBMS (bijv. van MySQL 5.7 naar MySQL 8.0), het wisselen van cloudprovider, migratie van monolith naar microservices of bij overgang van schema naar NoSQL. Volgens Stripe (2024) heeft 89% van de bedrijven ten minste eens in de twee jaar te maken met gegevensmigratie en 43% beschouwt het als de moeilijkste fase van een technische update.

Belangrijkste doelen van gegevensmigratie

Het eerste doel — prestatieverbetering door over te stappen op een modernere opslagoplossing. Het tweede — verlaging van operationele kosten door het wisselen van infrastructuurprovider. Het derde — naleving van wettelijke vereisten (AVG, 152-FZ) wanneer gegevens in een bepaalde jurisdictie moeten worden opgeslagen.

Verschil tussen migratie en integratie

Integratie veronderstelt permanente synchronisatie tussen twee werkende systemen. Migratie — eenmalige overdracht met daaropvolgende uitschakeling van de bron. Integratie verwijdert geen gegevens in de bron, migratie eindigt met het overschakelen van het ontvangende systeem naar de primary-status. Dit fundamentele verschil bepaalt de keuze van hulpmiddelen en validatiebenaderingen.

ETL-model voor gegevensmigratie

De basisarchitectuur van elke Data Migration is gebaseerd op het ETL-model (Extract, Transform, Load). Extract — het ophalen van gegevens uit de bron. Transform — omzetting naar het doelschema. Load — laden in de ontvanger. Elke fase heeft zijn eigen kwaliteitscontrole methoden.

Extract: gegevens ophalen

In de extractiefase worden gegevens gelezen uit de brondatabase, bestandsopslag of API. Incrementele export (CDC — Change Data Capture) maakt het mogelijk alleen gewijzigde records over te brengen, waardoor het verkeersvolume afneemt. Een volledige dump is geschikt voor kleine volumes, maar voor databases van terabytes heeft streaming replicatie via Debezium of Kafka Connect de voorkeur.

Transform: schema transformatie

Transformatie omvat het hernoemen van kolommen, wijzigen van gegevenstypen, normaliseren van waarden en aggregatie. Bij migratie van MySQL naar PostgreSQL moet bijvoorbeeld het numerieke type DECIMAL worden omgezet naar NUMERIC en het datumformaat naar ISO 8601. Volgens Talend (2024) gaat 70% van de migratietijd naar transformatie, niet naar overdracht.

Load: laden in de ontvanger

Het laden gebeurt in batches (batch insert) of streaming. Voor het elimineren van duplicaten wordt een idempotentiesleutel gebruikt. Na het laden is een validatiestap verplicht: vergelijking van het aantal records, berekening van checksums en controle van bedrijfsregels. Zonder validatie wordt Data Migration als onvolledig beschouwd.

Strategieën voor gegevensmigratie

De keuze van de Data Migration strategie bepaalt de stilstandtijd van het systeem, de complexiteit van terugrollen en de omvang van het voorbereidende werk. De belangrijkste strategieën — Big Bang, Trickle en parallelle uitvoering (Parallel Run). Elk is toepasbaar in verschillende scenario's.

Big Bang migratie

Big Bang — eenmalige uitschakeling van het oude systeem, gegevensoverdracht en inschakeling van het nieuwe. Geschikt voor kleine volumes en eenvoudige schema's. Risico: bij een storing is het systeem niet beschikbaar tot volledig herstel uit backup. In 2024 gebruikte GitLab Big Bang voor de migratie van 5 TB aan gegevens van AWS RDS naar GCP Cloud SQL met een stilstandvenster van 14 uur.

Trickle migratie

Trickle — doorlopende synchronisatie in kleine porties. Het oude en nieuwe systeem werken parallel, wijzigingen worden in realtime gerepliceerd. Na stabilisatie van de gegevens wordt de oude bron uitgeschakeld. Deze aanpak vereist bidirectionele synchronisatie en conflictoplossing. Wordt gebruikt in Continuous Delivery bij het updaten van een databaseschema zonder stilstand.

Parallel Run

Parallel Run — beide systemen werken gelijktijdig, de applicatie schrijft en leest uit beide bronnen. Na verificatie van de gegevens in de ontvanger wordt de oude bron uitgeschakeld. Dit is de veiligste strategie, maar ook de duurste — vereist onderhoud van twee infrastructuren. Wordt toegepast bij migratie van kritieke financiële systemen.

Soorten gegevensmigratie

In applicatieontwikkeling worden verschillende soorten Data Migration onderscheiden op basis van het overdrachtsobject en de context. Elk type heeft zijn eigen methodologie en hulpmiddelen. Inzicht in het type is de eerste stap naar het kiezen van de juiste strategie.

Databasemigratie (Database Migration)

Database Migration — overdracht tussen DBMS'en van verschillende leveranciers: van Oracle naar PostgreSQL, van SQL Server naar MySQL, van MongoDB naar DynamoDB. De complexiteit zit in de incompatibiliteit van gegevenstypen, SQL-dialecten en indexeringsmechanismen. Hulpmiddelen: AWS DMS, Debezium, Liquibase.

Applicatiegegevensmigratie (Application Data Migration)

Overdracht van gegevens tussen verschillende versies van dezelfde applicatie — bijvoorbeeld bij het updaten van code met wijziging van de entiteitsstructuur. Gaat vaak gepaard met het uitvoeren van migratiescripts in de applicatietaal: Active Record Migrations in Ruby on Rails, Flyway voor Java, Entity Framework Migrations in .NET. Deze scripts transformeren achtereenvolgens het schema en de gegevens.

Cloudmigratie (Cloud Data Migration)

Cloud Data Migration — overdracht van gegevens van on-premise infrastructuur naar de cloud of tussen clouds. AWS Snowball, Azure Data Box en Google Transfer Appliance worden gebruikt voor fysiek transport van terabytes aan data. Voor online migratie worden VPN-tunnels en replicatie gebruikt. Volgens Gartner zal 70% van de migraties tegen 2027 worden uitgevoerd in een hybride cloudomgeving.

Planning van gegevensmigratie

Data Migration zonder plan — gegarandeerd falen. Planning omvat audit van het huidige schema, dataprofilering, strategiekeuze, omgevingsvoorbereiding, testen en goedkeuring van het terugrolplan. Volgens onderzoek van McKinsey (2024) wordt 54% van de mislukte migraties veroorzaakt door het ontbreken van een formeel plan.

Audit en profilering

Voor de migratie moet een audit van het bronsysteem worden uitgevoerd: bepaling van het gegevensvolume, aantal tabellen, afhankelijkheden tussen entiteiten, typen nullable-velden en aanwezigheid van duplicaten. Profilering brengt afwijkingen aan het licht — NULL-waarden in sleutelvelden, formaatinconsistenties, kapotte verwijzingen. Deze gegevens vormen de baseline van de volledige dump.

Voorbereiding van de testomgeving

Testmigratie wordt uitgevoerd op een kopie van productiegegevens vóór de hoofdimplementatie. Doel — testen van de ETL-pijplijnprestaties, correctheid van transformatie en laadsnelheid. Ten minste drie volledige cycli van testen worden aanbevolen vóór Big Bang. Elke cyclus omvat volledige overdracht, validatie en terugrol.

Terugrolplan (Rollback)

Terugrol — terugkeer naar het oorspronkelijke systeem bij detectie van kritieke fouten. Het terugrolplan omvat: volledige backup van de bron voor de start, herstelscripts voor het schema, stapsgewijze instructies voor het inschakelen van het oude systeem en een communicatieplan voor gebruikers. Zonder goedgekeurd terugrolplan mag Data Migration niet in productie worden genomen.

Codevoorbeelden van gegevensmigratie

Laten we een praktisch voorbeeld van Data Migration in Kotlin in combinatie met Flyway bekijken. Het V1-migratiescript maakt de tabel users aan en brengt gegevens over uit legacy-formaat. Flyway houdt toegepaste migraties automatisch bij en garandeert idempotentie.

// V1__Migrate_Users.kt — gegevensmigratie van legacy-formaat
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()
        }
    }
}

Voorbeeld van migratie in Python met SQLAlchemy voor het overbrengen van gegevens uit CSV naar PostgreSQL. Het script voert extractie uit het bestand uit, converteert types en laadt de doeltabellen.

# migrate_data.py — CSV laden in PostgreSQL met transformatie
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("Data Migration voltooid")