Kasus seperti ini sudah beberapa kali saya temui. Aplikasinya masih jalan dan karyawan masih pakai setiap hari, tapi vendor yang membuatnya sudah tidak bisa dihubungi. Atau programmer internal yang dulu pegang sudah resign, dan sekarang tidak ada yang berani menyentuh kodenya.
Selama tidak ada masalah sih semuanya terasa aman. Masalahnya baru kelihatan waktu server penuh, ada error aneh, atau bos minta fitur baru. Saat itu baru sadar kalau sebenarnya tidak ada yang benar-benar memegang aplikasi itu.
Biasanya aplikasinya aplikasi internal berbasis web, misalnya inventaris, aplikasi dealer, absensi, atau portal pelanggan, yang dibuat dengan PHP, CodeIgniter, atau Laravel beberapa tahun lalu. Kabar baiknya, aplikasi yang seperti ini hampir selalu bisa diselamatkan, asal source code dan aksesnya masih bisa diamankan.
Urutan yang biasa saya pakai kira-kira begini.
Amankan aset dulu, baru mikir yang lain
Jangan langsung bicara perbaikan atau fitur baru. Pastikan dulu perusahaan memang memiliki semua bagian aplikasinya. Yang perlu dikumpulkan:
- Source code, idealnya dalam bentuk repository Git lengkap dengan riwayat commit-nya
- Akses server: panel hosting, SSH, atau akun VPS/cloud
- Database beserta backup yang sudah pernah dicoba di-restore
- Akun registrar domain dan DNS (misalnya Cloudflare)
- Akun layanan pihak ketiga: SMTP, payment gateway, API WhatsApp, Google Maps, dan sebagainya
Dokumentasi juga dikumpulkan, sekecil apa pun. File .env.example atau chat lama dengan vendor kadang malah yang paling membantu, lho.
Yang paling sering bikin deg-degan itu domain atau hosting yang terdaftar atas nama pribadi vendor. Kalau orangnya hilang kontak, domain bisa kedaluwarsa tanpa ada yang tahu. Nah, yang seperti ini harus diprioritaskan.
Versi di server belum tentu sama dengan source code
Ini sering kejadian. Source code yang diserahkan vendor ternyata bukan versi yang sedang jalan di server. Ada perbaikan yang langsung diedit di server, atau ada file konfigurasi yang cuma ada di sana.
Cara saya biasanya sederhana. Ambil salinan lengkap file aplikasi langsung dari server, bandingkan dengan source code dari vendor, lalu jadikan versi server sebagai titik awal. Setelah itu langsung simpan ke repository Git baru milik perusahaan.
Mulai dari situ setiap perubahan tercatat: siapa yang mengubah, kapan, dan kenapa. Kalau nanti mau sekalian dibuat deploy otomatis, bisa pakai cara seperti yang pernah saya tulis.
Jalankan di lingkungan terpisah
Jangan pernah mulai mengubah apa pun langsung di server produksi, ya. Siapkan salinan aplikasi di laptop developer atau server staging. Database-nya pakai salinan juga, dan data sensitifnya disamarkan kalau perlu.
Langkah ini sekaligus jadi tes. Kalau aplikasinya tidak bisa jalan di tempat lain, berarti ada pengetahuan yang hilang. Bisa versi PHP tertentu, ekstensi yang kurang, cron job yang tidak ketahuan, atau konfigurasi web server yang aneh. Lebih baik ketahuan sekarang kan, daripada ketahuannya pas server produksi bermasalah.
Untuk lingkungan lokal di Windows, saya biasanya pakai Laragon karena gampang ganti versi PHP. Kalau aplikasinya butuh HTTPS atau domain tertentu, bisa lihat catatan .
Audit singkat
Setelah aplikasi bisa jalan, baru kondisinya bisa dinilai dengan jujur. Yang pertama saya cek biasanya versi teknologinya: PHP, framework, database, dan OS server. Kalau masih PHP 5 atau CodeIgniter 2, wah, langsung masuk daftar prioritas karena sudah tidak dapat update keamanan.
Setelah itu cek keamanan dasar: password default, file konfigurasi yang bisa diakses publik, form yang rawan SQL injection, dan permission folder upload. Backup juga dicek: ada atau tidak, jalan otomatis atau manual, dan kapan terakhir diuji.
Terakhir lihat struktur kodenya, masih bisa diikuti atau penuh copy-paste di mana-mana. Tanyakan juga ke pengguna bagian mana yang paling sering error. Keluhan pengguna itu sih petunjuk paling jujur.
Hasil audit sebaiknya dibuat dokumen pendek dengan bahasa yang bisa dipahami manajemen: apa yang aman, apa yang berisiko, dan apa yang harus dikerjakan duluan. Jangan terlalu teknis, nanti malah tidak dibaca.
Dirawat, dimodernisasi, atau dibangun ulang?
Dari hasil audit, biasanya pilihannya cuma tiga.
Cukup dirawat
Pilihan ini cocok kalau aplikasinya masih memenuhi kebutuhan bisnis dan kodenya masih bisa dibaca. Fokusnya perbaiki bug, rapikan bagian yang rawan, tutup celah keamanan, dan pastikan backup jalan. Paling murah dan hasilnya paling cepat terasa.
Modernisasi bertahap
Pilihan ini cocok kalau aplikasinya masih berguna tapi teknologinya sudah ketinggalan. Upgrade-nya pelan-pelan: pindah server dulu, naikkan versi PHP, lalu framework, sementara aplikasi tetap dipakai sehari-hari.
Di tahap ini biasanya muncul error kecil yang menyebalkan. Contohnya waktu MySQL dinaikkan ke 5.7 ke atas, query lama tiba-tiba gagal dan butuh . Hal seperti ini wajar kok, asal dites dulu di staging.
Bangun ulang
Ini baru masuk akal kalau kebutuhan bisnisnya sudah jauh berubah, atau kodenya memang sudah tidak bisa dipertahankan. Biayanya paling mahal dan risikonya paling besar. Jadi keputusannya harus berdasarkan hasil audit, bukan karena kodenya "kelihatan jelek".
Jujur saja, dari pengalaman saya, kebanyakan aplikasi internal yang ditinggal vendor tidak perlu dibangun ulang. Yang dibutuhkan cuma orang yang mau sabar membaca kodenya, lalu merawatnya dengan disiplin.
Supaya tidak terulang
Setelah aplikasi kembali terkendali, ada beberapa kebiasaan kecil yang membuat perusahaan tidak lagi bergantung pada satu orang. Source code disimpan di repository milik perusahaan, bukan akun pribadi developer. Domain, hosting, dan akun pihak ketiga didaftarkan atas nama perusahaan dengan email perusahaan.
Backup harus otomatis dan rutin dites restore. Buat juga catatan singkat cara instalasi dan deploy, lalu perbarui setiap ada perubahan besar. Satu lagi nih: kontrak dengan vendor atau developer harus mewajibkan serah terima source code dan dokumentasi. Kedengarannya sepele, tapi justru ini yang paling sering dilupakan.
Beberapa pertanyaan yang sering muncul
Bisa dilanjutkan tanpa source code?
Susah. Untuk aplikasi PHP, kode yang jalan di server biasanya masih bisa dibaca dan dijadikan titik awal. Tapi kalau kodenya di-obfuscate atau aplikasinya hasil compile, pilihan yang tersisa sering kali cuma bangun ulang. Makanya akses server harus diamankan paling awal.
Berapa lama prosesnya?
Tergantung ukuran aplikasi dan kelengkapan aksesnya. Kalau aksesnya lengkap, mengamankan aset dan menjalankan aplikasi di lingkungan terpisah biasanya cukup beberapa hari. Audit dan perbaikan menyusul setelahnya.
Developer-nya harus menguasai teknologi yang sama?
Idealnya iya, misalnya paham PHP dengan CodeIgniter atau Laravel, plus MySQL atau MariaDB. Tapi menurut saya yang sering dilupakan adalah sisi server. Banyak masalah aplikasi lama justru datang dari servernya, bukan dari kodenya.
Butuh bantuan?
Saya Mardino Santosa, freelance system administrator dan full-stack developer di Makassar. Sejak 2007 saya mengurus jaringan, server, dan aplikasi web. Sepuluh tahun di antaranya saya pegang IT di Transstudio Theme Park Makassar, lalu empat tahun jadi system administrator sekaligus developer di Kumalagroup.
Sekarang saya membantu perusahaan merawat, memperbaiki, memigrasi, dan mengembangkan aplikasi yang sudah ada. Kerjanya langsung dengan saya, tanpa perantara software house.
Detail layanan, cara kerja, dan FAQ ada di halaman freelance software developer di Makassar. Kalau mau langsung ngobrol, kirim pesan lewat WhatsApp aja. Ceritakan singkat aplikasinya, jalan di mana, dan apa yang dibutuhkan.
(z)
