Data Migration — esensi, metode dan proses pemindahan data

Apa itu Data Migration

Data Migration adalah proses pemindahan data dari satu sumber ke sumber lain dengan memastikan integritas, konsistensi, dan ketersediaannya setelah selesai. Berbeda dengan penyalinan sederhana, migrasi mencakup transformasi format, pembersihan duplikat, pemeriksaan integritas referensial, dan validasi hasil.

Kebutuhan akan Data Migration muncul saat memperbarui DBMS (misalnya dari MySQL 5.7 ke MySQL 8.0), berganti penyedia cloud, migrasi dari monolit ke mikroservis, atau saat beralih dari skema ke NoSQL. Menurut Stripe (2024), 89% perusahaan menghadapi migrasi data setidaknya sekali dalam dua tahun, dan 43% menganggapnya sebagai tahap pembaruan teknis yang paling sulit.

Tujuan utama migrasi data

Tujuan pertama — peningkatan kinerja dengan beralih ke solusi penyimpanan yang lebih modern. Kedua — pengurangan biaya operasional dengan mengganti penyedia infrastruktur. Ketiga — memastikan kepatuhan terhadap persyaratan regulasi (GDPR, 152-FZ) ketika data harus disimpan di yurisdiksi tertentu.

Perbedaan migrasi dengan integrasi

Integrasi mengasumsikan sinkronisasi permanen antara dua sistem yang berjalan. Migrasi — pemindahan satu kali dengan penonaktifan sumber selanjutnya. Integrasi tidak menghapus data di sumber, migrasi berakhir dengan mengalihkan sistem penerima ke status primary. Perbedaan fundamental ini menentukan pilihan alat dan pendekatan validasi.

Model ETL migrasi data

Arsitektur dasar setiap Data Migration didasarkan pada model ETL (Extract, Transform, Load). Extract — ekstraksi data dari sumber. Transform — transformasi ke skema target. Load — pemuatan ke penerima. Setiap fase memiliki metode kontrol kualitasnya sendiri.

Extract: ekstraksi data

Pada tahap ekstraksi, data dibaca dari basis data sumber, penyimpanan file, atau API. Pembongkaran inkremental (CDC — Change Data Capture) memungkinkan pemindahan hanya catatan yang diubah, mengurangi volume lalu lintas. Dump penuh cocok untuk volume kecil, tetapi untuk basis data terabyte, replikasi streaming melalui Debezium atau Kafka Connect lebih disukai.

Transform: transformasi skema

Transformasi mencakup penggantian nama kolom, perubahan tipe data, normalisasi nilai, dan agregasi. Misalnya, saat migrasi dari MySQL ke PostgreSQL, tipe numerik DECIMAL harus diubah ke NUMERIC, dan format tanggal — ke ISO 8601. Menurut Talend (2024), 70% waktu migrasi dihabiskan untuk transformasi, bukan pemindahan.

Load: pemuatan ke penerima

Pemuatan dilakukan secara batch (batch insert) atau streaming. Untuk menghilangkan duplikat, digunakan kunci idempotensi. Setelah pemuatan, langkah validasi wajib dilakukan: perbandingan jumlah catatan, perhitungan checksum, dan pemeriksaan aturan bisnis. Tanpa validasi, Data Migration dianggap tidak selesai.

Strategi migrasi data

Pilihan strategi Data Migration menentukan waktu henti sistem, kompleksitas rollback, dan volume pekerjaan persiapan. Strategi utama — Big Bang, Trickle, dan pelaksanaan paralel (Parallel Run). Masing-masing dapat diterapkan dalam skenario yang berbeda.

Migrasi Big Bang

Big Bang — penonaktifan satu kali sistem lama, pemindahan data, dan pengaktifan sistem baru. Cocok untuk volume kecil dan skema sederhana. Risiko: jika terjadi kegagalan, sistem tidak tersedia hingga pemulihan penuh dari cadangan. Pada tahun 2024, GitLab menggunakan Big Bang untuk memigrasi 5 TB data dari AWS RDS ke GCP Cloud SQL dengan jendela waktu henti 14 jam.

Migrasi Trickle

Trickle — sinkronisasi berkelanjutan dalam porsi kecil. Sistem lama dan baru berjalan paralel, perubahan direplikasi secara real-time. Setelah data stabil, sumber lama dinonaktifkan. Pendekatan ini memerlukan sinkronisasi dua arah dan resolusi konflik. Digunakan dalam Continuous Delivery saat memperbarui skema basis data tanpa waktu henti.

Parallel Run

Parallel Run — kedua sistem berjalan bersamaan, aplikasi menulis dan membaca dari kedua sumber. Setelah verifikasi data di penerima, sumber lama dinonaktifkan. Ini adalah strategi teraman, tetapi juga termahal — memerlukan pemeliharaan dua infrastruktur. Diterapkan pada migrasi sistem keuangan kritis.

Jenis migrasi data

Dalam pengembangan aplikasi, beberapa jenis Data Migration dibedakan berdasarkan objek pemindahan dan konteks. Setiap jenis memiliki metodologi dan alatnya sendiri. Memahami jenisnya adalah langkah pertama menuju pemilihan strategi yang tepat.

Migrasi basis data (Database Migration)

Database Migration — pemindahan antar DBMS dari vendor berbeda: dari Oracle ke PostgreSQL, dari SQL Server ke MySQL, dari MongoDB ke DynamoDB. Kompleksitasnya terletak pada ketidakcocokan tipe data, dialek SQL, dan mekanisme pengindeksan. Alat: AWS DMS, Debezium, Liquibase.

Migrasi data aplikasi (Application Data Migration)

Pemindahan data antar versi berbeda dari aplikasi yang sama — misalnya, saat memperbarui kode dengan perubahan struktur entitas. Sering disertai dengan menjalankan skrip migrasi dalam bahasa aplikasi: Active Record Migrations di Ruby on Rails, Flyway untuk Java, Entity Framework Migrations di .NET. Skrip ini secara berurutan mentransformasi skema dan data.

Migrasi cloud (Cloud Data Migration)

Cloud Data Migration — pemindahan data dari infrastruktur on-premise ke cloud atau antar cloud. AWS Snowball, Azure Data Box, dan Google Transfer Appliance digunakan untuk transportasi fisik volume terabyte. Untuk migrasi online, digunakan terowongan VPN dan replikasi. Menurut Gartner, pada tahun 2027 70% migrasi akan dilakukan di lingkungan cloud hibrida.

Perencanaan migrasi data

Data Migration tanpa rencana — kegagalan terjamin. Perencanaan mencakup audit skema saat ini, profiling data, pemilihan strategi, persiapan lingkungan, pengujian, dan persetujuan rencana rollback. Menurut penelitian McKinsey (2024), 54% migrasi yang gagal disebabkan oleh tidak adanya rencana formal.

Audit dan profiling

Sebelum migrasi, perlu dilakukan audit sistem sumber: menentukan volume data, jumlah tabel, dependensi antar entitas, tipe bidang nullable, dan keberadaan duplikat. Profiling mengungkapkan anomali — nilai NULL di bidang kunci, ketidaksesuaian format, referensi rusak. Data ini membentuk baseline dari dump penuh.

Persiapan lingkungan pengujian

Migrasi pengujian dilakukan pada salinan data produksi sebelum pelaksanaan utama. Tujuannya — memeriksa kinerja pipeline ETL, kebenaran transformasi, dan kecepatan pemuatan. Disarankan setidaknya tiga siklus penuh pengujian sebelum Big Bang. Setiap siklus mencakup pemindahan penuh, validasi, dan rollback.

Rencana rollback

Rollback — kembali ke sistem asli saat mendeteksi kesalahan kritis. Rencana rollback mencakup: cadangan penuh sumber sebelum dimulai, skrip pemulihan skema, instruksi langkah demi langkah untuk mengaktifkan sistem lama, dan rencana komunikasi dengan pengguna. Tanpa rencana rollback yang disetujui, Data Migration tidak boleh dijalankan di produksi.

Contoh kode migrasi data

Mari kita lihat contoh praktis Data Migration di Kotlin yang dikombinasikan dengan Flyway. Skrip migrasi V1 membuat tabel users dan memindahkan data dari format lama. Flyway secara otomatis melacak migrasi yang diterapkan dan menjamin idempotensi.

// V1__Migrate_Users.kt — migrasi data dari format lama
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()
        }
    }
}

Contoh migrasi di Python menggunakan SQLAlchemy untuk memindahkan data dari CSV ke PostgreSQL. Skrip melakukan ekstraksi dari file, mengonversi tipe, dan memuat tabel target.

# migrate_data.py — memuat CSV ke PostgreSQL dengan transformasi
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 selesai")