Berapa Biaya Migrasi Legacy System? Komponen Budget dari Audit hingga Go-Live

Biaya migrasi legacy system tidak ditentukan hanya oleh ukuran aplikasi atau jumlah user. Dua perusahaan dengan sistem yang terlihat serupa dapat membutuhkan budget yang sangat berbeda karena effort migrasi dipengaruhi oleh kualitas codebase, dependency antar-sistem, kondisi database, kebutuhan integrasi, tingkat technical debt, target architecture, downtime tolerance, hingga cara migrasi dilakukan.

Karena itu, pertanyaan:

“Berapa biaya mengganti sistem lama?”

biasanya belum cukup untuk menghasilkan estimasi yang dapat dipertanggungjawabkan.

Pertanyaan yang lebih tepat adalah:

“Bagian mana dari sistem yang masih bernilai, bagian mana yang harus dimodernisasi, dan risiko apa yang harus dikendalikan selama transisi?”

Pendekatan ini penting karena modernisasi legacy system tidak selalu berarti membuang sistem lama dan membangun semuanya dari nol. IBM dalam panduannya mengenai legacy application modernization menjelaskan beberapa pendekatan berbeda, mulai dari replatforming, re-architecting hingga rebuilding atau replacement. Pilihan strategi inilah yang kemudian sangat memengaruhi biaya dan durasi proyek.

Mengapa Budget Migrasi Legacy System Sulit Dipukul Rata?

Bayangkan dua perusahaan menggunakan aplikasi operasional yang sama-sama telah berjalan selama lebih dari 10 tahun.

Perusahaan pertama memiliki codebase yang masih terdokumentasi, database relatif konsisten, API untuk sistem eksternal, automated testing pada modul kritikal, dan developer internal yang masih memahami arsitekturnya.

Perusahaan kedua memiliki aplikasi monolithic yang beberapa kali berpindah vendor, dokumentasi tidak lengkap, banyak business rule tertanam di dalam code, integrasi menggunakan direct database connection, dan hanya sedikit orang yang memahami bagaimana sistem bekerja secara end-to-end.

Secara bisnis, keduanya sama-sama disebut:

legacy system.

Tetapi risiko migrasi dan effort engineering-nya sangat berbeda.

Itulah sebabnya Microsoft Cloud Adoption Framework menempatkan assessment sebelum migrasi. Assessment perlu memberikan visibility terhadap architecture, performance, security, application code, database, dependency, dan requirement sebelum target architecture dan strategi migrasi diputuskan.

Artinya, estimasi yang dibuat sebelum memahami dependency sistem biasanya hanya menghasilkan dua kemungkinan:

budget terlalu besar karena terlalu banyak contingency, atau budget terlalu kecil dan membengkak di tengah implementasi.

Komponen Budget Migrasi Legacy System

Secara praktis, budget modernisasi dapat dibagi menjadi beberapa kelompok berikut.

Model tersebut sejalan dengan pendekatan financial planning dari AWS Prescriptive Guidance untuk migration business case. AWS memasukkan biaya discovery dan migration planning, workload migration, infrastructure selama proses migrasi, testing, operational ramp-up, hingga decommissioning sebagai bagian dari business case migrasi.

Jadi biaya migrasi bukan hanya:

development cost.

Ada biaya sebelum development, selama transisi, dan setelah sistem baru berjalan.

1. Assessment: Jangan Mengestimasi Sistem yang Belum Dipahami

Tahap pertama seharusnya bukan langsung membuat timeline development.

Mulailah dengan mengetahui apa yang sebenarnya ada di dalam sistem.

Assessment biasanya mencakup:

• module inventory,
• database,
• application architecture,
• integration,
• user role,
• third-party dependency,
• batch process,
• reporting,
• authentication,
• infrastructure,
• code quality,
• security exposure,
• dan business-critical workflow.

Tujuannya bukan sekadar menghasilkan dokumentasi.

Tujuan assessment adalah mengetahui:

apa yang harus dipindahkan, apa yang harus diperbaiki, apa yang harus dipertahankan, dan apa yang sebenarnya sudah tidak digunakan lagi.

IBM pada pembahasan brownfield application modernization menunjukkan mengapa hal ini berpengaruh langsung terhadap economics proyek. Legacy application dapat mengandung dead code, duplicated logic, architectural decay, dan technical debt yang membuat scope modernisasi terlihat lebih besar daripada business capability yang sebenarnya masih diperlukan.

Dalam kasus seperti itu, memigrasikan seluruh codebase secara otomatis belum tentu efisien.

Sebagian code mungkin sudah tidak memberikan business value.

2. Strategi Migrasi Menentukan Besar Budget

Tidak semua legacy system harus diperlakukan dengan strategi yang sama.

Secara sederhana, perusahaan dapat memilih beberapa pendekatan.

Rehost

Aplikasi dipindahkan ke environment baru dengan perubahan minimal.

Biasanya lebih cepat, tetapi masalah architecture lama tetap terbawa.

Replatform

Aplikasi dipindahkan sekaligus melakukan perubahan pada infrastructure atau platform agar lebih sesuai dengan kebutuhan baru.

Refactor

Sebagian code dan architecture diperbaiki tanpa membangun ulang seluruh sistem.

Re-architect

Struktur aplikasi mengalami perubahan lebih signifikan agar lebih scalable, modular, dan mudah diintegrasikan.

Rebuild

Business capability dipertahankan, tetapi aplikasi dibangun kembali menggunakan architecture dan technology stack baru.

Replace

Sistem lama diganti dengan platform atau produk lain.

Microsoft menyediakan migration strategy framework yang mencakup beberapa pendekatan tersebut dan secara khusus mengingatkan bahwa workload yang sudah memiliki masalah performance, reliability, atau architecture tidak sebaiknya hanya dipindahkan begitu saja karena technical debt tersebut akan ikut berpindah.

Inilah salah satu alasan mengapa dua proposal migrasi dapat memiliki harga yang sangat berbeda.

Vendor A mungkin menawarkan:

rehost.

Vendor B mungkin menawarkan:

re-architect + migration.

Keduanya tidak sedang menjual scope yang sama.

3. Technical Debt Dapat Menjadi Hidden Cost Terbesar

Legacy system hampir selalu membawa keputusan teknis dari masa lalu.

Sebagian mungkin masih baik.

Sebagian lainnya berubah menjadi technical debt.

Contohnya:

• framework sudah tidak didukung,
• library tidak dapat di-upgrade,
• business logic duplicated,
• hard-coded configuration,
• dependency tidak terdokumentasi,
• database query sangat kompleks,
• deployment masih manual,
• automated test hampir tidak ada.

Technical debt seperti ini membuat perubahan sederhana menjadi mahal karena developer harus memahami dan mengamankan banyak dependency sebelum melakukan perubahan.

Menurut IBM mengenai legacy application modernization, technical debt menjadi salah satu tantangan utama dalam modernisasi karena shortcut dan keputusan lama dapat menghasilkan code yang sulit dipelihara serta meningkatkan biaya perubahan di kemudian hari.

Karena itu budget migrasi sebaiknya tidak hanya mengukur:

berapa feature yang harus dibangun.

Tetapi juga:

berapa banyak complexity yang harus dibereskan agar feature tersebut dapat dipindahkan dengan aman.

4. Data Migration Sering Terlihat Sederhana Sampai Data Dibuka

Pada proposal awal, data migration sering ditulis hanya sebagai satu baris:

“Migrasi database lama ke database baru.”

Dalam praktiknya, pekerjaan ini dapat menjadi salah satu bagian paling berisiko.

Contoh masalah yang sering ditemukan:

Customer A pada sistem lama:

PT ABC

di sistem kedua:

ABC, PT

di spreadsheet divisi:

ABC Indonesia

Apakah ketiganya entitas yang sama?

Sistem lama juga mungkin memiliki:

• column yang sudah tidak digunakan,
• duplicate record,
• inconsistent format,
• invalid reference,
• missing relation,
• transaction history yang terlalu besar,
• data yang perlu di-archive,
• atau encoding lama.

Migrasi yang baik karena itu tidak hanya melakukan:

export → import.

Tetapi:

mapping → cleansing → transformation → migration → validation → reconciliation.

Assessment terhadap database juga menjadi bagian yang ditekankan dalam Microsoft workload migration assessment guidance agar compatibility dan requirement diketahui sebelum workload dipindahkan.

Untuk sistem seperti ERP, CRM, finance, atau supply chain, kesalahan data setelah go-live sering kali lebih berbahaya daripada bug UI.

5. Integrasi Sistem Harus Masuk Budget Sejak Awal

Legacy application jarang berdiri sendiri.

Ia mungkin terhubung dengan:

ERP
CRM
payment gateway
banking system
warehouse
HRIS
Active Directory
email
WhatsApp
BI platform
third-party API
government platform.

Karena itu modernisasi satu aplikasi sering memiliki efek terhadap sistem lain.

Misalnya aplikasi procurement diganti.

UI barunya selesai.

Database baru selesai.

Tetapi sistem ternyata masih harus menerima vendor data dari ERP lama dan mengirim invoice ke finance.

Jika integrasi baru diketahui setelah development berjalan, budget mudah membengkak.

Itulah sebabnya dependency mapping harus dilakukan ketika assessment.

Bukan setelah aplikasi selesai dibangun.

6. Testing Legacy Migration Lebih Mahal daripada Greenfield Testing

Saat membuat sistem baru, kita menguji apakah feature baru bekerja.

Saat memigrasikan legacy system, ada pertanyaan tambahan:

Apakah behaviour yang sudah digunakan perusahaan bertahun-tahun masih bekerja setelah migrasi?

Itulah mengapa regression testing menjadi sangat penting.

Contohnya ada workflow:

Order → Approval → Inventory Reservation → Invoice → Delivery

Tim tidak hanya menguji setiap fitur.

Tim perlu memastikan keseluruhan sequence tetap bekerja.

Kemudian ada skenario:

• transaksi besar,
• transaksi bersamaan,
• failed integration,
• permission berbeda,
• historical data,
• batch process,
• rollback.

Semakin mission-critical sistemnya, semakin besar testing effort yang dibutuhkan.

Dan jika automated test pada aplikasi lama sangat minim, effort ini biasanya lebih besar lagi karena baseline behaviour harus dipetakan terlebih dahulu.

7. Cutover Bukan Sekadar “Deploy ke Production”

Salah satu biaya yang sering tidak terlihat ada pada fase cutover.

Pada sistem non-kritikal, perusahaan mungkin dapat menghentikan aplikasi beberapa jam, memindahkan data, lalu menjalankan sistem baru.

Namun untuk sistem yang digunakan 24/7, strategi seperti itu tidak selalu memungkinkan.

Perusahaan mungkin membutuhkan:

parallel environment

incremental synchronization

migration rehearsal

rollback plan

change freeze

production monitoring

hingga tim standby setelah go-live.

Microsoft dalam panduan eksekusi migrasi memasukkan stakeholder preparation, change freeze, cutover, fallback option, validation, dan stabilization sebagai bagian dari migration execution.

Artinya:

semakin kecil downtime yang dapat diterima bisnis, semakin tinggi complexity migrasinya.

Downtime requirement harus ditentukan sejak awal karena langsung memengaruhi architecture dan budget.

8. Jangan Lupa Biaya Menjalankan Dua Sistem Sementara

Ada satu periode yang sering terlupakan dalam perhitungan:

legacy masih hidup, sistem baru juga sudah hidup.

Saat itu perusahaan mungkin membayar:

• infrastructure lama,
• infrastructure baru,
• database replication,
• operational support,
• dua license,
• migration tooling,
• additional monitoring.

AWS memasukkan biaya seperti migration infrastructure, testing environment, cloud ramp-up dan existing infrastructure ramp-down ke dalam migration business case. Lihat AWS Directional Business Case Guidance.

Jadi budget modernisasi perlu melihat periode transisi, bukan hanya kondisi sebelum dan sesudah migrasi.

9. Decommissioning Juga Memiliki Cost dan Risiko

Setelah sistem baru berjalan, sistem lama tidak boleh langsung dimatikan.

Pertanyaan yang perlu diselesaikan antara lain:

• apakah semua data sudah berpindah?
• apakah audit history masih dibutuhkan?
• apakah ada integration yang ternyata masih mengakses sistem lama?
• berapa lama backup harus disimpan?
• apakah ada license atau vendor contract yang harus dihentikan?
• siapa yang memberikan final approval untuk shutdown?

Jika tahap ini tidak dikelola, perusahaan justru menjalankan dua sistem dalam jangka panjang.

Akibatnya salah satu tujuan modernisasi—mengurangi maintenance cost—tidak pernah benar-benar tercapai.

Bagaimana Membuat Estimasi Budget yang Lebih Realistis?

Daripada langsung meminta satu angka, enterprise dapat menggunakan model estimasi bertahap.

Stage 1 — Assessment Budget

Digunakan untuk:

• system audit,
• dependency mapping,
• code assessment,
• data assessment,
• architecture review,
• security review,
• migration option analysis.

Outputnya:

migration recommendation + target architecture + scope + risk + budget range.

Stage 2 — Migration / Modernization Budget

Digunakan untuk:

• development,
• refactoring,
• API,
• data migration,
• integration,
• testing,
• infrastructure.

Stage 3 — Cutover Budget

Digunakan untuk:

• migration rehearsal,
• final data sync,
• deployment,
• fallback,
• production validation.

Stage 4 — Stabilization Budget

Digunakan untuk:

• monitoring,
• bug fixing,
• performance tuning,
• user support,
• knowledge transfer.

Stage 5 — Decommission Budget

Digunakan untuk:

• archive,
• shutdown,
• infrastructure termination,
• license termination,
• documentation.

Model tersebut lebih sehat dibanding membuat satu angka besar bernama:

“Biaya Rebuild Sistem.”

Illustrative Budget Allocation

Setiap proyek akan berbeda, tetapi untuk membantu diskusi awal, enterprise dapat menggunakan pembagian effort berikut sebagai planning model, bukan standar harga pasar.

Angka tersebut bukan quotation dan bukan benchmark industri universal. Tujuannya hanya memperlihatkan bahwa budget migration tidak seharusnya 80–90% dihabiskan pada coding.

Jika audit, data, testing, dan cutover hampir tidak memiliki alokasi, justru ada risiko scope penting belum dihitung.

Crocodic Perspective: Jangan Migrasikan Semua yang Ada Hanya karena Sistem Lama Memilikinya

Salah satu kesalahan terbesar dalam modernization project adalah menganggap:

semua feature yang ada di sistem lama harus ada di sistem baru.

Legacy system dapat membawa 10–15 tahun histori keputusan bisnis.

Ada feature yang masih kritikal.

Tetapi bisa juga ada:

• module yang hampir tidak digunakan,
• workflow yang sebenarnya sudah berubah,
• report yang digantikan BI,
• business rule yang tidak lagi relevan,
• duplicated feature,
• workaround yang muncul karena keterbatasan sistem lama.

Jika semuanya dibangun ulang satu per satu, enterprise sebenarnya bukan melakukan modernization.

Enterprise hanya:

memindahkan technical debt ke technology stack yang lebih baru.

IBM juga membahas masalah dead code dan duplicated logic dalam modernisasi brownfield application. Dalam contoh internal yang mereka uraikan, structural analysis dapat digunakan untuk memperkecil scope modernisasi dengan mengidentifikasi code yang tidak lagi memberikan value. Lihat analisis IBM mengenai brownfield modernization.

Karena itu sebelum migrasi, setiap capability sebaiknya diklasifikasikan:

KEEP

Masih kritikal dan tetap diperlukan.

IMPROVE

Masih diperlukan tetapi workflow atau UX perlu diperbaiki.

REPLACE

Capability tetap diperlukan tetapi implementasinya harus berubah.

RETIRE

Tidak lagi memberikan business value.

Pendekatan ini membantu perusahaan memperkecil scope sekaligus menghasilkan sistem baru yang benar-benar lebih baik.

Big Bang atau Bertahap?

Biaya juga dipengaruhi strategi deployment.

Big Bang

Seluruh sistem berpindah pada satu periode.

Keuntungannya:

• transition period lebih pendek,
• lebih cepat menghentikan legacy infrastructure.

Risikonya:

• cutover lebih kompleks,
• blast radius besar,
• rollback lebih sulit.

Phased Migration

Migration dilakukan per module, region, business unit, atau workflow.

Keuntungannya:

• risiko lebih terisolasi,
• pengguna dapat beradaptasi bertahap,
• learning dari fase awal dapat digunakan pada fase berikutnya.

Risikonya:

• masa coexistence lebih lama,
• temporary integration bisa bertambah,
• operational cost dapat berjalan lebih lama.

Pendekatan bertahap juga sejalan dengan pola migrasi skala enterprise yang digunakan dalam AWS Prescriptive Guidance, yang membagi perjalanan migrasi besar menjadi assess, mobilize, dan migrate alih-alih memindahkan seluruh workload secara sekaligus tanpa preparation.

Karena itu pertanyaan sebenarnya bukan:

mana yang selalu lebih murah?

Tetapi:

berapa biaya risiko yang bersedia diterima perusahaan?

Kapan Perusahaan Sebaiknya Memilih Refactor daripada Rewrite?

Tidak semua sistem lama harus dibangun ulang.

Refactor lebih masuk akal ketika:

• core architecture masih cukup sehat,
• business logic bernilai tinggi,
• sebagian besar teknologi masih dapat dipertahankan,
• masalah terkonsentrasi pada module tertentu,
• integration layer masih dapat diperbaiki.

Rewrite lebih relevan ketika:

• architecture membatasi hampir seluruh pengembangan,
• teknologi sudah obsolete,
• perubahan kecil sangat mahal,
• codebase sulit diuji,
• security tidak dapat diperbaiki tanpa perubahan fundamental.

IBM juga menempatkan replatforming, re-architecting, rebuilding dan replacement sebagai pilihan berbeda dalam modernization strategy. Panduan IBM Legacy Application Modernization dapat digunakan sebagai referensi untuk memahami perbedaan pendekatan tersebut.

Bagi enterprise, keputusan terbaik bukan yang paling modern secara teknologi.

Tetapi yang memberikan:

risk-adjusted business value terbaik.

Jangan Mengukur Migrasi Hanya dari Go-Live

Salah satu jebakan modernization project adalah menjadikan:

“sistem berhasil go-live”

sebagai satu-satunya definisi keberhasilan.

Padahal migration seharusnya menghasilkan perubahan yang bisa diukur.

Contohnya:

Dengan KPI seperti ini, perusahaan dapat membandingkan:

cost of modernization

dengan:

cost of maintaining the status quo.

Ini jauh lebih berguna untuk board atau executive team daripada hanya membandingkan development quotation.

Jadi, Berapa Biaya Migrasi Legacy System?

Jawabannya tergantung pada:

scope + technical debt + data + integrations + migration strategy + downtime tolerance + risk level.

Semakin kompleks sistem dan semakin kritikal proses bisnisnya, semakin besar effort yang dibutuhkan untuk memastikan perpindahan berlangsung aman.

Karena itu biaya sebaiknya tidak dihitung hanya dari:

jumlah halaman atau jumlah fitur.

Model estimasi yang lebih realistis menggunakan:

system assessment → migration strategy → modernization scope → data & integration → testing → cutover → stabilization → decommission.

Dengan model tersebut, perusahaan tidak hanya mengetahui berapa biaya untuk “membangun sistem baru”, tetapi memahami apa yang sebenarnya dibayar dan risiko apa yang sedang dikendalikan.

Modernisasi Sistem Lama Tanpa Harus Mengambil Risiko Big Bang

Crocodic membantu enterprise mengevaluasi dan meningkatkan legacy system melalui pendekatan yang disesuaikan dengan kondisi architecture, data, integration, dan business process existing.

Modernisasi dapat dilakukan melalui:

refactoring, API enablement, architecture modernization, data migration, system integration, phased replacement, maupun rebuild ketika memang dibutuhkan.

Tujuannya bukan sekadar mengganti teknologi lama.

Tujuannya adalah membuat sistem enterprise lebih mudah dikembangkan, lebih mudah terintegrasi, dan lebih siap mendukung kebutuhan bisnis berikutnya.

Untuk perusahaan yang belum yakin apakah sistem sebaiknya diperbaiki atau dibangun ulang, langkah pertama sebaiknya dimulai dari system assessment, sehingga keputusan investasi dibuat berdasarkan kondisi sistem yang sebenarnya—bukan asumsi.