Saat sebuah bisnis mengganti sistem lama, semua orang membicarakan software baru yang berkilau. Demonya terlihat hebat, dek presentasi sales menjanjikan transisi yang mulus, dan anggaran sudah mencakup lisensi serta training. Lalu kenyataan datang, dan wujudnya adalah data. Panduan migrasi data legacy ini membahas bagian proyek yang tidak pernah dianggarkan siapa pun dan selalu diremehkan semua orang: memindahkan sepuluh tahun catatan berantakan ke sistem baru tanpa merusak bisnis.

Saya sudah menyaksikan lebih banyak penggantian sistem tersandung karena data dibanding karena kekurangan fitur. Sistem barunya baik-baik saja. Masalahnya adalah data lama tidak pernah sebersih yang dikira semua orang, dan proses memindahkannya membongkar setiap jalan pintas dan inkonsistensi yang menumpuk selama satu dekade.

Anda tidak perlu menjalankan migrasinya sendiri. Tapi jika Anda pemilik bisnis, ada segelintir keputusan yang hanya bisa diambil oleh Anda, dan mengambilnya dengan baik adalah pembeda antara go-live yang tenang dan sebulan penuh pemadaman kebakaran.

Data Lama Tidak Pernah Sebersih yang Anda Kira

Kebenaran pahit pertama dari panduan migrasi data legacy mana pun yang layak dibaca: data Anda yang sekarang lebih kotor dari yang Anda percaya. Selalu begitu.

Sepuluh tahun manusia mengetik ke dalam form menghasilkan:

  • Pelanggan yang sama tercatat tiga kali dengan ejaan yang sedikit berbeda.
  • Nomor telepon dalam lima format berbeda, sebagian pakai kode negara, sebagian tidak.
  • Kolom kosong yang akan ditolak mentah-mentah oleh field wajib di sistem baru.
  • Kode dan kategori yang masuk akal bagi seseorang di tahun 2015 dan sekarang tidak berarti apa-apa.
  • Record yang merujuk ke record lain yang sudah tidak ada lagi.

Semua ini tidak jadi masalah di sistem lama, karena sistem lama toleran dan staf Anda menyiasati celahnya dari ingatan. Sistem baru tidak akan semaklum itu. Ia mengharapkan data yang bersih, konsisten, dan lengkap, dan akan menolak atau merusak apa pun yang tidak sesuai.

Inilah sebabnya fase pertama migrasi bukan memindahkan data. Fase pertama adalah membersihkannya. Dan fase ini hampir selalu memakan waktu lebih lama dibanding pekerjaan teknis memindahkan record itu sendiri.

Keputusan Level Pemilik Pertama: Apa yang Dimigrasi, Apa yang Diarsipkan

Ini keputusan yang hanya bisa diambil oleh sisi bisnis, dan layak dipikirkan serius. Anda tidak harus memindahkan semuanya.

Ajukan pertanyaan yang blak-blakan: seberapa banyak histori yang benar-benar Anda butuhkan hidup di sistem baru? Ada alasan kuat untuk memigrasi lebih sedikit dari yang Anda kira.

  • Migrasikan: pelanggan aktif, order yang masih berjalan, inventori saat ini, apa pun yang Anda sentuh dalam operasional harian, dan histori terkini secukupnya untuk menjalankan bisnis, biasanya dua sampai tiga tahun terakhir.
  • Arsipkan: transaksi lama yang sudah selesai, pelanggan tidak aktif, record yang Anda simpan hanya untuk keperluan legal atau pajak. Ini bisa hidup di ekspor read-only atau database arsip sederhana yang bisa dicari kapan pun Anda membutuhkannya.

Memigrasikan semuanya terdengar aman tapi tidak gratis. Setiap record tambahan berarti lebih banyak yang harus dibersihkan, lebih banyak yang harus diuji, dan lebih banyak yang bisa salah. Menyeret sepuluh tahun data mati ke sistem baru memperlambat migrasi, membengkakkan biaya, dan mengotori sistem baru sejak hari pertama. Tentukan batasnya dengan sengaja. Simpan yang menjalankan bisnis, arsipkan yang hanya Anda butuhkan sebagai referensi.

Keputusan Level Pemilik Kedua: Siapa yang Bertanggung Jawab atas Pembersihan

Ini keputusan yang paling sering salah diambil oleh proyek, dan ini bukan keputusan teknis.

Developer bisa memindahkan data dan mengubah formatnya. Mereka tidak bisa memutuskan bahwa "PT Maju Jaya" dan "Maju Jaya PT" adalah pelanggan yang sama, atau mana dari tiga record duplikat yang merupakan data asli. Penilaian semacam itu membutuhkan seseorang yang memahami bisnisnya. Pembersihan data adalah tanggung jawab bisnis, bukan tugas developer, dan berpura-pura sebaliknya adalah cara migrasi jadi berantakan.

Tetapkan secara eksplisit:

  • Tunjuk seorang penanggung jawab dari tim operasional atau finance yang mengenal record-record tersebut dan bisa mengambil keputusan penilaian.
  • Beri mereka waktu. Pembersihan bukan sesuatu yang dikerjakan di sela-sela tugas lain. Ini beban kerja nyata untuk minggu-minggu yang nyata.
  • Biarkan mereka menentukan aturannya. Bagaimana menggabungkan duplikat, apa yang dilakukan terhadap kolom kosong, kategori historis mana yang dipetakan ke kategori baru yang mana. Ini adalah aturan bisnis, dan hanya bisnis yang bisa menetapkannya.

Jika Anda melewatkan ini dan menyerahkan semuanya ke tim teknis, mereka akan menebak-nebak. Tebakan itu menjadi data yang salah di sistem baru Anda, dan Anda akan menemukannya di saat yang paling buruk, biasanya ketika pelanggan atau auditor yang menunjukkannya. Ini erat kaitannya dengan risiko ketergantungan pada orang yang saya tulis di Titik Kegagalan Tunggal Terbesar Anda Kemungkinan Besar Adalah Seseorang, karena pengetahuan yang dibutuhkan untuk membersihkan data seringkali hanya ada di kepala satu orang.

Parallel Running Mengalahkan Big Bang

Ada dua cara untuk berpindah ke sistem baru. Big bang: matikan sistem lama hari Jumat, nyalakan sistem baru hari Senin, dan berharap yang terbaik. Dan parallel running: menjalankan kedua sistem berdampingan untuk periode tertentu sebelum berkomitmen penuh.

Big bang menggoda karena di atas kertas lebih murah dan lebih cepat. Ini juga sumber dari cerita-cerita horor. Jika ada yang salah dengan data yang dimigrasi atau perilaku sistem baru, Anda baru menyadarinya tanpa jalan mundur, di production, dengan seluruh bisnis bergantung padanya.

Parallel running memang lebih mahal dalam jangka pendek, dan hampir selalu sepadan:

  1. Jalankan kedua sistem untuk periode yang ditentukan, biasanya sebulan, dengan memasukkan transaksi nyata di keduanya.
  2. Bandingkan hasilnya. Apakah laporannya cocok? Apakah saldonya sesuai? Apakah jumlah inventorinya sejalan? Ketidakcocokan mengungkap kesalahan migrasi selagi Anda masih punya sistem lama sebagai kebenaran acuan.
  3. Bangun keyakinan sebelum berkomitmen. Di akhir periode paralel, Anda tidak lagi berharap sistem baru bekerja. Anda sudah punya bukti.
  4. Jaga sistem lama tetap bisa dibaca untuk sementara waktu bahkan setelah cutover, agar Anda bisa mengecek apa pun yang terlihat janggal.

Ya, menjalankan dua sistem adalah kerja ekstra bagi tim Anda selama sebulan. Kerja ekstra itu adalah asuransi, dan jauh lebih murah dibanding menemukan tiga bulan kemudian bahwa histori keuangan Anda termigrasi secara salah dan tidak ada yang menyadarinya.

Poin-Poin Praktis

Jika Anda akan mengganti sistem inti, perlakukan data sebagai acara utama, bukan renungan belakangan:

  • Anggarkan untuk pembersihan, bukan cuma pemindahan. Fase pertama adalah membenahi data kotor, dan itu memakan waktu lebih lama dibanding transfer teknisnya.
  • Migrasikan lebih sedikit dari yang Anda kira. Pindahkan yang menjalankan bisnis, arsipkan yang hanya Anda simpan untuk referensi. Data mati yang lama adalah biaya, bukan jaring pengaman.
  • Tunjuk penanggung jawab bisnis untuk pembersihan data. Developer memindahkan data, tapi hanya orang yang memahami bisnis yang bisa memutuskan mana yang benar.
  • Pilih parallel running dibanding big bang. Sebulan menjalankan kedua sistem dan membandingkan hasilnya adalah asuransi termurah yang pernah Anda beli.

Penggantian sistem hidup atau mati karena datanya. Software barunya adalah bagian yang mudah. Utang data lama yang sudah Anda tanggung selama satu dekade akan muncul ke permukaan selama proses pemindahan, dan bisnis yang merencanakan untuk itu akan melewatinya dengan tenang. Jika Anda ingin seseorang merencanakan migrasi dengan benar dan menjaganya agar tidak menjadi krisis, itu pekerjaan yang saya ambil sebagai mitra teknis.