Belajar Data Architect - Migration & Modernization

#Pendahuluan

Setelah di episode 14 kita menguasai biaya, sekarang kita menghadapi kenyataan banyak organisasi: sistem lama yang harus dimodernisasi. Warehouse on-prem yang berumur 15 tahun, pipeline shell script yang dijaga satu orang, atau ETL yang hanya dipahami penulis aslinya yang sudah pindah. Modernisasi adalah proyek arsitektur paling menantang — dan paling sering gagal.

Mengapa episode ini penting? Karena sebagian besar kesalahan migrasi bukan teknis, tapi strategis: berpindah semua sekaligus, tidak punya rollback, atau mengukur keberhasilan dengan tolok ukur yang salah. Arsitek yang merancang migrasi dengan benar menyelamatkan organisasi dari proyek 2 tahun yang macet di tengah jalan.

#Empat Strategi Migrasi (6R dari AWS)

Kerangka paling umum adalah 6R — model untuk berpindah ke cloud. Kuncinya: tidak semua sistem harus dimigrasi dengan cara yang sama.

Strategi	Arti	Kapan Dipakai
Rehost (lift & shift)	Pindahkan apa adanya	Cepat, biaya minimal, deadline ketat
Replatform	Pindah + tweak kecil (misal pakai managed service)	Menengah; butuh benefit managed
Refactor	Tulis ulang arsitektur	Sistem lama sudah tak bisa berkembang
Repurchase	Ganti dengan SaaS	Ada produk jadi yang lebih baik
Retain	Biarkan di tempat	Belum worth memindah
Retire	Matikan	Tidak ada yang memakai

Keputusan per sistem

sistem                  strategi   alasan
ETL batch legacy        Refactor   sudah tidak bisa diubah tanpa risiko
Oracle warehouse        Replatform pindah ke managed, skema dipertahankan
Report harian shell     Retain     masih jalan, pengguna 3 orang
Aplikasi BI lama        Repurchase ganti BI modern
RDS lama tanpa owner    Retire     tidak ada konsumen selama 6 bulan

#Refactoring Pipeline Legacy

Pipeline legacy biasanya berisi business logic tersembunyi — aturan yang tidak terdokumentasi dan hanya diketahui lewat trial & error. Memindahkan logic ke platform baru tanpa memindahkan maknanya adalah sumber bug paling umum.

#Pola refactor yang aman

Pola strangler: pelan-pelan memindahkan fungsionalitas dari sistem lama ke sistem baru, di balik interface yang sama, sampai sistem lama bisa dimatikan.

Strangler pattern untuk pipeline

masa 1: aplikasi lama → pipeline lama → warehouse lama
masa 2: aplikasi lama → pipeline lama + pipeline baru (paralel, validasi)
masa 3: switchover: pipeline baru jadi sumber kebenaran
masa 4: matikan pipeline lama

Pola parallel run + validasi: jalankan pipeline baru paralel dengan yang lama untuk periode tertentu, lalu bandingkan outputnya.

Validasi paralel

out_lama   = legacy_pipeline.run(tanggal)
out_baru   = new_pipeline.run(tanggal)
assert set(out_lama.keys()) == set(out_baru.keys())
for k: toleransi per kolom (misal revenue selisih < 0.01%)

Masa paralel adalah jaring pengaman: kalau output berbeda, arsitek bisa bedah sebelum membuang sistem lama.

Warning

Jangan percaya begitu saja bahwa sistem lama itu "benar". Sebelum menjadikannya referensi validasi, audit dulu logika lama: baris yang di-skip, filter tersembunyi, dan timezone yang membingungkan. Sering kali "sistem baru yang salah" sebenarnya "sistem lama yang selama ini salah, dan baru terlihat".

#Integrasi Sistem Legacy

Sistem lama jarang bisa dihapus seketika — ia harus berjalan bersama sistem baru. Pola integrasi:

#1. CDC dari Legacy ke Platform Baru

Jangan biarkan warehouse baru membaca langsung tabel legacy setiap query. Alirkan perubahan via CDC (episode 7) ke lakehouse, dan jadikan itu sumber tunggal.

#2. API Wrapper

Bungkus sistem legacy dengan API agar konsumen baru tidak bergantung pada protokol lamanya. Interface tetap, internal bisa diganti nanti.

#3. Data Contract sebagai Jembatan

Terapkan kontrak data (episode 13) pada antarmuka dengan sistem lama — siapa yang menulis, format apa, dan jaminan apa.

#Menyusun Rencana Migrasi

#Step 1: Inventarisasi Lengkap

Daftar semua aset, ketergantungan, dan pemilik. Ini yang paling sering dilewatkan — dan penyebab utama "ternyata masih ada yang pakai sistem ini".

Inventaris migrasi

sistem | pemilik | konsumen | data_kritis | strategi | effort | risiko

#Step 2: Tentukan Urutan

Migrasi urut dari yang paling rendah risiko dan paling sedikit dependensi. Jangan mulai dari sistem paling kritikal.

#Step 3: Tetapkan Tolok Ukur Keberhasilan

Bukan hanya "data pindah", tapi: query X selesai dalam Y detik dengan biaya Z. Bandingkan sebelum/sesudah dengan angka nyata.

#Step 4: Rencanakan Rollback

Setiap fase harus punya cara kembali ke kondisi sebelumnya. Tanpa rollback, satu bug kecil bisa mengubah migrasi berbulan-bulan menjadi krisis darurat.

#Step 5: Migrate Data dengan Verifikasi

Lakukan migrasi data bertahap: pilih rentang waktu (misal 3 bulan), bandingkan row count + checksum + sample, baru lanjut rentang berikutnya.

Verifikasi migrasi data

- row count per partisi sama persis
- checksum/aggregate (SUM, COUNT DISTINCT) identik
- sample 10k baris dibandingkan kolom per kolom
- jadwal & SLA di target terpenuhi

Tip

Pilih satu sistem kecil yang kurang penting sebagai pilot migrasi penuh — dari inventaris sampai cutover. Pelajaran dari pilot (logika tersembunyi, orang yang harus dilibatkan, approval berapa lama) akan membuat migrasi sistem besar jauh lebih mulus.

#Penutup

Inti yang harus dibawa pulang:

Pilih strategi per sistem: rehost, replatform, refactor, repurchase, retain, retire.
Refactor pakai strangler pattern dan parallel run + validasi sebagai jaring pengaman.
Integrasi legacy via CDC, API wrapper, dan data contract.
Rencana migrasi = inventarisasi → urutan → tolok ukur → rollback → verifikasi data.
Pilot kecil dulu, pelajari, baru migrasi sistem besar.

Di episode 16 selanjutnya kita akan membahas Data Integration & Interop — ETL vs ELT, API, dan pola integrasi antar sistem yang membuat data mengalir konsisten. Sampai jumpa di episode 16!