Rewrite baru masuk akal kalau biaya menambal sistem lama sudah lebih mahal daripada membangun ulang, dan salah satu tanda paling nyata adalah setiap perubahan aturan pemerintah, seperti kenaikan UMP atau perubahan iuran BPJS, memaksa tim IT membongkar logika inti sistem alih-alih sekadar mengubah satu angka di pengaturan.
Menambal itu murah, sampai titik tertentu
Selama bertahun-tahun, menambal sistem lama memang pilihan yang rasional. Biaya satu perbaikan kecil jauh lebih murah daripada proyek rewrite penuh, dan bisnis tetap berjalan tanpa gangguan besar. Masalahnya muncul ketika tambalan itu tidak berhenti.
Setiap tambalan menambah satu lapisan kode di atas kode lama yang sudah tidak dipahami siapa pun secara utuh. Lama-lama, mengubah satu hal kecil butuh menyentuh lima tempat berbeda karena tidak ada yang tahu pasti apa yang saling bergantung. Di titik ini, ongkos tambalan berikutnya sudah lebih mahal daripada kelihatannya di invoice.
Tanda pertama: perubahan aturan jadi proyek darurat
Kalau perusahaan Anda mengelola tenaga kerja outsourcing atau karyawan kontrak, aturan yang harus diikuti sistem payroll berubah cukup sering. Kementerian Ketenagakerjaan menetapkan bahwa PKWT yang selesai lebih cepat dari perjanjian dihitung kompensasinya sampai tanggal pekerjaan selesai (PP 35/2021 Pasal 16 ayat 5), sementara PKWT yang diakhiri sepihak sebelum jangka waktu berakhir dihitung berdasarkan masa yang sudah dijalani (Pasal 17). Dua aturan ini kelihatan sederhana di atas kertas, tapi kalau logika perhitungan kompensasi di sistem Anda ditulis sebagai satu rumus kaku, setiap kasus pemutusan kontrak yang tidak standar berarti perhitungan manual di luar sistem.
Contoh lain: Kementerian Ketenagakerjaan menegaskan lewat SE Nomor M/6/HK.04/IV/2021 bahwa pekerja kontrak dan outsourcing berhak THR asal masa kerja sudah satu bulan terus-menerus, tanpa beda status dengan karyawan tetap. Kalau sistem lama Anda memisahkan "karyawan tetap" dan "karyawan kontrak" sebagai dua tabel data yang berbeda sejak awal dibangun, menyamakan hak THR di antara keduanya bukan perkara ubah satu baris kode.
Permenaker 7/2026 juga membatasi alih daya hanya untuk bidang tertentu, yaitu layanan kebersihan, penyediaan makanan dan minuman, pengamanan, penyediaan pengemudi dan angkutan pekerja, layanan penunjang operasional, serta pekerjaan penunjang di sektor pertambangan, perminyakan, gas, dan kelistrikan, sebagai tindak lanjut Putusan Mahkamah Konstitusi Nomor 168/PUU-XXI/2023. Kalau sistem penempatan tenaga kerja Anda tidak dibangun untuk memvalidasi bidang penempatan terhadap daftar yang boleh, aturan baru seperti ini berarti audit manual ke setiap client.
Ini yang membedakan sistem yang masih layak ditambal dari yang sudah harus ditulis ulang: bukan soal tampilan atau kecepatan, tapi soal apakah asumsi dasarnya masih cocok dengan aturan yang berlaku sekarang.
Tanda kedua: biaya perawatan naik lebih cepat dari fitur baru
Cara paling gampang mengecek ini bukan dengan bertanya "apakah sistem masih lambat", tapi dengan melihat rasio waktu tim IT: berapa persen waktu mereka habis untuk memperbaiki bug lama, dibanding membangun sesuatu yang baru. Kalau rasio itu terus bergeser ke arah perbaikan, ongkos tambalan diam-diam sudah melampaui ongkos rewrite, hanya tersebar di banyak invoice kecil sepanjang tahun alih-alih satu proyek besar yang kelihatan.
Perubahan tarif juga masuk kategori ini. Iuran Jaminan Hari Tua sebesar 5,7% dari upah (3,7% ditanggung perusahaan, 2% ditanggung pekerja), Jaminan Kecelakaan Kerja antara 0,24% sampai 1,74% tergantung kategori risiko, Jaminan Kematian 0,3%, dan Jaminan Pensiun 3% (2% perusahaan, 1% pekerja) adalah angka yang ditetapkan BPJS Ketenagakerjaan dan bisa berubah. Sistem yang menghitung semua ini dengan angka tertulis langsung di kode, bukan sebagai parameter yang bisa diubah dari pengaturan, berarti setiap penyesuaian tarif jadi permintaan perubahan kode, dengan biaya dan waktu tunggu yang menumpuk setiap tahun.
Tanda ketiga: satu orang memegang seluruh sistem
Kalau hanya satu orang, entah karyawan atau satu vendor tertentu, yang benar-benar mengerti bagaimana sistem lama bekerja, itu risiko tersendiri, terlepas dari soal biaya. Begitu orang itu resign atau vendor itu berhenti kontrak, perusahaan kehilangan kemampuan mengubah sistemnya sendiri. Ini sering menjadi alasan rewrite yang lebih mendesak daripada alasan biaya, karena begitu terjadi, tidak ada cara menambal apa pun sampai ada orang baru yang mempelajari ulang seluruh sistem dari nol.
Menimbang tambal versus rewrite
| Situasi | Tambal masih masuk akal | Rewrite lebih murah |
|---|---|---|
| Perubahan aturan pemerintah | Aturan cuma ubah satu angka tarif | Aturan ubah kategori data atau logika perhitungan |
| Waktu tim IT | Sebagian besar untuk fitur baru | Sebagian besar untuk perbaikan bug lama |
| Ketergantungan orang | Beberapa orang paham sistemnya | Hanya satu orang atau satu vendor yang paham |
| Integrasi ke sistem lain | Bisa disambungkan dengan sedikit kerja | Perlu ekspor manual atau tidak bisa disambungkan sama sekali |
Apa yang perlu dilakukan sebelum memutuskan
Jangan mulai dari "apakah sistem ini terasa jadul". Mulai dari mencatat setiap kali perubahan aturan, tarif, atau kebijakan pemerintah memaksa perbaikan kode inti dalam satu tahun terakhir, lalu bandingkan dengan berapa fitur baru yang berhasil ditambahkan di periode yang sama. Kalau daftar perbaikan darurat lebih panjang dari daftar fitur baru, itu jawabannya.
Kalau Anda sampai di kesimpulan bahwa rewrite lebih murah, tanyakan ke vendor apakah migrasi bisa dilakukan per modul supaya operasional tidak berhenti total, dan minta mereka menunjukkan bagaimana sistem baru akan menyimpan aturan dan tarif sebagai data yang bisa diubah, bukan sebagai angka yang ditulis di dalam kode.
Pertanyaan yang Sering Diajukan
Apa tanda paling jelas bahwa sistem lama harus ditulis ulang, bukan ditambal lagi?
Kalau setiap perubahan aturan pemerintah, misalnya UMP atau iuran BPJS, membuat tim IT harus mengubah kode inti dan menguji ulang seluruh modul, itu tanda sistemnya sudah kaku. Sistem yang sehat menerima perubahan angka atau aturan tanpa menyentuh logika utamanya.
Berapa lama proses rewrite biasanya berjalan?
Tergantung ukuran dan jumlah modul yang harus dipindahkan, jadi tidak ada angka baku yang bisa dijanjikan tanpa melihat sistem Anda dulu. Tanyakan ke vendor apakah mereka bisa memigrasikan per modul, bukan sekaligus, supaya operasional tidak berhenti total.
Apakah lebih murah menambal sistem lama daripada menulis ulang dari nol?
Untuk perubahan kecil, biasanya masih iya. Yang membalik hitungan itu adalah frekuensi tambalan: kalau tim IT Anda menghabiskan lebih banyak waktu memperbaiki bug lama daripada membangun fitur baru, biaya tambal sebenarnya sudah melebihi biaya rewrite, hanya tidak terlihat di satu invoice besar.
Kalau sistem masih jalan dan tidak ada komplain, apakah tetap perlu diganti?
Tidak otomatis. "Masih jalan" dan "masih murah dijalankan" adalah dua hal berbeda. Cek dulu apakah biaya perawatannya naik dari tahun ke tahun dan apakah sistem itu bisa menangani perubahan aturan yang berlaku sekarang, sebelum memutuskan.
Siapa yang harus dilibatkan dari sisi perusahaan saat mengevaluasi rewrite?
Bukan hanya tim IT. Orang yang memegang payroll, HR, atau operasional harian tahu persis di bagian mana sistem lama sering diakali secara manual, dan informasi itu yang menentukan cakupan rewrite yang sebenarnya dibutuhkan.
Butuh tim yang mengerjakan ini untuk Anda?
Javaman Digieco menyediakan dedicated team, staff augmentation, dan pengembangan software custom untuk perusahaan di Jakarta, Medan, dan seluruh Indonesia.
Hubungi Kami Sekarang