Kalimat paling menakutkan yang saya dengar dari klien yang merencanakan migrasi sistem lama adalah "kita go live akhir pekan ini." Rencana itu mengasumsikan setiap bagian dari cutover yang kompleks akan berjalan benar di percobaan pertama, di bawah tekanan waktu, tanpa jalan mundur kalau gagal. Saya belum pernah melihat asumsi itu terbukti benar, dan saya sudah berhenti menyetujui rencana yang dibangun ke arah itu.

Migrasi sistem lama tidak mengharuskan Anda memilih satu tanggal untuk menekan tombol dan berharap yang terbaik. Pendekatan yang lebih baik, yang saya pakai di setiap proyek migrasi tanpa peduli industrinya, adalah menjalankan sistem lama dan baru berdampingan, lalu memindahkan satu alur kerja pada satu waktu, memverifikasi setiap perpindahan sebelum menyentuh yang berikutnya. Cara ini terdengar lebih lambat saat diumumkan, tapi jauh lebih cepat selesai secara nyata, karena Anda tidak menghabiskan berbulan-bulan memulihkan diri dari cutover besar yang gagal.

Mengapa cutover besar-besaran sering gagal

Penggantian total yang dilakukan dalam satu akhir pekan memusatkan semua kemungkinan kegagalan ke dalam satu jendela waktu bertekanan tinggi: bug migrasi data, ketidakcocokan integrasi, kebingungan pengguna, dan kasus-kasus tepi yang tidak terpikirkan untuk diuji, semuanya datang bersamaan, sementara bisnis tetap dituntut beroperasi penuh pada Senin pagi apa pun yang terjadi.

Ketika sesuatu rusak dalam skenario itu, dan biasanya memang rusak, Anda akan men-debug insiden produksi langsung di bawah tekanan maksimal, sementara sistem lama sudah dimatikan. Tidak ada jalur mundur yang tenang. Ini bukan masalah teknologi, ini masalah manajemen risiko, dan bisa dihindari lewat cara merancangnya, bukan dengan berusaha lebih keras saat akhir pekan cutover.

Pendekatan strangler dalam bahasa sederhana

Pola yang oleh para engineer disebut pendekatan "strangler" sebenarnya sederhana begitu jargonnya dilepas: bungkus sistem lama alih-alih menggantinya secara langsung, lalu lepaskan satu fungsi pada satu waktu, memverifikasi masing-masing terhadap sistem lama sebelum benar-benar mengambil alih.

Secara konkret, untuk migrasi sistem lama:

  1. Pasang lapisan tipis di depan sistem lama yang bisa mengarahkan request ke sistem lama atau sistem baru, per alur kerja.
  2. Pilih satu alur kerja dengan risiko paling rendah dan visibilitas paling tinggi terlebih dahulu. Cukup kecil untuk bisa gagal dengan aman, tapi cukup terlihat agar keberhasilannya membangun kepercayaan di seluruh tim.
  3. Bangun satu alur kerja itu di sistem baru, dan jalankan paralel dengan sistem lama untuk periode tertentu, membandingkan output pada data nyata, bukan data uji.
  4. Pindahkan alur kerja itu begitu outputnya konsisten sama, sementara semua yang lain tetap berjalan di sistem lama tanpa disentuh.
  5. Ulangi untuk alur kerja berikutnya, memakai apa yang sudah dipelajari. Setiap alur kerja yang berhasil dimigrasikan membuat yang berikutnya lebih cepat dan lebih rendah risiko, karena tim kini sudah percaya pada fondasi sistem baru.

Saat Anda sampai di beberapa alur kerja terakhir, sistem lama sudah menyusut menjadi sisa kecil yang mudah dipahami, dan mematikannya hampir jadi anticlimax, alih-alih menjadi babak final menegangkan yang ditakuti semua orang di awal.

Menjalankan sistem lama dan baru secara paralel

Menjalankan paralel adalah bagian yang paling sering ingin dilewati klien, karena terasa seperti kerja dua kali lipat. Padahal tidak. Ini adalah asuransi, dan asuransi ini murah dibandingkan biaya insiden di production dengan data pelanggan asli tanpa jalan mundur.

Dalam praktiknya, menjalankan paralel berarti:

  • Sistem baru memproses transaksi yang sama dengan sistem lama, untuk satu alur kerja tertentu, selama jendela waktu tertentu, biasanya dua sampai empat minggu tergantung volume transaksi dan seberapa beragam datanya.
  • Output dibandingkan secara otomatis sebisa mungkin: total invoice yang sama, jumlah stok yang sama, data pelanggan yang sama. Selisih langsung diselidiki saat itu juga, bukan menunggu akhir bulan.
  • Sistem lama tetap menjadi system of record sampai periode perbandingan menunjukkan sistem baru konsisten benar, bukan sekadar biasanya benar.

Inilah persis pola yang membuat sebuah perusahaan multifinance mendigitalisasi collections dan menekan kerugian tanpa satu pun siklus pembayaran yang terlewat selama masa transisi. Collections bukan proses yang bisa ditoleransi kesalahannya bahkan untuk satu siklus penagihan saja, dan menjalankan paralel adalah yang membuat migrasi penuh mungkin dilakukan tanpa risiko itu.

Aturan utamanya

Jangan pernah menjadwalkan akhir pekan di mana semuanya harus berjalan benar. Kalau rencana migrasi Anda punya satu tanggal tunggal di mana sistem lama dimatikan, sistem baru dinyalakan, dan tidak ada jalan kembali, rencana itu sudah membawa satu titik kegagalan yang tertanam di dalam jadwalnya sendiri. Tulis ulang rencananya sebelum menyentuh kodenya.

Jalur rollback pantas mendapat perhatian desain yang sama seriusnya dengan jalur maju. Untuk setiap alur kerja yang Anda migrasikan, ketahui sejak awal persis bagaimana caranya mengarahkan kembali ke sistem lama kalau ada yang salah pasca-cutover, dan jaga jalur itu tetap hidup dan teruji minimal selama satu siklus bisnis penuh setelah cutover, bukan hanya selama masa pengujian.

Apa yang harus dibayar dan apa yang didapat

Migrasi sistem lama yang paralel dan bertahap per alur kerja memang memakan waktu kalender lebih lama dibanding cutover besar-besaran, seringkali dua sampai tiga kali lipat tergantung berapa banyak alur kerja yang dibawa sistem lama. Itu trade-off yang jujur, dan lebih baik diakui terus terang daripada disembunyikan dalam rencana proyek yang diam-diam berasumsi semuanya akan berjalan sempurna.

Yang Anda dapatkan sebagai gantinya: tidak ada satu hari pun di mana seluruh bisnis dipertaruhkan, jalur rollback di setiap tahap, dan tim yang semakin percaya diri, bukan semakin kelelahan. Bandingkan itu dengan biaya tersembunyi dari sistem lama yang selama ini Anda tanggung, senyap, menumpuk, nyaris tak terlihat, versus risiko migrasi yang berisik, terlihat jelas, dan terpusat dalam satu akhir pekan. Pendekatan paralel menukar pendarahan pelan dengan perbaikan bertahap yang terkendali, bukan sebuah pertaruhan.

Kesimpulannya

Kalau ada yang mengusulkan satu akhir pekan cutover tunggal untuk migrasi sistem lama Anda, tanyakan apa yang terjadi kalau sistem baru gagal di alur kerja ketiga dari dua belas pada pukul 11 malam Sabtu. Kalau tidak ada jawaban yang meyakinkan, rencananya belum siap. Bungkus sistem lama, pindahkan satu alur kerja pada satu waktu, jalankan keduanya paralel cukup lama untuk bisa dipercaya hasil perbandingannya, dan jaga jalur rollback tetap hidup di setiap tahap. Ini cerita yang kurang dramatis untuk disampaikan ke board, tapi jauh lebih baik untuk benar-benar dijalani.