Pukul dua pagi, tim TI sebuah BPR menyelesaikan pemindahan data ke sistem baru. Pada pagi hari, seorang teller mencoba membuka rekening. Sistem menolak karena nomor rekening sudah dipakai. Di cabang lain, saldo tabungan seorang nasabah berbedca Rp1,2 juta dari buku tabungannya.

Tentunya kejadian seperti ini bukan disebabkan karena kerusakan perangkat. Penyebabnya biasanya data yang tidak lengkap, urutan pemindahan yang salah, atau sering kali disebabkan oleh testing yang dilewati karena mepetnya waktu migrasi.

Artikel ini membahas migrasi data core banking untuk BPR dan BPRS: apa yang harus dipindahkan, aturan yang mengikat, tahap yang perlu dilalui, cara menguji hasilnya, rencana cut-over dan rollback, serta bukti yang harus disimpan.

1. Migrasi bukan proyek TI semata

Migrasi data sering dianggap pekerjaan tim TI. Anggapan itu berbahaya. Data yang dipindahkan adalah saldo nasabah, riwayat kredit, agunan, dan catatan transaksi. Kesalahan satu angka bisa menjadi sengketa, temuan audit, atau laporan yang salah kepada OJK.

Karena itu, migrasi adalah proyek lintas fungsi. Tim TI menyiapkan alat dan infrastruktur. Tim operasional memeriksa hasil. Tim akuntansi merekonsiliasi saldo. Tim kepatuhan memastikan laporan tetap dapat disusun. Direksi mengambil keputusan go-live atau menunda.

Pembagian peran ini bukan formalitas. Ketika hanya tim TI yang memeriksa hasil migrasi, yang diperiksa adalah apakah data masuk, bukan apakah data benar. Kebenaran data hanya bisa dinilai oleh orang yang memahami arti angka itu.

2. Apa yang sebenarnya dipindahkan

Kata “data” terlalu luas untuk dijadikan rencana kerja. Sebelum menyusun jadwal, bank perlu memecah data menjadi beberapa kelompok.

Kelompok Contoh isi Risiko jika salah
Data induk nasabah Identitas, alamat, pekerjaan, status Nasabah tidak ditemukan atau data ganda
Data rekening dan saldo Nomor rekening, saldo, tanggal buka Saldo berbeda dan sengketa
Data kredit Pokok, bunga, agunan, kolektibilitas Laporan SLIK dan CKPN salah
Riwayat transaksi Mutasi, jurnal, tabungan Rekonsiliasi dan audit gagal
Parameter produk Suku bunga, nisbah, biaya, akad Perhitungan tidak sesuai kontrak
Pengguna dan hak akses User ID, peran, otorisasi Akses berlebih atau teller terkunci
Dokumen dan arsip Scan KTP, akad, bukti transaksi Tidak dapat ditunjukkan saat diperiksa

Pengelompokan ini penting karena setiap kelompok punya cara uji yang berbeda. Saldo diuji dengan rekonsiliasi. Hak akses diuji dengan simulasi peran. Riwayat transaksi diuji dengan menelusuri transaksi tertentu dari awal sampai akhir.

Tujuh kelompok data yang dipindahkan dalam migrasi core banking: data induk nasabah, rekening dan saldo, kredit, riwayat transaksi, parameter produk, pengguna dan hak akses, serta dokumen
Setiap kelompok data memerlukan cara uji yang berbeda; saldo tidak cukup diuji dengan menghitung jumlah baris.

Yang sering terlupakan adalah data yang tidak aktif. Rekening dorman, kredit lunas, dan nasabah yang sudah menutup rekening tetap harus dipindahkan. Alasannya bukan untuk pelayanan harian, tetapi untuk audit dan permintaan informasi di kemudian hari.

3. Aturan yang mengikat migrasi

Migrasi data tidak diatur dalam satu pasal khusus. Kewajibannya tersebar di beberapa aturan, dan semuanya tetap berlaku meskipun bank berganti sistem.

POJK 34/2025 Pasal 18 mewajibkan bank memastikan ketersediaan aplikasi inti dan rekam cadang data, baik diselenggarakan sendiri maupun bekerja sama dengan penyedia jasa TI. Rekam cadang dilakukan setiap akhir hari untuk seluruh data aktivitas bank.

Pasal 19 mewajibkan seluruh transaksi dicatat dalam pembukuan pada akhir hari yang sama. Selama migrasi, kewajiban ini tidak boleh tertunda. Jika cut-over berlangsung lebih dari satu hari, bank perlu skema pencatatan sementara yang tetap dapat direkonsiliasi.

Pasal 31 mengatur kemampuan aplikasi inti, termasuk pembukuan antarkantor, konsolidasi data, dan log aktivitas sistem. Artinya, sistem baru harus bisa menghasilkan data yang lengkap dan akurat sejak hari pertama, bukan setelah beberapa minggu penyesuaian.

Pasal 35 dan Pasal 36 mewajibkan pengelolaan data yang memperhatikan kualitas, sistem pengelolaan, dan pelindungan data pribadi. Migrasi yang menyalin data pribadi ke lingkungan uji tanpa pengamanan melanggar prinsip ini. Kewajiban pelindungan data pribadi secara umum dibahas di artikel UU PDP dan pelindungan data nasabah.

PADK 43/2025 menambahkan kewajiban yang lebih teknis. Jika terjadi perubahan besar pada sistem elektronik, bank wajib memiliki kebijakan dan prosedur penanganan migrasi data. PADK juga mewajibkan sistem mampu menampilkan kembali informasi secara utuh, termasuk dalam hal konversi, migrasi, dan rollback.

POJK 41/2017 Pasal 6 mewajibkan bank segera memperlihatkan buku, dokumen, data elektronik, dan keterangan yang diperlukan saat pemeriksaan. Jika data lama dihapus setelah migrasi, kewajiban ini tidak bisa dipenuhi.

Karena itu, migrasi yang baik selalu menyisakan dua hal: sistem lama yang masih bisa dibaca dan data historis yang bisa ditelusuri.

4. Delapan tahap migrasi

PADK 43/2025 menyebut tahap migrasi data dimulai dari rencana strategis, manajemen proyek, change management, pengujian, rencana kontinjensi, rekam cadang, manajemen penyedia jasa TI, dan post implementation review. Delapan tahap itu bisa diterjemahkan menjadi urutan kerja berikut.

Tahap 1: Rencana strategis. Tetapkan alasan migrasi, ruang lingkup, dan ukuran keberhasilan. Ukuran keberhasilan harus konkret, misalnya saldo seluruh produk cocok pada hari pertama dan laporan bulanan dapat disusun tanpa penyesuaian manual.

Tahap 2: Manajemen proyek. Bentuk tim dengan peran yang jelas, jadwal, anggaran, dan daftar risiko. Tim minimal mencakup TI, operasional, akuntansi, kepatuhan, dan perwakilan pengguna.

Tahap 3: Change management. Siapkan prosedur perubahan, pelatihan, komunikasi ke cabang, dan rencana mundur. Perubahan besar tanpa sosialisasi akan berhenti di meja teller, bukan di ruang server.

Tahap 4: Pengujian. Uji pemetaan data, uji fungsi, uji laporan, dan uji beban. Pengujian harus memakai data yang menyerupai produksi, termasuk kasus aneh seperti rekening dengan dua pemilik atau kredit yang direstrukturisasi.

Tahap 5: Rencana kontinjensi. Siapkan skenario jika migrasi gagal, termasuk keputusan siapa yang berwenang menghentikan proses dan kembali ke sistem lama.

Tahap 6: Rekam cadang. Ambil cadangan penuh sebelum cut-over dan pastikan cadangan itu bisa dipulihkan. Cadangan yang belum diuji restore bukan jaminan.

Tahap 7: Manajemen penyedia jasa TI. Pastikan peran vendor, batas tanggung jawab, akses, dan kewajiban serah terima data tertulis dalam kontrak.

Tahap 8: Post implementation review. Nilai hasil migrasi setelah sistem berjalan, catat penyimpangan, dan tutup temuan sebelum proyek dinyatakan selesai.

Delapan tahap migrasi data core banking: rencana strategis, manajemen proyek, change management, pengujian, rencana kontinjensi, rekam cadang, manajemen penyedia jasa TI, dan post implementation review
Migrasi yang aman bergerak berurutan; melompati tahap pengujian berarti memindahkan risiko ke hari go-live.

Urutan ini bukan satu-satunya cara. Bank yang lebih kecil bisa menggabungkan beberapa tahap dalam satu dokumen. Yang tidak boleh digabung adalah pengujian dan cut-over, karena keduanya membutuhkan sikap yang berbeda: pengujian mencari kesalahan, cut-over harus berjalan tanpa kesalahan.

5. Uji sebelum go-live

Pengujian migrasi punya satu tujuan: membuktikan bahwa sistem baru menghasilkan angka yang sama dengan sistem lama untuk transaksi yang sama.

Uji pemetaan data. Periksa apakah setiap kolom di sistem lama memiliki tujuan yang benar di sistem baru. Kolom yang tidak dipetakan harus didaftar dan dijelaskan, bukan dibiarkan kosong.

Uji fungsi. Jalankan proses harian: buka rekening, setor, tarik, bayar angsuran, cetak buku, tutup rekening. Lakukan juga proses yang jarang dipakai, seperti pembatalan transaksi dan koreksi jurnal.

Uji laporan. Hasilkan laporan APOLO, SLIK, laporan keuangan, dan laporan publikasi dari data hasil migrasi. Laporan yang tidak bisa dihasilkan berarti data pendukungnya hilang atau formatnya berubah. Tenggat pelaporan APOLO dijelaskan di panduan lapor APOLO untuk BPR.

Uji hak akses. Masuk sebagai teller, supervisor, dan administrator. Pastikan setiap peran hanya bisa membuka menu yang seharusnya. Uji juga akun yang dinonaktifkan.

Uji beban. Jalankan transaksi bersamaan sesuai volume jam sibuk. Migrasi yang berhasil pada data kecil bisa gagal ketika antrean transaksi panjang.

Uji rollback. Kembalikan sistem ke kondisi sebelum migrasi, lalu pastikan data lama masih utuh. Uji ini sering dilewati karena dianggap membuang waktu, padahal justru inilah yang menentukan apakah bank punya jalan keluar.

PADK 43/2025 juga menyebut parallel run, yaitu menjalankan sistem lama dan baru bersamaan sampai data baru dipastikan akurat dan andal. Parallel run menambah beban kerja, tetapi memberi perbandingan langsung yang sulit digantikan oleh pengujian lain.

6. Rekonsiliasi: inti dari migrasi

Rekonsiliasi adalah pekerjaan paling penting dan paling sering kurang disiapkan. Tanpa rekonsiliasi, tim hanya tahu bahwa data sudah masuk, bukan bahwa data itu benar.

Rekonsiliasi migrasi paling sedikit membandingkan:

  1. Jumlah nasabah antara sistem lama dan baru, termasuk nasabah tanpa rekening aktif.
  2. Jumlah rekening per produk dan per cabang.
  3. Saldo per rekening untuk seluruh rekening, bukan hanya sampel.
  4. Total saldo per produk, per cabang, dan seluruh bank.
  5. Saldo kredit termasuk pokok, bunga, dan tunggakan.
  6. Jumlah transaksi historis per periode dan total nilainya.

Selisih harus dijelaskan satu per satu. Penjelasan yang dapat diterima misalnya pembulatan yang disepakati atau transaksi yang memang dibatalkan sebelum cut-over. Penjelasan yang tidak dapat diterima misalnya “selisih kecil” atau “akan diperbaiki setelah go-live”.

Rekonsiliasi sebaiknya dilakukan tiga arah: saldo di sistem lama, saldo di sistem baru, dan saldo di buku besar. Jika ketiganya cocok, keyakinan atas hasil migrasi jauh lebih tinggi daripada hanya membandingkan dua sistem. Perbedaan pada rekening antarbank dan akun antar kantor juga perlu diperiksa, karena selisih di sana sering baru terlihat saat tutup buku.

PADK 43/2025 secara khusus meminta bank menghindari patching data saat implementasi karena dapat memengaruhi integritas basis data. Artinya, memperbaiki data dengan mengubah langsung di server produksi bukan solusi. Jika ada data yang salah, perbaikannya harus melalui prosedur, tercatat, dan dapat diaudit.

7. Rencana cut-over dan rollback

Cut-over adalah periode ketika sistem lama berhenti dan sistem baru mulai dipakai. Periode ini biasanya berlangsung di luar jam layanan, tetapi dampaknya terasa pada hari kerja berikutnya.

Rencana cut-over perlu memuat:

  • Waktu mulai dan selesai untuk setiap langkah, bukan hanya waktu go-live.
  • Pihak yang memberi persetujuan di setiap titik keputusan.
  • Batas toleransi selisih yang masih dapat diterima, yang ditetapkan sebelum hari-H.
  • Kriteria rollback yang jelas, misalnya selisih saldo melebihi batas atau uji transaksi kunci gagal.
  • Pihak yang berwenang memutuskan rollback, agar keputusan tidak diambil berdasarkan debat di grup pesan.
  • Rencana komunikasi ke cabang, nasabah, dan pengawas jika layanan terganggu.

Kriteria rollback harus disepakati sebelum cut-over. Jika kriteria ditentukan saat masalah muncul, keputusan akan dipengaruhi rasa panik dan keinginan menyelesaikan proyek.

Hal yang sama berlaku untuk data lama. PADK 43/2025 meminta bank mengatur penyimpanan kode sumber dan basis data sistem lama. Sistem lama tidak cukup dimatikan. Ia harus tetap dapat dibaca jika suatu saat diperlukan untuk pembuktian.

Enam kontrol kunci migrasi data: rekonsiliasi menyeluruh, parallel run, batas toleransi selisih, kriteria rollback, larangan patching langsung, dan penyimpanan data lama
Kontrol migrasi bertumpu pada angka yang direkonsiliasi dan keputusan rollback yang disepakati sebelum hari-H.

8. Risiko dan kontrol

Risiko Kontrol
Data tidak lengkap Hitung jumlah baris per tabel dan bandingkan dengan sumber
Data ganda Terapkan aturan unik pada nomor rekening dan identitas nasabah
Saldo berbeda Rekonsiliasi per rekening, per produk, dan per cabang
Riwayat transaksi hilang Uji penelusuran transaksi lama sampai ke jurnal
Hak akses berlebih Uji peran dan hapus akun yang tidak diperlukan
Layanan berhenti terlalu lama Siapkan prosedur layanan darurat dan komunikasi cabang
Rollback gagal Uji rollback sebelum cut-over, bukan setelah masalah muncul
Data uji bocor Gunakan data tersamar dan batasi akses ke lingkungan uji

Risiko yang paling sering menjadi kenyataan bukan risiko teknis yang rumit. Yang sering terjadi adalah data ganda karena aturan unik tidak diterapkan, dan hak akses berlebih karena akun lama disalin tanpa diperiksa.

9. Setelah go-live

Go-live bukan akhir proyek. Beberapa minggu pertama menentukan apakah migrasi benar-benar berhasil.

Hypercare. Tetapkan masa pengawasan intensif dengan tim yang siap dihubungi, daftar masalah harian, dan waktu penyelesaian. Catat setiap keluhan cabang, sekecil apa pun.

Rekonsiliasi harian. Bandingkan saldo dan jumlah transaksi setiap hari sampai stabil. Jangan menunggu akhir bulan untuk menemukan selisih.

Post implementation review. PADK 43/2025 mewajibkan kaji ulang pasca implementasi untuk memastikan seluruh aktivitas proyek telah dilaksanakan dan tujuan tercapai. Kaji ulang ini juga menjadi bahan audit intern.

Audit intern. POJK 34/2025 Pasal 40 mewajibkan audit intern atas penyelenggaraan TI paling sedikit sekali dalam setahun, serta ketersediaan jejak audit untuk pengawasan dan pemeriksaan. Migrasi adalah salah satu area yang wajar diperiksa. Pola pemeriksaan TI oleh OJK dibahas di persiapan pemeriksaan OJK sistem IT BPR/BPRS.

Pelaporan. Jika migrasi menimbulkan gangguan layanan atau insiden, kewajiban pelaporan kepada OJK mengikuti ketentuan yang berlaku. Jangan menunggu sampai insiden menjadi temuan.

10. Bukti yang harus disimpan

Saat pengawas meminta penjelasan, bank tidak cukup mengatakan bahwa migrasi berjalan lancar. Bank perlu menunjukkan bukti.

Bukti yang sebaiknya diarsipkan:

  • Dokumen kebijakan dan prosedur migrasi.
  • Rencana proyek, jadwal, dan daftar risiko.
  • Berita acara pengujian dan persetujuan pengguna.
  • Kertas kerja rekonsiliasi saldo sebelum dan sesudah migrasi.
  • Bukti uji rollback dan uji restore cadangan.
  • Daftar masalah yang ditemukan beserta penyelesaiannya.
  • Laporan post implementation review.
  • Kontrak dan berita acara serah terima dengan penyedia jasa TI.

Bukti ini bukan tumpukan dokumen untuk mengisi lemari. Fungsinya adalah menunjukkan bahwa bank mengambil keputusan berdasarkan pemeriksaan, bukan berdasarkan asumsi. Dalam pemeriksaan, kemampuan menjelaskan proses sering sama pentingnya dengan hasilnya.

11. Peran vendor dan kontrak

Vendor core banking biasanya menyediakan alat migrasi, pemetaan data, dan bantuan teknis. Namun, tanggung jawab akhir tetap berada di bank.

Kontrak perlu mengatur:

  • Ruang lingkup migrasi, termasuk data apa saja yang dipindahkan dan siapa yang menyiapkan ekstraksi.
  • Kriteria penerimaan, misalnya rekonsiliasi saldo tanpa selisih yang tidak dijelaskan.
  • Batas waktu dan dukungan selama hypercare.
  • Kepemilikan dan pengembalian data, termasuk format dan tenggat penyerahan.
  • Kerahasiaan dan pelindungan data pribadi, termasuk larangan memakai data produksi untuk pengujian tanpa pengamanan.
  • Tanggung jawab jika migrasi gagal, termasuk biaya pemulihan.

HeaBank memiliki modul migrasi data dari sistem lama yang membantu pemetaan dan pemindahan data. Modul itu mengurangi pekerjaan teknis, tetapi tidak menggantikan rekonsiliasi dan persetujuan pengguna. Pilihan penempatan sistem juga memengaruhi strategi migrasi; perbandingannya ada di core banking cloud vs on-premise. Rincian produknya ada di halaman core banking HeaBank.

12. Kesalahan umum

Pertama, menganggap migrasi sebagai pekerjaan TI. Tim operasional dan akuntansi baru dilibatkan saat masalah muncul.

Kedua, menguji dengan data contoh yang terlalu bersih. Data produksi selalu memiliki kasus aneh yang tidak muncul di data uji.

Ketiga, melewati parallel run. Perbandingan langsung dianggap mahal, padahal selisih yang ditemukan lebih mahal.

Keempat, tidak menetapkan batas toleransi selisih. Setiap selisih diperdebatkan, dan keputusan diambil berdasarkan siapa yang paling bersuara.

Kelima, memperbaiki data langsung di produksi. Cara ini merusak integritas dan meninggalkan jejak yang sulit dipertanggungjawabkan.

Keenam, menghapus sistem lama terlalu cepat. Data lama masih diperlukan untuk audit dan pemeriksaan.

Ketujuh, menganggap go-live sebagai akhir. Masa hypercare dan kaji ulang justru menentukan apakah masalah kecil berubah menjadi temuan.

13. Kesimpulan

Migrasi data core banking bukan proyek memindahkan file. Ia adalah proyek membuktikan bahwa angka yang dipakai bank sehari-hari tetap benar setelah sistem berganti.

Kuncinya ada tiga: rencana yang mengikuti tahap PADK 43/2025, pengujian yang berani mencari kesalahan, dan rekonsiliasi yang menjelaskan setiap selisih. Ketiganya harus ditutup dengan bukti yang bisa diperiksa.

Aturan yang berlaku menuntut hal yang sama. POJK 34/2025 meminta pencatatan transaksi pada hari yang sama, rekam cadang harian, aplikasi inti yang mampu mengonsolidasikan data, serta jejak audit. PADK 43/2025 meminta kebijakan migrasi, pengujian, parallel run, larangan patching data, dan kaji ulang pasca implementasi.

Bank yang menyiapkan migrasi dengan sabar akan menghadapi go-live sebagai peristiwa yang membosankan. Itu tanda yang baik. Migrasi yang menarik untuk diceritakan biasanya adalah migrasi yang bermasalah.

Referensi

  1. Otoritas Jasa Keuangan — “POJK Nomor 34 Tahun 2025 tentang Penyelenggaraan Teknologi Informasi oleh Bank Perekonomian Rakyat dan Bank Perekonomian Rakyat Syariah”. https://ojk.go.id/id/regulasi/Pages/POJK-34-Tahun-2025-Penyelenggaraan-Teknologi-Informasi-oleh-Bank-Perekonomian-Rakyat-dan-Bank-Perekonomian-Rakyat-Syariah.aspx
  2. Otoritas Jasa Keuangan — “PADK Nomor 43/PADK.03/2025 tentang Penyelenggaraan Teknologi Informasi oleh BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/PADK-43-PADK03-2025-Penyelenggaraan-Teknologi-Informasi-oleh-BPR-BPRS.aspx
  3. Otoritas Jasa Keuangan — “POJK Nomor 75/POJK.03/2016 tentang Standar Penyelenggaraan Teknologi Informasi bagi Bank Perkreditan Rakyat dan Bank Pembiayaan Rakyat Syariah”. https://peraturan.bpk.go.id/Details/129781/peraturan-ojk-no-75-pojk032016-tahun-2016
  4. Otoritas Jasa Keuangan — “POJK Nomor 41 Tahun 2017 tentang Persyaratan dan Tata Cara Pemeriksaan Bank”. https://ojk.go.id/id/regulasi/Pages/Persyaratan-dan-Tata-Cara-Pemeriksaan-Bank-.aspx
  5. Otoritas Jasa Keuangan — “POJK Nomor 9 Tahun 2024 tentang Penerapan Tata Kelola bagi BPR dan BPRS”. https://ojk.go.id/id/regulasi/Pages/POJK-9-2024-Penerapan-Tata-Kelola-bagi-BPR-dan-BPRS.aspx
  6. Republik Indonesia — “Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi”. https://peraturan.bpk.go.id/Details/229798/uu-no-27-tahun-2022
  7. Otoritas Jasa Keuangan — “POJK Nomor 12 Tahun 2024 tentang Strategi Anti Fraud bagi Lembaga Jasa Keuangan”. https://peraturan.bpk.go.id/Details/301737/peraturan-ojk-no-12-tahun-2024