Data Migration — essens, metoder och processen för dataöverföring

Vad är Data Migration

Data Migration är processen att överföra data från en källa till en annan med säkerställande av integritet, konsistens och tillgänglighet efter slutförandet. Till skillnad från enkel kopiering innefattar migrering transformering av format, rensning av dubbletter, kontroll av referensintegritet och validering av resultatet.

Behovet av Data Migration uppstår vid uppdatering av DBMS (t.ex. från MySQL 5.7 till MySQL 8.0), byte av molnleverantör, migrering från monolit till mikrotjänster eller vid övergång från schema till NoSQL. Enligt Stripe (2024) stöter 89 % av företagen på datamigrering minst en gång vartannat år, och 43 % anser det vara det svåraste steget i en teknisk uppdatering.

Huvudmål för datamigrering

Det första målet — prestandaökning genom övergång till en modernare lagringslösning. Det andra — minskning av driftskostnader genom byte av infrastrukturleverantör. Det tredje — säkerställande av regelefterlevnad (GDPR, 152-FZ) när data måste lagras inom en viss jurisdiktion.

Skillnad mellan migrering och integration

Integration förutsätter permanent synkronisering mellan två fungerande system. Migrering — engångsöverföring med efterföljande avstängning av källan. Integration tar inte bort data i källan, migrering avslutas med att mottagarsystemet övergår till primary-status. Denna grundläggande skillnad avgör valet av verktyg och valideringsmetoder.

ETL-modell för datamigrering

Grundarkitekturen för varje Data Migration bygger på ETL-modellen (Extract, Transform, Load). Extract — utvinning av data från källan. Transform — omvandling till målschemat. Load — laddning i mottagaren. Varje fas har egna kvalitetskontrollmetoder.

Extract: datautvinning

I utvinningsfasen läses data från källdatabasen, fillagring eller API. Inkrementell export (CDC — Change Data Capture) möjliggör överföring av endast ändrade poster, vilket minskar trafikvolymen. Fullständig dump lämpar sig för små volymer, men för terabyte-databaser föredras strömmande replikering via Debezium eller Kafka Connect.

Transform: schemaomvandling

Omvandling innefattar omdöpning av kolumner, ändring av datatyper, normalisering av värden och aggregering. Till exempel vid migrering från MySQL till PostgreSQL måste numerisk typ DECIMAL konverteras till NUMERIC och datumformat till ISO 8601. Enligt Talend (2024) går 70 % av migreringstiden åt till transformering, inte överföring.

Load: laddning i mottagaren

Laddning utförs i batchar (batch insert) eller strömmande. För att eliminera dubbletter används en idempotensnyckel. Efter laddning krävs ett obligatoriskt valideringssteg: jämförelse av antal poster, beräkning av kontrollsummor och kontroll av affärsregler. Utan validering anses Data Migration vara ofullständig.

Strategier för datamigrering

Valet av Data Migration-strategi bestämmer systemets stilleståndstid, återställningens komplexitet och omfattningen av förberedande arbete. Huvudstrategierna — Big Bang, Trickle och parallellkörning (Parallel Run). Varje är tillämplig i olika scenarier.

Big Bang-migrering

Big Bang — engångsavstängning av det gamla systemet, dataöverföring och påslagning av det nya. Lämpligt för små volymer och enkla scheman. Risk: vid fel är systemet otillgängligt tills fullständig återställning från säkerhetskopia. Under 2024 använde GitLab Big Bang för migrering av 5 TB data från AWS RDS till GCP Cloud SQL med ett stilleståndsfönster på 14 timmar.

Trickle-migrering

Trickle — kontinuerlig synkronisering i små portioner. Gamla och nya systemet arbetar parallellt, ändringar replikeras i realtid. Efter stabilisering av data stängs den gamla källan av. Denna metod kräver dubbelriktad synkronisering och konfliktlösning. Används inom Continuous Delivery vid uppdatering av databasschema utan stillestånd.

Parallel Run

Parallel Run — båda systemen arbetar samtidigt, applikationen skriver och läser från båda källorna. Efter verifiering av data i mottagaren stängs den gamla källan av. Detta är den säkraste strategin, men också den dyraste — kräver underhåll av två infrastrukturer. Tillämpas vid migrering av kritiska finansiella system.

Typer av datamigrering

I applikationsutveckling särskiljs flera typer av Data Migration baserat på överföringsobjekt och sammanhang. Varje typ har egen metodologi och egna verktyg. Att förstå typen är första steget mot att välja rätt strategi.

Databasmigrering (Database Migration)

Database Migration — överföring mellan DBMS från olika leverantörer: från Oracle till PostgreSQL, från SQL Server till MySQL, från MongoDB till DynamoDB. Komplexiteten ligger i inkompatibilitet mellan datatyper, SQL-dialekter och indexeringsmekanismer. Verktyg: AWS DMS, Debezium, Liquibase.

Applikationsdatamigrering (Application Data Migration)

Dataöverföring mellan olika versioner av samma applikation — till exempel vid koduppdatering med ändring av entitetsstruktur. Åtföljs ofta av exekvering av migreringsskript på applikationsspråket: Active Record Migrations i Ruby on Rails, Flyway för Java, Entity Framework Migrations i .NET. Dessa skript transformerar sekventiellt schema och data.

Molnmigrering (Cloud Data Migration)

Cloud Data Migration — överföring av data från on-premise-infrastruktur till molnet eller mellan moln. AWS Snowball, Azure Data Box och Google Transfer Appliance används för fysisk transport av terabyte-volymer. För onlinemigrering används VPN-tunnlar och replikering. Enligt Gartner kommer 70 % av migreringarna att utföras i hybrid molnmiljö till 2027.

Planering av datamigrering

Data Migration utan plan — garanterat misslyckande. Planering innefattar granskning av nuvarande schema, dataprofilering, strategival, miljöförberedelse, testning och godkännande av återställningsplan. Enligt McKinsey (2024) orsakas 54 % av misslyckade migreringar av avsaknad av formell plan.

Granskning och profilering

Före migrering måste en granskning av källsystemet utföras: bestämma datavolym, antal tabeller, beroenden mellan entiteter, typer av nullable-fält och förekomst av dubbletter. Profilering avslöjar avvikelser — NULL-värden i nyckelfält, formatinkonsekvenser, trasiga referenser. Dessa data utgör baslinjen för fullständig dump.

Förberedelse av testmiljö

Testmigrering utförs på en kopia av produktionsdata före huvudkörningen. Syfte — kontrollera ETL-pipeline-prestanda, korrekthet av transformering och laddningshastighet. Minst tre fullständiga cykler testning rekommenderas före Big Bang. Varje cykel innefattar fullständig överföring, validering och återställning.

Återställningsplan (Rollback)

Återställning — återgång till ursprungligt system vid upptäckt av kritiska fel. Återställningsplanen inkluderar: fullständig säkerhetskopia av källan före start, skript för schemåterställning, steg-för-steg-instruktion för att starta gamla systemet och kommunikationsplan för användare. Utan godkänd återställningsplan bör Data Migration inte köras i produktion.

Kodexempel för datamigrering

Låt oss titta på ett praktiskt exempel på Data Migration i Kotlin i kombination med Flyway. Migreringsskriptet V1 skapar tabellen users och överför data från legacy-format. Flyway spårar automatiskt tillämpade migreringar och garanterar idempotens.

// V1__Migrate_Users.kt — datamigrering från legacy-format
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()
        }
    }
}

Exempel på migrering i Python med SQLAlchemy för överföring av data från CSV till PostgreSQL. Skriptet utför utvinning från fil, konverterar typer och laddar måltabellerna.

# migrate_data.py — laddning av CSV till PostgreSQL med transformering
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 slutförd")