Migrasi Sistem Catalog

KONTRIBUSI SAYA

Tanggung jawab saya sebenarnya bukan memindahkan data catalog dari sistem A ke sistem B. Bagian saya justru menjaga semua yang selama ini bergantung ke catalog lama supaya tetap bekerja setelah sumber datanya diganti. Jadi sebelum ngomongin migrasi, saya harus listing dulu fitur dan flow mana saja yang kemungkinan tersentuh. Mana yang perubahannya relatif sederhana, mana yang butuh penyesuaian lebih jauh, dan mana yang ternyata punya dependency atau behavior yang sebelumnya bahkan nggak terlalu kelihatan. Di sini saya kerja cukup dekat bareng satu junior Product Manager dari squad internal apps yang memang fokus pegang sistem catalog barunya. Sementara saya lebih banyak menjaga sisi commerce-nya: apa yang bergantung ke catalog, apa yang harus berubah, apa yang perlu dibangun ulang, dan terutama apa yang seharusnya tetap terasa sama buat customer.

MASALAH

Risiko terbesar dari migrasi ini sebenarnya bukan 80.000 produknya hilang atau gagal dipindahkan. Yang lebih bikin khawatir justru menemukan terlalu telat kalau ternyata ada sesuatu yang diam-diam bergantung ke catalog lama. Selama bertahun-tahun, sistem lama sudah keburu terhubung ke banyak bagian commerce. Ada dependency yang jelas dan terdokumentasi. Tapi ada juga yang cuma bekerja seperti itu karena memang dari dulu implementasinya begitu. Artinya kami nggak punya satu dokumen rapi yang tinggal dibaca lalu semua impact migration langsung kelihatan. Kami harus membangun pemahaman itu lagi. Dan ternyata mengganti sumber datanya saja nggak selalu cukup. Ada flow yang behavior-nya berbeda, ada informasi yang perlu diperlakukan berbeda, ada logic di frontend maupun service lain yang sudah telanjur dibangun berdasarkan cara kerja sistem lama, dan ada capability yang sebelumnya tersedia tapi belum ada di sistem baru. Jadi semakin dikerjakan, semakin kelihatan kalau ini bukan sekadar pekerjaan memindahkan catalog. Kami sedang mencari dependency yang tersembunyi sebelum dependency itu berubah jadi production issue.

HASIL

Setelah kurang lebih satu semester dipakai untuk mapping, redevelopment, testing, dan koordinasi lintas tim, sekitar 80.000 produk akhirnya berhasil dipindahkan ke sistem catalog baru yang dikelola secara internal. Buat saya indikator keberhasilan yang lebih penting justru sederhana: dari sisi customer, seharusnya nggak banyak yang terasa berubah meskipun salah satu fondasi utama di belakang commerce-nya sudah diganti. Migrasi ini juga akhirnya memberi kami gambaran yang jauh lebih jelas tentang dependency yang selama bertahun-tahun terbentuk di sekitar sistem lama. Setelah semuanya mulai stabil, pekerjaan berikutnya malah jadi lebih menarik: satu-satu logic dan implementasi lama yang sebelumnya terasa aneh mulai bisa dirapikan tanpa harus membawa risiko migrasi di saat yang sama.

DAMPAK

Project ini cukup mengubah definisi “migrasi” di kepala saya. Sebelumnya saya melihat migrasi ya sebagai memindahkan sesuatu dari sistem lama ke sistem baru. Sekarang saya malah melihatnya sebagai proses mencari semua hal yang selama bertahun-tahun kita lupa ternyata dikerjakan oleh sistem lama. Datanya justru bagian yang paling kelihatan. Risiko sebenarnya banyak hidup di dependency, asumsi, edge case, dan behavior yang sudah terlalu lama berjalan sampai semua orang menganggapnya normal. Dan satu hal lagi yang baru benar-benar kerasa setelah cutover: migrasi nggak selesai ketika sistem barunya sudah live. Kalau orang yang sehari-hari menggunakannya belum memahami cara kerja barunya, kita mungkin sudah selesai secara teknis. Tapi belum tentu selesai sebagai produk.