Catatan

Mengambil alih aplikasi dari vendor lain: audit sebelum melanjutkan pengembangan

Yang perlu diperiksa sebelum aplikasi buatan vendor lama dikembangkan lagi: akses dan kredensial, apakah kodenya bisa dibangun ulang, umur dependency, keamanan, data dan backup, alur deploy, serta cara memutuskan antara memperbaiki atau membangun ulang.

Terbit 2026-10-04

Kontrak dengan vendor lama sudah selesai, developer yang membangunnya sudah pindah, atau hubungan kerjanya memang tidak berlanjut. Aplikasinya masih dipakai setiap hari, dan sekarang ada fitur baru yang harus dibangun. Godaannya adalah langsung mencari tim baru dan meminta mereka mulai mengerjakan fitur itu.

Masalahnya, tidak ada yang tahu persis apa yang sedang diwarisi. Kode di repositori mungkin bukan kode yang berjalan di server. Akun store mungkin terdaftar atas nama orang yang sudah tidak bisa dihubungi. Backup mungkin ada, tapi belum pernah dicoba dipulihkan. Karena itu langkah pertama mengambil alih aplikasi adalah audit, bukan fitur. Tulisan ini merangkum apa saja yang perlu diperiksa, berurutan dari yang paling mendesak.

1. Kumpulkan semua akses, lalu ganti kuncinya

Mulai dengan inventaris. Tuliskan setiap tempat aplikasi Anda hidup, siapa yang memegang aksesnya hari ini, dan apakah Anda sendiri bisa masuk:

Repositori source code, untuk mobile, web, dan backend.
Server atau akun cloud, database, dan penyimpanan file.
Domain dan pengaturan DNS-nya.
Akun developer Google Play dan App Store.
Upload key Android dan aksesnya ke Play Console.
Payment gateway, layanan email dan SMS, push notification, peta, analytics, dan layanan pihak ketiga lainnya.

Kalau repositori masih ada di akun vendor lama, minta dipindahkan ke organisasi milik Anda. Di GitHub, misalnya, repositori yang dipindahkan membawa riwayat commit, issue, dan pull request-nya, termasuk secrets dan deploy key yang terpasang. Bagian terakhir ini yang sering terlewat: semua kredensial yang ikut pindah tetap kredensial yang dikenal vendor lama.

Kalau aplikasinya terdaftar di akun store milik vendor, Google Play dan App Store sama-sama menyediakan transfer aplikasi antar akun, tapi permintaan di Google Play diajukan oleh pemilik akun asal, dan transfer di App Store dimulai oleh Account Holder akun lama. Jadi urus ini selagi vendor lama masih bisa dihubungi. Untuk Android, periksa juga apakah aplikasinya memakai Play App Signing. Kalau ya, upload key yang hilang bisa direset lewat Play Console. Kalau kunci signing dikelola sendiri dan hilang, menurut Google kunci itu tidak bisa direset. Lebih baik ketahuan di minggu pertama daripada saat ada perbaikan darurat yang harus dirilis.

Setelah semua akses ada di tangan Anda, ganti kredensialnya: kata sandi admin, API key, kunci server, token deploy. Panduan OWASP tentang pengelolaan secret menyarankan rotasi berkala supaya kredensial yang dicuri hanya berlaku sebentar. Pergantian vendor adalah alasan yang lebih kuat lagi. Cabut juga akun pengguna vendor lama di Play Console, App Store Connect, dan akun cloud.

2. Bisakah aplikasinya dibangun ulang dari source code?

Ini pertanyaan paling penting di seluruh audit. Kalau kode di repositori tidak bisa dibangun menjadi aplikasi yang sama dengan yang berjalan di produksi, setiap perubahan berikutnya adalah tebakan.

Ujinya sederhana. Ambil kode dari repositori ke mesin yang bersih, ikuti dokumentasi yang ada, lalu bangun aplikasinya. Biasanya di sini masalah muncul: file konfigurasi yang tidak pernah di-commit, versi tool yang tidak tercatat, library yang sudah hilang dari internet, atau langkah build yang hanya ada di kepala satu orang. Bandingkan juga versi yang berhasil dibangun dengan versi yang sedang berjalan di server dan di store. Kalau berbeda, cari tahu perubahan mana yang tidak pernah masuk repositori.

3. Seberapa tua dependency dan versinya

Aplikasi yang lama tidak disentuh biasanya tertinggal versi di banyak tempat: bahasa pemrograman, framework, library, database, sistem operasi server. Menurut OWASP Top 10:2025, sistem rentan kalau versi semua komponennya tidak dilacak, termasuk dependency turunan, atau kalau software-nya rentan, tidak lagi didukung, atau ketinggalan versi.

Untuk aplikasi mobile, umur versi juga menentukan apakah update masih bisa dirilis. Google Play punya syarat target API level: sejak 31 Agustus 2026, aplikasi baru dan update harus menargetkan Android 16 (API level 36) atau lebih baru. Apple punya syarat versi Xcode dan SDK minimum: sejak 28 April 2026, aplikasi yang diunggah ke App Store Connect harus dibangun dengan Xcode 26 atau lebih baru. Kedua syarat ini dinaikkan secara berkala. Artinya, perbaikan sekecil apa pun pada aplikasi yang lama tidak diperbarui bisa membutuhkan pekerjaan upgrade lebih dulu. Lebih baik ini masuk hitungan sejak audit daripada jadi kejutan di tengah jalan.

4. Tinjauan keamanan

Audit keamanan saat pengambilalihan tidak harus berupa penetration test penuh. Yang perlu dijawab lebih dulu adalah risiko yang paling mungkin terjadi:

Apakah ada kata sandi, API key, atau kunci yang tertulis di kode atau di riwayat commit?
Apakah semua halaman dan endpoint admin benar-benar dilindungi login dan hak akses?
Apakah hak akses pengguna sesuai dengan peran mereka hari ini?
Apakah ada log yang cukup untuk melacak kejadian kalau terjadi insiden?

Temuan dari sini menentukan prioritas. Celah yang bisa dipakai hari ini didahulukan, sebelum fitur apa pun.

5. Data dan backup

Cari tahu di mana data disimpan, apakah backup berjalan, seberapa sering, dan disimpan di mana. Lalu lakukan langkah yang paling sering dilewati: coba pulihkan satu backup ke lingkungan terpisah. Backup yang belum pernah dipulihkan belum terbukti bisa dipakai.

Kalau aplikasinya menyimpan data pribadi pelanggan atau karyawan, perhatikan juga siapa saja yang diberi akses selama audit. UU Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi mengatur kewajiban pengendali dan prosesor data pribadi. Untuk penerapannya di perusahaan Anda, libatkan penasihat hukum.

6. Alur deploy dan lingkungan

Bagaimana kode sampai ke server hari ini? Ada aplikasi yang dirilis lewat pipeline otomatis, ada juga yang di-deploy manual dari laptop seseorang. Periksa apakah ada lingkungan staging untuk menguji perubahan sebelum ke produksi, dan apakah ada cara kembali ke versi sebelumnya kalau rilis bermasalah. Kalau jawabannya tidak, membangun alur ini biasanya lebih berharga daripada fitur pertama, karena semua pekerjaan berikutnya lewat sini.

7. Celah dokumentasi

Dokumentasi aplikasi warisan jarang lengkap. Yang paling sering hilang adalah aturan bisnis yang tertanam di kode: kenapa satu status bisa dilewati, kenapa satu laporan dihitung dengan cara tertentu. Jangan menunggu dokumentasi sempurna sebelum mulai. Tulis temuan audit sebagai dokumentasi pertama, lalu lengkapi setiap kali satu bagian sistem disentuh.

Perbaiki atau bangun ulang?

Setelah audit, pertanyaan ini hampir pasti muncul. Membangun ulang terdengar bersih, tapi sistem yang sudah berjalan menyimpan banyak keputusan dan pengecualian yang tidak tertulis di mana pun. Membangun ulang berarti menemukan semuanya lagi, sambil sistem lama tetap harus dirawat.

Biasanya lebih masuk akal diperbaiki kalau

Kodenya bisa dibangun ulang dari repositori.
Stack-nya masih didukung, walaupun perlu di-upgrade.
Masalah utamanya ada di bagian tertentu, bukan di seluruh sistem.

Membangun ulang layak dipertimbangkan kalau

Source code tidak lengkap atau tidak bisa dibangun sama sekali.
Teknologinya sudah tidak didukung dan tidak ada jalur upgrade yang wajar.
Kebutuhan bisnisnya sudah berubah jauh dari yang dulu dibangun.

Seringnya jawabannya campuran: sebagian dipertahankan, sebagian diganti bertahap. Apa pun keputusannya, tuliskan alasannya bersama temuan audit, supaya bisa diperiksa lagi saat kondisinya berubah.

Seperti apa kerja sama pertama yang masuk akal

Kerja sama pertama dengan tim baru sebaiknya bukan fitur, tapi audit dengan hasil tertulis. Hasilnya setidaknya memuat:

Inventaris akses dan status pemindahannya.
Apakah aplikasi bisa dibangun ulang dari source code, dan apa yang kurang.
Daftar risiko, diurutkan dari yang paling mendesak.
Rekomendasi langkah berikutnya, termasuk perbaiki atau bangun ulang.

Dari situ, langkah yang masuk akal biasanya menstabilkan dulu, yaitu backup yang terbukti, monitoring, dan alur deploy yang bisa diulang, baru kemudian fitur. Tim baru yang langsung menyanggupi fitur tanpa melihat kodenya sedang menebak, sama seperti vendor yang memberi harga sebelum bertanya tentang proses Anda.

Daftar periksa pengambilalihan

Inventaris semua akses selesai, dan Anda bisa masuk ke semuanya.
Repositori dan akun store sudah di akun milik perusahaan, atau proses transfernya berjalan.
Status Play App Signing dan lokasi upload key diketahui.
Semua kredensial sudah diganti, dan akses vendor lama dicabut.
Aplikasi berhasil dibangun ulang dari repositori di mesin yang bersih.
Versi framework, library, dan syarat store sudah dicek.
Risiko keamanan utama sudah ditinjau dan diprioritaskan.
Satu backup sudah dicoba dipulihkan.
Alur deploy dan cara rollback diketahui dan tertulis.
Temuan audit dan keputusan perbaiki atau bangun ulang tertulis.

Bagaimana kami menanganinya

Kami memang mengambil alih sistem yang bukan kami bangun. Lewat managed service, kerja sama dimulai dengan audit dan gambaran tertulis tentang apa yang kami ambil alih, jadi Anda tahu apa yang dicakup sebelum kami bertanggung jawab atasnya. Pekerjaan pengembangan setelahnya, termasuk untuk aplikasi Android dan iOS, dimulai dari lingkup tertulis dengan harga tetap.

Supaya situasi yang sama tidak terulang dengan vendor berikutnya, termasuk dengan kami, baca juga apa yang perlu disepakati soal kepemilikan source code, akun, dan kunci aplikasi. Kalau Anda sedang menghadapi kondisi ini, ceritakan aplikasinya.