Checklist Migrasi dari Spreadsheet ke ERP

Kegagalan proyek ERP paling sering terjadi bukan di fase implementasi, tapi di fase migrasi data. Berikut checklist yang harus Anda lewati sebelum go-live.

Ada tiga fase kritis: sebelum, saat, dan sesudah migrasi. Kesalahan di salah satunya akan menghantui Anda selama audit tahunan berikutnya.

Panduan ini menyusun checklist praktis, risiko klasik, contoh skenario UMKM Indonesia, dan pola keputusan yang terbukti mengurangi drama di hari-H. Fokusnya bukan bagaimana memindahkan file, melainkan bagaimana memindahkan integritas informasi bisnis Anda dengan aman.

Kenapa Migrasi Adalah Titik Paling Rawan

Spreadsheet longgar terhadap kesalahan: kolom kosong, format tanggal campur aduk, dan duplikat masih bisa 'jalan'. ERP tidak. Begitu data tersebut masuk ke sistem terpadu, satu kesalahan format bisa memblokir sinkronisasi ke modul lain — dan Anda baru menyadarinya saat mencetak faktur pertama.

Selain itu, tanggal cutover mengunci saldo pembuka. Kalau saldo pembuka salah, seluruh laporan periode berikutnya bergeser tanpa Anda tahu penyebabnya. Karena itu migrasi harus dianggap sebagai proyek terpisah — bukan lampiran dari implementasi.

Migrasi yang baik tidak dinilai dari hari-H yang mulus, tapi dari bulan pertama pasca go-live yang tenang.

Prinsip Utama Sebelum Menyentuh Data

• Satu sumber kebenaran per entitas: SKU, pelanggan, dan supplier dikonsolidasi ke satu file master sebelum masuk ke sistem baru.
• Migrasikan saldo, bukan seluruh histori. Histori disimpan read-only di sistem lama.
• Uji impor di lingkungan staging minimal dua putaran sebelum go-live.
• Setiap file impor punya penanggung jawab yang menandatangani (bukti reviewer, bukan sekadar operator).
• Aturan penomoran dokumen (PO, invoice, DO) ditetapkan tertulis — melanjutkan atau reset dari 1.

Sebelum Migrasi (H-30 sampai H-1)

• Bekukan format master data: satu SKU = satu baris, satu pelanggan = satu ID.
• Bersihkan duplikat pelanggan dan supplier — biasanya ada 5–15% duplikat tersembunyi karena beda ejaan.
• Rekonsiliasi saldo per akun ke tanggal cutover; selisih di sistem lama akan menjadi selisih di sistem baru.
• Tentukan kebijakan penomoran dokumen (PO, invoice, DO) mulai kapan direset atau dilanjutkan.
• Pastikan setiap SKU punya UoM (satuan) yang jelas — 'pcs' vs 'box' vs 'karton' harus konsisten.
• Buat mapping akun lama ke akun baru. Jangan berasumsi kode yang sama berarti akun yang sama.
• Identifikasi transaksi in-flight: PO belum di-GR, invoice belum lunas, retur belum diproses.
• Siapkan template impor final dan bekukan struktur kolomnya minimal H-14.

Data yang Sering Terlewat di Fase Ini

• Harga jual khusus per pelanggan (price list custom) yang selama ini hanya di kepala sales senior.
• Termin pembayaran per supplier yang berbeda-beda dan tidak terdokumentasi.
• Nomor seri atau batch untuk produk yang butuh traceability (obat, kosmetik, elektronik).
• Catatan internal per pelanggan seperti 'jangan kirim hari Jumat' atau 'harus PO tertulis'.
• Dokumen pendukung: kontrak, MoU, dan sertifikat yang sebelumnya tersimpan di drive shared.

Saat Migrasi (D-Day)

• Migrasikan saldo, bukan seluruh histori transaksi tahun berjalan.
• Lakukan test import di lingkungan staging terlebih dulu, minimal 2 kali putaran.
• Pilih tanggal cutover di jam operasional paling sepi (biasanya akhir minggu atau libur nasional).
• Freeze transaksi di sistem lama minimal 24 jam sebelum cutover.
• Siapkan tim rollback: siapa yang berhak menyatakan 'batal, kembali ke sistem lama'.
• Cetak neraca saldo akhir dari sistem lama dan simpan sebagai lampiran berita acara cutover.
• Verifikasi jumlah baris impor sama dengan jumlah baris sumber sebelum menekan 'commit'.

Kriteria Go / No-Go yang Wajib Disepakati

Sepakati sejak awal indikator yang membuat cutover dibatalkan: mis. selisih total piutang > 0,5%, jumlah SKU tidak match, atau modul faktur pajak belum terhubung ke Coretax. Tanpa kriteria eksplisit, keputusan rollback biasanya diambil terlambat karena tim sudah lelah.

Setelah Migrasi (H+1 sampai H+30)

• Cocokkan neraca saldo sistem baru dengan sistem lama pada tanggal cutover.
• Simpan sistem lama read-only minimal 12 bulan untuk audit.
• Latih tim di data nyata mereka, bukan data dummy vendor.
• Buat 'war room' harian selama 2 minggu pertama untuk menampung pertanyaan tim.
• Ukur adoption rate per modul; modul dengan adoption < 70% biasanya bermasalah di UX atau pelatihan.
• Jalankan closing paralel di bulan pertama: tutup buku di sistem lama dan baru, bandingkan hasilnya.
• Dokumentasikan setiap incident dan resolusinya di knowledge base internal — ini menjadi manual pelatihan berikutnya.

Risiko Klasik dan Cara Menghindarinya

Risiko 1: Cutover di bulan sibuk

Migrasi di bulan Ramadan, akhir tahun, atau musim panen adalah kombinasi tersibuk yang bisa Anda pilih. Volume transaksi tinggi menutup jendela waktu untuk memperbaiki masalah kecil. Pilih bulan sepi bahkan kalau itu berarti menunda go-live tiga bulan.

Risiko 2: Menambah scope di menit terakhir

Permintaan 'sekalian tarik modul payroll' seminggu sebelum go-live hampir selalu berujung tragedi. Bekukan scope minimal H-30 dan tunda semua permintaan baru ke fase 2.

Risiko 3: Tim IT internal kelelahan

Migrasi menyita waktu tim IT/finance jauh di atas normal. Kalau tidak ada backup untuk pekerjaan harian mereka, kualitas migrasi turun. Alokasikan pengganti sementara atau outsource pekerjaan rutin selama fase kritis.

Risiko 4: Data histori diminta dimigrasikan seluruhnya

Godaan untuk membawa 5 tahun histori transaksi ke sistem baru hampir selalu datang dari komisaris atau auditor. Tolak dengan tegas: histori bertahan lebih aman di sistem lama yang di-freeze. Yang perlu dimigrasikan hanyalah saldo pembuka dan transaksi in-flight.

Contoh Konkret: Retailer 8 Cabang

Sebuah retailer fashion dengan 8 cabang di Jabodetabek pindah dari sistem POS lama ke ERP terpadu. Total 12.000 SKU, 40.000 pelanggan aktif, dan 15 supplier utama. Fase persiapan menyita 6 minggu — sebagian besar untuk membersihkan duplikat pelanggan (14% dari total) dan menstandarkan UoM.

Cutover dijalankan di minggu pertama Februari (bulan sepi pasca-liburan) dan berjalan selama 36 jam. Bulan pertama pasca go-live tetap menemukan 27 masalah kecil (harga khusus, catatan pelanggan, aturan diskon musiman), tapi tidak ada yang bersifat blocker karena kriteria go/no-go sudah disepakati di awal. Tim finance menjalankan closing paralel di bulan pertama dan menemukan selisih Rp2,3 juta yang bisa dijelaskan (kurs) — bukan lubang misterius.

Kesalahan Umum yang Harus Dihindari

• Menganggap migrasi selesai di hari cutover — padahal fase pasca go-live justru paling menentukan.
• Tidak melibatkan operator harian dalam validasi hasil impor.
• Menyerahkan bersih-bersih master data sepenuhnya ke vendor — mereka tidak tahu bisnis Anda.
• Menghapus akses ke sistem lama terlalu cepat, sebelum sistem baru terbukti stabil.
• Tidak menyiapkan komunikasi ke pelanggan/supplier tentang perubahan nomor dokumen atau format invoice.

FAQ Singkat

Perlukah membawa histori transaksi tahun berjalan?

Idealnya tidak. Migrasikan saldo per tanggal cutover, dan simpan histori di sistem lama untuk audit. Kalau regulator meminta histori terintegrasi, pertimbangkan cutover di awal tahun fiskal supaya seluruh tahun berjalan tetap ada di satu sistem.

Berapa lama fase paralel di sistem lama dan baru?

Minimal satu siklus penuh laporan bulanan. Untuk bisnis dengan closing kompleks (manufaktur, multi-cabang), disarankan dua bulan. Setelah itu sistem lama dijadikan read-only sepenuhnya.

Apakah data pelanggan boleh dibersihkan setelah migrasi?

Boleh, tapi jangan menghapus di sistem baru. Nonaktifkan (soft delete) supaya jejak transaksi lama tetap terhubung. Menghapus permanen bisa merusak laporan histori yang butuh join ke master pelanggan.

Kesimpulan & Langkah Selanjutnya

Migrasi yang sukses adalah migrasi yang membosankan — semua checklist tercentang, tidak ada drama, dan tim tetap bisa tidur nyenyak di malam cutover. Kebosanan itu hasil dari persiapan berminggu-minggu sebelumnya, bukan keberuntungan.

Minggu ini, mulai dari satu langkah kecil: audit master pelanggan Anda dan cari duplikat berdasarkan nomor telepon atau NPWP. Angka duplikatnya akan mengejutkan — dan itu adalah gambaran jujur beban migrasi yang menunggu Anda.