11 Oktober 2026 2 minutes minutes read Admin

Ganti aplikasi lama itu ga sesimpel nyalin ulang

Belakangan ini gue dapet pengalaman baru di salah satu project kantor, sebagai semacam analis jadi-jadian. Project-nya bikin aplikasi baru buat menggantikan aplikasi lama, dan ternyata rasanya cukup beda dari project yang bikin sesuatu dari nol.

Bedanya kelihatan dari awal banget. Karena aplikasi lamanya udah jalan, client udah punya bayangan yang jelas soal apa yang mereka mau. Workflow-nya udah ada, datanya udah ada, bahkan waktu pertama kali kita masuk, mereka udah megang rancangan yang sangat mereka inginkan. Wajar sih, mereka yang tiap hari hidup bareng sistem itu. Tapi di sisi lain, kantor gue masuk sebagai konsultan, jadi tugas kita juga ngeliat lagi kondisi client dan masalah yang bikin mereka pengen punya aplikasi baru.

Kalau dilihat sekilas, kayaknya gampang. Masalah besarnya cuma satu: mereka ga mau terus bergantung sama aplikasi lama, karena harus bayar dan segala macem. Ya udah, tinggal jiplak 1 banding 1, kelar. Tapi begitu requirement digali lebih dalam, keliatan ada beberapa masalah yang ternyata udah ada juga di aplikasi lama. Kalau cuma dijiplak, masalah itu ikut kebawa ke aplikasi baru. Jadi menurut gue lebih efisien kalau sekalian aja, selagi bikin yang baru, masalah-masalah lama itu ikut dibereskan.

Yang paling terasa beda dari project dari nol adalah keberadaan data lama dan keterhubungan dengan aplikasi di sekitarnya. Pas bikin desain UI, kita udah bisa nanya sumber data tiap fitur dari mana. Tapi sumber datanya ga selalu gampang didapet, jadi kadang butuh kerjaan migrasi data tersendiri. Sebaliknya, data yang diolah di aplikasi baru juga bakal dipake aplikasi lain, jadi perlu integrasi, entah langsung atau lewat jalur lain.

Terus ada faktor operator. Mereka yang biasa pake aplikasi lama punya cara kerja sendiri, dan pergantian sistem ini nyentuh langsung kebiasaan itu. Jadi kebutuhan mereka ikut mempengaruhi keputusan waktu bikin aplikasi baru, bukan cuma maunya manajemen atau client di level atas.

Soal arsitektur juga lumayan panjang diskusinya sama client, biar bener-bener sesuai kebutuhan dan keinginan mereka. Kadang masukan dari tim dipertanyakan, karena ga cocok sama keyakinan client soal gimana sistem itu seharusnya. Wajar, tapi di situ pelajaran pentingnya: dokumentasiin keputusan client. Sama kayak project lain, kalau suatu hari keputusan itu bikin masalah, kita punya catatan bahwa kita udah ngasih masukan yang lebih baik, tapi client milih jalan yang lain.

Kesimpulannya, ganti aplikasi lama itu ga sesimpel nyalin ulang. Ada data, ada integrasi, ada kebiasaan orang, dan ada keputusan-keputusan yang perlu dicatat rapi.