Di suatu sudut kantor Anda mungkin ada sistem yang selalu jadi bahan keluhan. Lemot, cuma bisa jalan di satu PC yang sudah uzur, vendornya sudah menghilang bertahun-tahun lalu, dan hanya satu staf senior yang paham seluk-beluknya. Tapi anehnya, itu justru yang menjalankan bisnis Anda. Setiap invoice, setiap pergerakan stok, setiap proses payroll, semuanya lewat sistem itu.

Kombinasi inilah yang membuat modernisasi sistem legacy menjadi salah satu keputusan dengan taruhan tertinggi yang dihadapi pemilik bisnis. Godaannya wajar: sistem lama itu memalukan, jadi buang saja dan bangun penggantinya yang modern. Tapi justru fakta bahwa sistem lama itu yang menjalankan bisnis Anda-lah yang membuat penggantiannya dalam satu langkah besar menjadi sangat berbahaya. Kuburan proyek IT yang gagal penuh dengan rewrite yang tadinya penuh percaya diri.

Setelah berada di kedua sisi keputusan ini, sebagai engineer yang mengerjakan migrasinya dan sebagai penasihat yang membantu owner memutuskan apakah proyek ini layak didanai, berikut cara saya memandang pilihan ini.

Kenapa Sistem Lama Lebih Sulit Diganti dari yang Terlihat

Sistem legacy tidak pernah sekadar kumpulan kode. Setelah sepuluh tahun beroperasi, ia diam-diam mengumpulkan tiga hal:

  • Aturan bisnis yang tidak terdokumentasi. Pembulatan aneh di invoice itu ada karena sengketa pajak tahun 2014. Jeda tiga hari pada approval tertentu ada karena kasus fraud yang sudah tidak dibicarakan lagi. Semua ini tidak tertulis di mana pun kecuali di dalam kode, itu pun kalau Anda beruntung. Ini juga alasan terkuat untuk mendokumentasikan hal-hal selagi orang-orangnya masih ingat, yang sudah saya bahas di Dokumentasi Adalah Asuransi Termurah yang Bisa Anda Beli.
  • Data yang punya sejarah panjang. Bertahun-tahun transaksi, data pelanggan, dan kasus-kasus khusus, dalam struktur yang tidak akan sama dengan sistem baru. Migrasi data rutin menjadi separuh dari rasa sakit di setiap penggantian sistem, dan hampir selalu diremehkan.
  • Alur kerja manusia yang terbentuk mengikutinya. Staf sudah punya muscle memory, cara-cara akal-akalan, dan spreadsheet sampingan yang diam-diam menambal celah sistem. Sistem baru akan merusak semuanya di hari pertama.

Sebuah rewrite harus mereproduksi ketiganya, sebagian besar dengan menemukannya kembali dengan cara yang sulit, di lingkungan produksi, sementara bisnis tetap harus berjalan.

Hitung-hitungan Risiko Big-Bang Rewrite

Pendekatan big-bang kedengarannya rapi: bangun sistem baru secara paralel, lalu pindah total dalam satu akhir pekan. Pada praktiknya, pendekatan ini membawa profil risiko yang brutal.

Selama 12 hingga 18 bulan Anda membayar untuk pembangunan sistem baru sementara bisnis tidak mendapat manfaat apa pun, karena nilainya baru muncul saat cutover terakhir. Sementara itu sistem lama tidak diam saja, bisnis terus berubah, sehingga rewrite ini mengejar target yang terus bergerak, dan setiap perubahan sekarang harus dikerjakan dua kali atau ditunda. Lalu tiba hari cutover, dan setiap celah yang belum ditemukan muncul sekaligus, di bawah beban produksi penuh, tanpa jalan mundur kecuali membatalkan seluruh proyek.

Secara kasar, pendekatan big bang memusatkan seluruh risiko proyek ke satu momen, setelah semua uang habis dikeluarkan. Kalau gagal, Anda sudah menghabiskan ratusan juta rupiah dan memiliki dua sistem: yang lama yang masih Anda andalkan, dan yang baru yang tidak dipercaya siapa pun. Saya pernah melihat perusahaan skala menengah mencoba persis ini pada sistem pemrosesan order intinya: 14 bulan pembangunan, minggu cutover yang kacau, rollback, dan kembali diam-diam ke sistem lama. Kerugiannya di atas Rp 600 juta, tapi biaya yang lebih buruk adalah organisasi itu menolak menyentuh modernisasi lagi selama bertahun-tahun.

Alternatif Bertahap, dalam Bahasa Sederhana

Pendekatan yang biasanya menang untuk bisnis skala UKM punya nama teknis yang kurang sedap didengar, strangler fig pattern, tapi idenya sederhana: bangun bagian-bagian baru di sekeliling inti sistem lama, dan pindahkan fungsi satu per satu, memensiunkan sistem lama sepotong demi sepotong.

Secara konkret, prosesnya seperti ini:

  1. Pasang lapisan di depan. Layar, aplikasi, atau integrasi baru berbicara dengan lapisan tipis yang mengarahkan permintaan, baik ke sistem lama maupun ke komponen baru. Pengguna dan sistem lain berhenti bergantung langsung pada internal sistem legacy.
  2. Pilih satu fungsi yang jelas batasnya, dengan rasa sakit tinggi tapi keterkaitan yang masih terkendali. Reporting adalah pilihan potongan pertama yang klasik: salin datanya keluar secara terjadwal dan bangun laporan modern di sebelah sistem lama, tanpa menyentuh apa pun yang kritikal.
  3. Pindahkan, jalankan, verifikasi. Bagian baru ini live untuk fungsi tersebut. Selama masa transisi, Anda bahkan bisa menjalankan sistem lama dan baru secara paralel dan membandingkan hasilnya.
  4. Ulangi. Ordering yang berhadapan dengan pelanggan berikutnya, lalu inventory, lalu invoicing. Setiap potongan adalah proyek kecil dengan anggarannya sendiri, go-live-nya sendiri, dan rencana rollback-nya sendiri.
  5. Suatu hari inti sistem lama tinggal mengerjakan sedikit sekali sehingga Anda bisa mematikannya. Seringkali secara diam-diam, tanpa akhir pekan cutover sama sekali.

Hitung-hitungan risikonya berbalik total. Alih-alih satu taruhan raksasa di akhir, Anda menempatkan serangkaian taruhan kecil, masing-masing memberikan nilai sendiri dalam dua atau tiga bulan. Satu potongan yang gagal hanya merugikan potongan itu, bukan seluruh program. Aturan bisnis ditemukan kembali secara bertahap, satu fungsi pada satu waktu, sementara sistem lama masih ada untuk dijadikan pembanding. Dan Anda bisa berhenti sejenak setelah potongan mana pun kalau kas sedang ketat, sambil tetap mempertahankan semua yang sudah selesai dikerjakan.

Kapan Penggantian Total Justru Tepat

Migrasi bertahap biasanya menang, tapi tidak selalu. Penggantian total adalah pilihan yang lebih baik ketika:

  • Sistemnya kecil dan dangkal. Tool sederhana dengan data terbatas dan dua pengguna tidak butuh strategi migrasi. Ganti saja langsung.
  • Produk siap pakai yang matang sudah mencakup kebutuhan Anda. Kalau sistem legacy Anda melakukan hal yang sudah dilakukan dengan baik oleh software akuntansi atau POS standar saat ini, migrasikan datanya ke produk yang sudah terbukti itu daripada membangun apa pun dari nol. Disiplin reporting-dan-parallel-run yang sama tetap berlaku.
  • Platformnya benar-benar sekarat. Hardware yang tidak bisa diganti lagi, OS yang sudah melewati end of life dengan eksposur kepatuhan, database yang sudah tidak ada yang bisa melisensikannya lagi. Deadline yang keras mengubah hitung-hitungannya, meski dalam kondisi ini pun Anda seringkali masih bisa membagi transisinya ke beberapa tahap.
  • Tidak ada yang bisa menyentuh kode lamanya sama sekali. Kalau sistemnya begitu opak sehingga membungkusnya dalam lapisan integrasi pun tidak memungkinkan, opsi bertahap menyusut. Ini jarang terjadi, dan layak dimintakan opini kedua sebelum Anda menerimanya begitu saja, karena "kata vendor kami itu tidak mungkin" kadang sebenarnya berarti "vendor Anda lebih suka kontrak rebuild." Tanda-tanda peringatannya mirip dengan yang saya bahas di Red Flag Vendor Teknologi yang Harus Dikenali Sebelum Anda Tanda Tangan.

Aturan praktis yang berguna: semakin banyak transaksi, integrasi, dan tahun-tahun tak terdokumentasi yang dimiliki sebuah sistem, semakin besar peluangnya berpihak pada pendekatan bertahap. Semakin kecil dan semakin standar fungsinya, semakin besar peluangnya berpihak pada penggantian dengan produk siap pakai.

Pertanyaan yang Harus Diajukan Sebelum Anda Tanda Tangan Apa Pun

Apa pun jalur yang Anda condong ke sana, ajukan ini ke tim atau vendor Anda:

  • Apa potongan pertamanya, dan nilai apa yang diberikannya sendiri dalam 90 hari?
  • Apa rencana rollback untuk setiap go-live, dan sudahkah itu diuji?
  • Bagaimana data akan dimigrasikan dan diverifikasi, dan siapa yang bertanggung jawab merekonsiliasi perbedaannya?
  • Kalau kita menghentikan program di tengah jalan, apa yang tetap kita pertahankan?
  • Siapa yang mendokumentasikan aturan bisnis yang kita temukan sepanjang jalan?

Vendor yang menjawab ini dengan tegas dan jelas sedang merencanakan migrasi. Vendor yang menjawab dengan satu tanggal cutover besar sedang merencanakan taruhan dengan uang Anda.

Kesimpulan Praktisnya

Keburukan sistem lama bukanlah keadaan darurat sesungguhnya. Keadaan darurat yang sebenarnya adalah konsentrasi risiko: satu sistem rapuh, satu orang yang memahaminya, satu cutover besar yang bisa menjatuhkan bisnis Anda. Modernisasi bertahap menyerang risiko itu secara langsung, mengubah satu proyek yang menakutkan menjadi serangkaian proyek yang membosankan, dan mulai memberikan hasil dalam hitungan bulan, bukan tahun. Jadikan pendekatan strangler sebagai default, simpan big bang untuk sistem yang kecil atau standar, dan bersikaplah sangat curiga pada siapa pun yang rencananya punya satu akhir pekan dramatis di dalamnya.