Migrasi Aplikasi Lama ke AI: Roadmap 5 Langkah Tanpa Rewrite

Kamu sudah punya aplikasi yang jalan. Mungkin sistem kasir, aplikasi pesanan, dashboard internal, atau portal pelanggan yang dibangun beberapa tahun lalu. Sekarang muncul pertanyaan: "Bisa nggak ditambah AI, tanpa harus bikin ulang dari nol?" Jawaban singkatnya: hampir selalu bisa. Artikel ini adalah roadmap migrasi aplikasi lama ke AI dalam lima langkah, berdasarkan cara kami di Rancangin Aja (RAT) mengerjakannya.

Kata "migrasi" di sini sedikit menyesatkan. Yang terjadi bukan memindahkan aplikasi ke tempat baru, tapi menambahkan lapisan AI di atas yang sudah ada. Ini penting dipahami sejak awal karena banyak pemilik bisnis mengira harus rewrite total, lalu membatalkan niatnya karena biayanya terbayang besar.

Kenapa jangan rewrite?

Membangun ulang aplikasi yang sudah jalan adalah salah satu keputusan paling mahal dan berisiko dalam software. Alasannya:

• Aplikasi lama menyimpan banyak aturan bisnis yang tidak terdokumentasi. Rewrite berarti menemukan kembali semuanya, sering kali lewat bug.
• Selama rewrite berjalan (berbulan-bulan), bisnis tetap butuh fitur baru di aplikasi lama. Jadi kamu membayar dua kali.
• Pengguna sudah terbiasa dengan yang lama. Perubahan total menambah beban pelatihan.
• Nilai AI biasanya datang dari satu atau dua fitur spesifik, bukan dari aplikasi yang serba baru.

Jadi pendekatan kami: biarkan aplikasi lama tetap jadi "sumber kebenaran", dan tambahkan AI sebagai layanan di sampingnya.

Langkah 1: Audit data dan alur kerja

Sebelum bicara AI, kami perlu tahu dua hal: data apa yang kamu punya dan di mana AI bisa masuk ke alur kerja.

Audit data

Pertanyaan yang kami ajukan:

• Data apa yang disimpan aplikasi? Pesanan, pelanggan, produk, chat, dokumen?
• Bagaimana cara mengaksesnya? Ada API? Akses langsung ke database? Atau hanya ekspor manual?
• Seberapa rapi? Ada kolom yang kosong, format tidak konsisten, data ganda?
• Siapa yang memiliki kode dan akun? Ini sering jadi penghambat kalau aplikasi dibuat vendor lain.

Audit alur kerja

Kami duduk dengan tim yang memakai aplikasi sehari-hari dan mencari titik di mana manusia melakukan pekerjaan berulang yang melibatkan teks atau dokumen: membaca, mengetik ulang, mengelompokkan, merangkum, menjawab. Di situlah kandidat AI biasanya berada.

Hasil langkah ini: daftar sumber data yang bisa diakses, daftar titik alur kerja yang berpotensi, dan daftar hambatan teknis (misalnya tidak ada API).

Catatan jujur: cukup sering, hasil audit menunjukkan bahwa masalah utamanya bukan ketiadaan AI, tapi data yang tidak rapi atau proses yang belum jelas. Dalam kasus seperti itu, kami lebih dulu menyarankan membereskan fondasinya. Kami tulis lebih lengkap soal ini di kapan bisnis belum butuh AI. Menambahkan AI di atas data yang berantakan hanya menghasilkan jawaban berantakan yang lebih cepat.

Langkah 2: Pilih satu use case bernilai tinggi

Dari daftar kandidat di langkah 1, pilih satu. Bukan tiga, bukan lima. Kriterianya:

Use case yang bagus untuk pertama: skor tinggi di nilai dan kesiapan data, rendah di risiko. Misalnya, sebuah aplikasi pesanan B2B yang timnya setiap hari membaca puluhan email pesanan dari pelanggan lalu mengetik ulang ke sistem. AI bisa membaca email, mengekstrak item dan jumlahnya, dan mengisi draf pesanan untuk dicek manusia. Datanya ada (email dan format pesanan), risikonya rendah (ada pengecekan sebelum disimpan), dan hasilnya terukur (waktu input turun).

Ide use case lain bisa kamu lihat di 10 contoh penerapan AI di bisnis kecil.

Langkah 3: Tambahkan lapisan AI lewat API, bukan rewrite

Ini inti teknisnya. Ada tiga pola arsitektur yang paling sering kami pakai. Kamu tidak perlu paham detailnya, tapi berguna tahu pilihannya saat vendor menjelaskan.

Pola A: Layanan AI di samping aplikasi lama

Kami membangun layanan kecil terpisah (biasanya dengan Node.js/NestJS atau Python) yang tugasnya hanya satu: menerima data dari aplikasi lama, memproses dengan AI, dan mengembalikan hasilnya. Aplikasi lama cukup ditambah satu "panggilan" ke layanan ini.

• Cocok untuk: aplikasi lama yang punya API atau bisa ditambah sedikit kode.
• Kelebihan: aplikasi lama hampir tidak disentuh. Kalau layanan AI bermasalah, aplikasi lama tetap jalan.
• Contoh: tombol "Rangkum" di halaman detail pelanggan yang memanggil layanan AI untuk merangkum riwayat chat.

Pola B: RAG di atas database yang sudah ada

Kalau use case-nya adalah "AI yang paham data atau dokumen kami", kami membangun lapisan RAG (Retrieval-Augmented Generation): data dari database atau dokumen diindeks, lalu AI menjawab berdasarkan potongan data yang relevan. Database aslinya tidak diubah, hanya dibaca.

• Cocok untuk: katalog produk, SOP, riwayat tiket, basis pengetahuan internal.
• Kelebihan: AI menjawab berdasarkan data kamu, bukan mengarang. Sumber jawabannya bisa ditampilkan.
• Kami jelaskan cara kerjanya di RAG: cara membuat AI paham dokumen bisnis kamu.

Pola C: Otomasi berbasis event

Setiap kali sesuatu terjadi di aplikasi lama (pesanan baru, tiket masuk, dokumen diunggah), sebuah "sinyal" dikirim ke layanan AI yang kemudian bertindak: mengklasifikasi, memberi label, mengirim notifikasi, atau mengisi field.

• Cocok untuk: proses yang berjalan di latar belakang tanpa interaksi pengguna.
• Kelebihan: tidak mengubah tampilan aplikasi sama sekali. Pengguna hanya melihat hasilnya "sudah terisi".
• Contoh: setiap tiket komplain masuk otomatis diberi kategori dan prioritas.

Tiga pola ini bisa dikombinasikan. Yang penting: aplikasi lama tetap jadi pusat, AI jadi pelengkap yang bisa dilepas.

Soal pemilihan model AI

Kami merancang lapisan AI supaya penyedia modelnya (OpenAI, Claude, atau model lokal seperti Ollama) bisa diganti tanpa membongkar sistem. Ini penting untuk dua hal: biaya (model murah untuk tugas sederhana, model kuat untuk tugas sulit) dan privasi (data sensitif bisa diproses model lokal).

Langkah 4: Uji dengan data asli, ukur dengan angka

Prototipe AI yang terlihat bagus di demo dengan 5 contoh bisa gagal di data asli dengan 500 variasi. Jadi sebelum dipakai, kami lakukan evaluasi:

1. Kumpulkan contoh asli dari bisnismu. Untuk kasus ekstraksi email pesanan tadi: 50–100 email asli beserta jawaban yang benar (dibuat manual oleh tim kamu).
2. Jalankan AI terhadap semua contoh itu.
3. Hitung: berapa persen yang benar, jenis kesalahan apa yang paling sering.
4. Perbaiki instruksi (prompt), cara data diproses, atau model yang dipakai. Ulangi.

Hasilnya angka yang jujur, misalnya "AI benar di 92% kasus, kesalahan terbanyak di satuan produk yang ditulis tidak standar". Dari sini kamu bisa memutuskan: cukup bagus untuk dipakai dengan pengecekan manusia? Atau perlu diperbaiki dulu?

Tahap ini juga saat biaya pemakaian terlihat. Berapa token per permintaan, berapa permintaan per hari, berapa rupiah per bulan. Kalau terlalu mahal, biasanya bisa ditekan dengan model yang lebih kecil untuk sebagian tugas.

Langkah 5: Rilis bertahap dengan manusia di dalam proses

Jangan langsung lepas ke semua pengguna. Pola yang kami pakai:

1. Mode saran: AI mengisi atau menyarankan, manusia memutuskan. Semua hasil AI terlihat jelas sebagai "saran AI". Berjalan 2–4 minggu.
2. Mode semi-otomatis: untuk kasus yang AI-nya sangat yakin (berdasarkan evaluasi), hasil langsung dipakai. Kasus yang ragu tetap ke manusia.
3. Mode otomatis dengan sampling: sebagian besar otomatis, manusia memeriksa sampel secara acak dan menangani eskalasi.

Di setiap tahap, ada pencatatan: apa yang disarankan AI, apa yang diputuskan manusia. Selisihnya jadi bahan perbaikan berikutnya. Ini yang disebut human-in-the-loop, dan untuk sebagian besar bisnis, mode 1 atau 2 sudah memberi manfaat besar tanpa perlu sampai mode 3.

Risiko dan biaya yang perlu diperhitungkan

Soal biaya, menambahkan satu use case AI ke aplikasi yang sudah ada biasanya jauh lebih terjangkau daripada membangun aplikasi baru. Kisarannya kami tulis di breakdown biaya bikin aplikasi dan integrasi AI. Yang perlu diingat: ada biaya bulanan untuk pemakaian API dan pemantauan kualitas.

Kapan rewrite memang perlu?

Supaya adil, ada situasi di mana menambal tidak masuk akal:

• Aplikasi lama tidak bisa diakses sama sekali: tidak ada kode, tidak ada API, database terkunci di vendor yang sudah hilang.
• Teknologinya sudah tidak didukung dan tidak aman (misalnya framework yang tidak dapat update keamanan bertahun-tahun).
• Aplikasi lama memang sudah tidak sesuai dengan proses bisnis sekarang, dan AI hanya salah satu dari banyak hal yang ingin diubah.
• Biaya mengintegrasikan lebih mahal dari membangun versi baru yang kecil.

Dalam kasus seperti ini, kami tetap sarankan rewrite bertahap: bangun modul baru (yang sudah ber-AI) di samping yang lama, pindahkan pengguna sedikit demi sedikit. Tahapannya mengikuti proses yang kami jelaskan di SDLC untuk pemilik bisnis.

Ringkasan roadmap

1. Audit data dan alur kerja. Temukan apa yang bisa diakses dan di mana manusia melakukan pekerjaan berulang.
2. Pilih satu use case: nilai tinggi, data siap, risiko rendah, bisa diukur.
3. Tambahkan lapisan AI di samping aplikasi lama: layanan terpisah, RAG, atau otomasi berbasis event.
4. Uji dengan data asli dan ukur akurasinya dengan angka, bukan perasaan.
5. Rilis bertahap dengan manusia yang memeriksa, lalu perluas kalau terbukti.

Langkah selanjutnya

Migrasi aplikasi lama ke AI tidak harus berarti membongkar semuanya. Dengan satu use case yang tepat dan lapisan AI yang dirancang terpisah, kamu bisa merasakan manfaatnya dalam hitungan minggu, bukan tahun. Kalau kamu punya aplikasi yang sudah jalan dan ingin tahu use case mana yang paling masuk akal, jadwalkan konsultasi gratis atau chat via WhatsApp. Kami akan bantu audit awal dan lihat bagaimana layanan AI engineering kami bisa masuk tanpa mengganggu yang sudah berjalan.