Migrasi data bertanggung jawab atas lebih dari 75% masalah implementasi ERP, namun secara konsisten menjadi fase yang paling kurang didanai dan ditunda. Klien selalu meremehkan timeline-nya, dan skala sebenarnya baru terlihat ketika tim membuka file legacy dan menemukan merged cell, format tanggal yang tidak konsisten, catatan pelanggan duplikat, serta kode produk yang digunakan ulang untuk item yang sudah dihentikan.
Post ini merekomendasikan menjalankan setidaknya tiga kali uji coba migrasi sebelum go-live. Uji coba pertama mengungkapkan kesalahan struktural seperti pemetaan kolom yang salah dan bidang wajib yang hilang. Uji coba kedua menangkap kesalahan logika bisnis seperti tanggal di luar rentang valid dan jumlah yang tidak balance. Uji coba ketiga adalah latihan final — harus selesai dengan bersih dan sesuai jumlah catatan yang diharapkan; jika gagal, proyek belum siap go-live.
Pembersihan data adalah tugas bisnis dengan dukungan IT, bukan semata-mata tugas IT — bisnis yang memiliki data dan harus memvalidasinya. Untuk setiap jenis entitas (pelanggan, vendor, produk, karyawan), seorang data steward bisnis ditunjuk sebagai penanggung jawab template validasi terstruktur: spreadsheet dengan satu baris per catatan, kolom bidang wajib, dan kolom status (Bersih, Perlu Ditinjau, Duplikat, Hapus). Pembersihan harus selesai sebelum UAT dimulai.
Untuk sebagian besar UKM Indonesia, memigrasikan transaksi 2–3 tahun terakhir sudah cukup. Data yang lebih lama dapat diarsipkan dalam format aslinya dan diakses saat dibutuhkan. Mencoba memigrasikan 10 tahun data historis yang berantakan akan menambah berbulan-bulan ke proyek dan menimbulkan risiko kualitas; pendekatan yang direkomendasikan adalah menetapkan tanggal cutoff data historis yang jelas di awal dan menjadikan sistem lama sebagai arsip.
Setelah setiap uji coba, tiga pemeriksaan harus lulus semua: validasi jumlah catatan (jumlah catatan di sumber sama dengan jumlah di target dikurangi pengecualian yang disengaja), validasi saldo keuangan (saldo AR, AP, dan nilai inventori di sistem baru cocok dengan periode tutup buku terakhir dari sistem lama), dan validasi spot check (20–30 catatan acak dari setiap jenis entitas diverifikasi secara manual oleh data steward bisnis).
Migrasi data bertanggung jawab atas lebih dari 75% masalah implementasi ERP, namun secara konsisten menjadi fase yang paling kurang didanai dan ditunda dari setiap proyek. Dalam setiap implementasi ERP yang pernah saya kerjakan sebagai konsultan ERP lepas, timeline migrasi data diremehkan oleh klien. Posting ini adalah panduan praktisi untuk melakukan migrasi data dengan benar.
Sebelum satu baris kode ERP ditulis, jalankan audit data. Audit menjawab empat pertanyaan: Di mana data Anda? Format apa? Seberapa kotor? Berapa banyak yang benar-benar Anda butuhkan di sistem baru? Sebagian besar UKM Indonesia memiliki data di tiga hingga lima tempat: spreadsheet akuntansi utama, file HR terpisah, data master vendor dan pelanggan, dan catatan transaksi historis.
Masalah kualitas data paling umum yang saya temui dalam migrasi UKM Indonesia: catatan duplikat, bidang wajib yang hilang (tidak ada nomor NPWP untuk catatan vendor), pengkodean yang tidak konsisten, ketidakkonsistenan format tanggal, dan catatan 'mati' yang belum dibersihkan. Masing-masing memerlukan strategi remediasi spesifik sebelum migrasi.
Pembersihan data bukan tugas IT — ini adalah tugas bisnis dengan dukungan IT. Bisnis memiliki data dan bisnis harus memvalidasinya. Untuk setiap jenis entitas, tunjuk data steward bisnis yang bertanggung jawab membersihkan domain mereka. Tetapkan tenggat waktu yang keras: pembersihan data harus selesai sebelum UAT dimulai, bukan setelahnya.
ERP Data Migration Pipeline (Excel/Access → PostgreSQL)
SOURCE SYSTEMS STAGING DB TARGET ERP
┌───────────────┐ ┌──────────────┐ ┌──────────────┐
│ Excel Files │──extract──▶│ customers │ │ │
│ (many sheets) │ │ vendors │──load──▶│ ERP │
├───────────────┤ │ products │ │ PostgreSQL │
│ Access DB │──extract──▶│ invoices │ │ (clean) │
│ (.mdb/.accdb) │ │ employees │ │ │
├───────────────┤ └──────┬───────┘ └──────────────┘
│ Old ERP │──export──▶ │
│ (CSV export) │ TRANSFORM STAGE
└───────────────┘ ┌──────▼───────────────────────────┐
│ 1. Remove duplicates │
│ 2. Standardize date formats │
│ 3. Validate required fields │
│ 4. Map old codes → new codes │
│ 5. Validate referential integrity │
│ 6. Flag records needing review │
└──────────────────────────────────┘
DRY RUN CHECKLIST (run 3 times before go-live):
Run 1: Fix structural errors (column mappings, missing fields)
Run 2: Fix business logic errors (dates, balances, codes)
Run 3: Dress rehearsal — must complete cleanly ✓Dari pengalaman saya mengimplementasikan ERP saat menjadi konsultan ERP lepas untuk klien: jalankan uji coba migrasi data setidaknya tiga kali sebelum go-live. Uji coba pertama mengungkapkan kesalahan struktural. Uji coba kedua mengungkapkan kesalahan logika bisnis. Uji coba ketiga adalah latihan — harus selesai dengan bersih.
Pipeline migrasi yang kuat memiliki tiga tahap: Extract (tarik data dari sistem sumber), Transform (bersihkan, petakan, dan validasi), dan Load (masukkan ke database ERP target). Untuk sistem sumber Excel dan Access, tahap ekstrak menggunakan skrip Python untuk membaca file dan menormalkan data ke dalam database staging.
# Python: Extract from Excel → Staging DB → Validate
import pandas as pd
import psycopg2
from datetime import datetime
# Stage 1: Extract
df = pd.read_excel("vendor_master.xlsx", sheet_name="Vendors")
# Stage 2: Profile — identify quality issues
print("=== DATA PROFILE ===")
print(f"Total rows: {len(df)}")
print(f"Null NPWP: {df['npwp'].isna().sum()}")
print(f"Duplicate vendor_code: {df['vendor_code'].duplicated().sum()}")
print(f"Invalid email: {df[~df['email'].str.contains('@', na=False)].shape[0]}")
# Stage 3: Transform
def standardize_date(val):
"""Handle multiple date formats from Indonesian Excel files"""
formats = ['%d/%m/%Y', '%d-%m-%Y', '%Y-%m-%d', '%d %b %Y']
for fmt in formats:
try:
return datetime.strptime(str(val), fmt).date()
except (ValueError, TypeError):
continue
return None # Flag for review
df['created_date'] = df['created_date_raw'].apply(standardize_date)
df['vendor_code'] = df['vendor_code'].str.upper().str.strip()
# Remove duplicates — keep most recent
df = df.sort_values('created_date', ascending=False)
df = df.drop_duplicates(subset=['vendor_code'], keep='first')
# Stage 4: Validate
invalid_rows = df[df['npwp'].isna() | df['email'].isna()]
print(f"Rows needing review: {len(invalid_rows)}")
invalid_rows.to_excel("vendor_review_needed.xlsx", index=False)
# Stage 5: Load clean rows
clean_df = df[df['npwp'].notna() & df['email'].notna()]
print(f"Clean rows ready to load: {len(clean_df)}")Setelah setiap uji coba migrasi, validasi dengan tiga pemeriksaan: validasi jumlah catatan, validasi saldo keuangan, dan validasi spot check. Semua tiga pemeriksaan harus lulus sebelum Anda dapat menyatakan migrasi siap.
Kesalahan umum adalah mencoba memigrasikan setiap catatan historis ke ERP baru. Untuk sebagian besar UKM Indonesia, memigrasikan transaksi 2–3 tahun terakhir sudah cukup — data yang lebih lama dapat diarsipkan dalam format aslinya. Tentukan tanggal cutoff data historis yang jelas di awal dan patuhi itu.
Migrasi final — dari hari terakhir parallel running hingga go-live — adalah operasi data paling berisiko tinggi dalam proyek. Rencanakan migrasi cutover dalam buku panduan yang terperinci: setiap langkah, siapa yang mengeksekusinya, berapa lama waktu yang dibutuhkan, cara memverifikasi selesai, dan apa yang dilakukan jika gagal.
Kualitas data tidak berakhir saat go-live. Data baru memasuki sistem setiap hari, dan tanpa proses tata kelola data, kualitas akan menurun dari waktu ke waktu. Tetapkan standar entri data, tunjuk data steward per jenis entitas, dan siapkan peringatan otomatis untuk pelanggaran kualitas data.