Bagaimana Memindahkan Data dari Aplikasi Lama ke Sistem Baru Tanpa Melanggar UU PDP?
Migrasi data adalah pemindahan data dari aplikasi atau basis data lama ke sistem baru, dan ketika data itu memuat identitas orang, pemindahannya termasuk pemrosesan data pribadi menurut Undang-Undang Nomor 27 Tahun 2022. Sederhananya, memindahkan data bukan hanya soal kabel dan skrip, tetapi juga soal izin, catatan, dan bukti. Tulisan ini mengupas pemetaan data, penilaian dampak, penghapusan data lama, akurasi, keamanan, urutan strategi, pengalihan saat aksi korporasi, hingga daftar periksa yang bisa dibuktikan.
TLDR
Mengapa Migrasi Data Termasuk Urusan Hukum, Bukan Hanya Urusan Teknis?
Memindahkan data pelanggan atau karyawan ke sistem baru adalah pemrosesan data pribadi, sehingga kewajiban UU PDP ikut berlaku sejak skrip pertama dijalankan.
Apa yang Harus Dipetakan Sebelum Satu Baris Data Dipindahkan?
Perusahaan perlu mencatat data apa yang dimiliki, untuk tujuan apa, dan di sistem mana, karena UU PDP mewajibkan perekaman seluruh kegiatan pemrosesan.
Kapan Migrasi Wajib Disertai Penilaian Dampak Pelindungan Data?
Penilaian dampak wajib untuk pemrosesan berisiko tinggi, dan daftar pemicunya mencakup pencocokan atau penggabungan sekelompok data, yang sering terjadi saat migrasi.
Data Lama Mana yang Ikut Pindah dan Mana yang Harus Dihapus atau Dimusnahkan?
Data yang masa retensinya habis atau tujuannya sudah tercapai wajib diakhiri pemrosesannya, jadi migrasi adalah kesempatan terbaik untuk tidak membawa data yang tidak perlu.
Bagaimana Menjaga Data Tetap Akurat dan Konsisten Selama Pemindahan?
Pengendali wajib memastikan akurasi, kelengkapan, dan konsistensi data serta melakukan verifikasi, sehingga hasil migrasi harus dicocokkan dengan sumbernya.
Bagaimana Mengamankan Data Saat Dipindahkan dan Siapa yang Boleh Memegangnya?
Keamanan harus sesuai risiko data, pengawasan terhadap vendor adalah kewajiban pengendali, dan salinan sementara harus dikendalikan sampai dihapus.
Strategi Migrasi Apa yang Masuk Akal untuk Sistem Besar?
Panduan AWS menyarankan pemindahan lebih dulu lewat rehost, replatform, atau relocate, lalu modernisasi aplikasi setelah migrasi selesai.
Apa yang Berubah Jika Migrasi Terjadi karena Merger atau Pengambilalihan?
PP 33/2026 mengatur mekanisme pengalihan data saat aksi korporasi, termasuk pemberitahuan kepada pemilik data dan perjanjian antara pengendali lama dan baru.
Bagaimana Menyusun Daftar Periksa Migrasi yang Bisa Dibuktikan?
Daftar periksa dibagi tiga tahap, yaitu sebelum, selama, dan sesudah migrasi, dengan bukti tertulis di setiap tahap agar siap diaudit.
Kesimpulan
Migrasi yang rapi menghasilkan sistem baru sekaligus bukti kepatuhan, dan waktu paling murah untuk menyusunnya adalah sebelum PP 33/2026 berlaku pada 16 Januari 2027.
Banyak proyek modernisasi aplikasi berakhir dengan satu pertanyaan yang tidak ada di rencana awal: data lama mau diapakan? Tim teknis biasanya fokus pada fitur sistem baru, sedangkan basis data lama dianggap tinggal disalin. Padahal basis data itu berisi nama, nomor identitas, riwayat transaksi, dan catatan yang sudah menumpuk bertahun-tahun, termasuk data yang seharusnya sudah dihapus. Ketika semuanya dipindahkan apa adanya, kesalahan lama ikut pindah dan kewajiban hukum yang tertinggal ikut terbawa ke rumah baru. Tulisan ini membahas cara memindahkan data dengan rapi tanpa melanggar aturan pelindungan data pribadi.
Mengapa Migrasi Data Termasuk Urusan Hukum, Bukan Hanya Urusan Teknis?
Migrasi data yang memuat data pribadi adalah kegiatan pemrosesan, sehingga UU PDP berlaku penuh pada proyek itu. Perusahaan sebagai pengendali data tetap bertanggung jawab atas keamanan, akurasi, dan pengakhiran data, baik sebelum, selama, maupun sesudah data berpindah ke sistem baru.
Pasal 16 ayat (2) UU PDP merinci prinsip pemrosesan, antara lain bahwa pemrosesan dilakukan secara akurat, lengkap, tidak menyesatkan, mutakhir, dan dapat dipertanggungjawabkan. Prinsip yang sama menuntut data dimusnahkan atau dihapus setelah masa retensi berakhir atau atas permintaan pemilik data. Kedua prinsip ini langsung menyentuh pekerjaan migrasi, karena migrasi menyalin, mengubah format, dan memutuskan data mana yang ikut pindah.
RSM Indonesia dalam peringatan kliennya tertanggal 18 September 2026 mengingatkan bahwa PP 33/2026 bukan awal kewajiban kepatuhan. UU PDP sudah berlaku dan masa penyesuaian dua tahunnya sudah berakhir. PP 33/2026 diundangkan pada 16 Juli 2026, terdiri dari 225 pasal, dan menurut Pasal 225 mulai berlaku enam bulan kemudian, yaitu 16 Januari 2027.
Dalam bahasa proyek, artinya proyek migrasi yang berjalan sekarang sudah wajib patuh pada UU PDP, dan akan dinilai juga dengan rincian PP 33/2026 begitu aturan itu berlaku. Proyek yang selesai pada Desember 2026 pun bisa diperiksa dengan standar Januari 2027, karena sistem barunya akan beroperasi lama sesudah tanggal itu.
Ada satu kebiasaan yang perlu dihentikan sejak awal: menganggap data lama sebagai milik tim IT. Data itu milik pemiliknya, dan perusahaan hanya memegangnya untuk tujuan tertentu. Karena itu keputusan data mana yang dipindahkan, diubah, atau dibuang tidak boleh diambil sendirian oleh pengembang. Perlu ada pemilik data dari sisi bisnis, wakil dari bagian hukum atau kepatuhan, dan penanggung jawab teknis yang duduk bersama sebelum rencana migrasi disetujui.
Kerangka umum untuk menghubungkan sistem baru dengan sistem lama dibahas di Bagaimana Perusahaan Menghubungkan AI ke Sistem Lama Tanpa Membongkar Semuanya?. Tulisan ini melengkapinya dari sisi data: apa yang boleh dibawa, bagaimana membuktikannya, dan kapan harus berhenti.
Apa yang Harus Dipetakan Sebelum Satu Baris Data Dipindahkan?
Sebelum migrasi, perusahaan perlu memetakan jenis data pribadi, tujuan pemrosesan, lokasi penyimpanan, pihak yang mengakses, dan masa retensinya. Pemetaan ini bukan sekadar persiapan teknis, karena UU PDP mewajibkan perekaman seluruh kegiatan pemrosesan dan PP 33/2026 mengaitkannya dengan catatan kegiatan pemrosesan.
Pasal 31 UU PDP berbunyi: "Pengendali Data Pribadi wajib melakukan perekaman terhadap seluruh kegiatan pemrosesan Data Pribadi." Menurut RSM Indonesia, PP 33/2026 menegaskan kewajiban pengendali menyimpan catatan seluruh kegiatan pemrosesan dalam Pasal 74, yang menjadi dasar inventaris pemrosesan. Migrasi adalah kegiatan pemrosesan baru, sehingga ia sendiri harus masuk catatan itu.
Pemetaan yang baik menjawab lima pertanyaan untuk setiap kelompok data. Data apa yang dimiliki? Untuk tujuan apa data itu dikumpulkan? Di tabel, berkas, atau layanan mana ia tersimpan? Siapa yang punya akses? Sampai kapan boleh disimpan? Jawaban kelima pertanyaan ini menjadi dasar semua keputusan berikutnya, dari data mana yang pindah sampai kontrol apa yang dipasang di sistem baru.
Pemetaan juga harus menjangkau tempat yang jarang dipikirkan. Basis data utama hanyalah satu bagian. Data pribadi biasanya juga ada di berkas ekspor yang dibagikan lewat surel, tabel bantu buatan pengguna, cadangan lama, lingkungan uji, dan sistem pihak ketiga yang terhubung. Jika hanya basis data utama yang dipetakan, migrasi akan meninggalkan salinan di tempat yang tidak terkendali.
Hasil pemetaan sebaiknya dituangkan dalam satu dokumen yang bisa dipakai ulang oleh tim hukum, tim keamanan, dan tim proyek. Dokumen ini berisi kolom sumber, jenis data, tujuan, dasar pemrosesan, masa retensi, tujuan di sistem baru, dan keputusan: pindah, ubah, arsipkan, atau musnahkan. Dokumen yang sama kemudian menjadi lampiran bukti saat audit.
Contoh sederhana memperjelas manfaatnya. Bayangkan sebuah BUMN logistik yang hendak memindahkan sistem pelanggan lama. Lewat pemetaan, tim menemukan tabel yang menyimpan nomor identitas pelanggan padahal sistem baru tidak membutuhkannya, serta berkas ekspor lama di penyimpanan bersama. Dua temuan itu langsung mengubah rencana: kolom identitas tidak dimigrasikan dan berkas ekspor dihapus. Tanpa pemetaan, keduanya ikut pindah dan menjadi risiko baru di rumah baru. Jadi pemetaan bukan beban administrasi, melainkan alat untuk memindahkan lebih sedikit dan lebih aman.
Kapan Migrasi Wajib Disertai Penilaian Dampak Pelindungan Data?
Penilaian dampak pelindungan data wajib dilakukan bila pemrosesan berpotensi berisiko tinggi terhadap pemilik data. Pasal 34 ayat (2) UU PDP memuat daftar pemicunya, dan salah satunya adalah pencocokan atau penggabungan sekelompok data, kegiatan yang hampir selalu terjadi ketika beberapa sistem lama dilebur menjadi satu sistem baru.
Daftar pemicu dalam Pasal 34 ayat (2) mencakup pengambilan keputusan otomatis dengan dampak signifikan, pemrosesan data pribadi yang bersifat spesifik, pemrosesan dalam skala besar, evaluasi atau pemantauan sistematis, pencocokan atau penggabungan sekelompok data, penggunaan teknologi baru, dan pemrosesan yang membatasi pelaksanaan hak pemilik data. Satu pemicu saja sudah cukup untuk mewajibkan penilaian.
RSM Indonesia mencatat PP 33/2026 merinci pemicu serupa dalam Pasal 120, termasuk pencocokan atau penggabungan kumpulan data dan penggunaan teknologi baru seperti kecerdasan buatan dan pembelajaran mesin. RSM juga menyarankan perusahaan menentukan inisiatif mana yang perlu penilaian dampak, bukan menganggap semua proses dengan pihak ketiga atau lintas negara otomatis masuk cakupan.
Untuk migrasi, tiga kondisi paling sering memicu penilaian. Pertama, beberapa basis data pelanggan digabung menjadi satu, sehingga profil orang yang sama dicocokkan dan disatukan. Kedua, data yang selama ini terpisah menurut tujuan kini disatukan di satu gudang data. Ketiga, sistem baru memakai fitur analitik atau kecerdasan buatan yang sebelumnya tidak ada. Jika salah satunya berlaku, jadwalkan penilaian sebelum desain migrasi dikunci.
Penilaian dampak tidak perlu rumit. Isinya menjelaskan apa yang diproses, mengapa perlu, risiko terhadap pemilik data, dan langkah mengurangi risiko itu. Hasilnya langsung mengubah rencana: misalnya data sensitif tidak ikut digabung, akses dibatasi per peran, atau data disamarkan sebelum masuk gudang data. Panduan modernisasi secara menyeluruh ada di Panduan Modernisasi Aplikasi untuk Perusahaan dan BUMN di Indonesia.
Tiga pertanyaan cepat membantu tim memutuskan apakah penilaian dampak diperlukan sebelum desain migrasi dikunci:
Apakah ada data yang digabung? Jika beberapa basis data pelanggan atau karyawan dilebur dan orang yang sama dicocokkan, pemicu pencocokan atau penggabungan data kemungkinan berlaku.
Apakah ada data spesifik atau skala besar? Data yang bersifat spesifik atau volume yang besar sudah masuk daftar pemicu dalam Pasal 34 ayat (2).
Apakah ada teknologi baru di sistem tujuan? Fitur analitik atau kecerdasan buatan yang sebelumnya tidak ada termasuk penggunaan teknologi baru dalam pemrosesan.
Jawaban ya pada salah satunya cukup untuk menjadwalkan penilaian, dan hasilnya disimpan bersama dokumen perencanaan migrasi.
Data Lama Mana yang Ikut Pindah dan Mana yang Harus Dihapus atau Dimusnahkan?
Data yang masa retensinya sudah habis atau tujuan pemrosesannya sudah tercapai tidak boleh dipindahkan hanya karena sudah ada. Pasal 42 UU PDP mewajibkan pengendali mengakhiri pemrosesan dalam kondisi itu, sehingga migrasi adalah titik paling alami untuk membersihkan data yang seharusnya sudah tidak ada.
Pasal 42 ayat (1) menyebut tiga kondisi pengakhiran pemrosesan: masa retensi telah tercapai, tujuan pemrosesan telah tercapai, atau ada permintaan dari pemilik data. Pasal 43 mewajibkan penghapusan data yang tidak lagi diperlukan untuk tujuan pemrosesan atau yang diproses secara melawan hukum. Pasal 44 mewajibkan pemusnahan data yang masa retensinya habis menurut jadwal retensi arsip, dan Pasal 45 mewajibkan pemberitahuan penghapusan atau pemusnahan kepada pemilik data.
DDS Law Office dalam ulasannya tentang PP 33/2026 menulis: "Kebijakan retensi perlu diterapkan dalam sistem dan prosedur, bukan hanya dituangkan dalam dokumen." Kalimat itu pas untuk proyek migrasi. Jika sistem lama tidak pernah menghapus data karena tidak punya fitur penghapusan terjadwal, sistem baru harus punya fitur itu, dan data lama harus disaring sebelum masuk.
Dalam praktik, tim bisa memakai tiga keranjang. Keranjang pertama berisi data aktif yang masih punya tujuan jelas, dan ini yang dimigrasikan. Keranjang kedua berisi data yang masih wajib disimpan karena aturan lain, misalnya arsip tertentu, dan ini dipindahkan ke penyimpanan terbatas dengan akses ketat. Keranjang ketiga berisi data yang sudah melewati masa retensi, dan ini dimusnahkan dengan bukti, bukan dibawa ke sistem baru.
Aplikasi lama sendiri juga perlu dinilai. Panduan migrasi besar dari AWS menyebut strategi retire untuk aplikasi yang tidak lagi punya nilai bisnis atau yang bisa dimatikan untuk mengurangi biaya dan risiko keamanan. AWS memberi contoh kriteria aplikasi zombie, yaitu rata-rata pemakaian CPU dan memori di bawah 5 persen, serta aplikasi idle dengan pemakaian 5 sampai 20 persen selama 90 hari. Mematikan aplikasi seperti itu berarti data di dalamnya tidak perlu dipindahkan.
Bukti pemusnahan perlu dirancang sejak awal. Catat kelompok data yang dimusnahkan, dasar keputusannya, tanggal pelaksanaan, siapa yang melaksanakan, dan cara pemusnahan yang dipakai. Pasal 45 UU PDP mewajibkan pemberitahuan penghapusan atau pemusnahan data kepada pemilik data, sehingga catatan ini sekaligus menjadi bahan pemberitahuan. Jika suatu data harus tetap disimpan karena ketentuan peraturan lain, tulis aturan yang mendasarinya agar keputusan menyimpan tidak terlihat seperti kelalaian menghapus.
Bagaimana Menjaga Data Tetap Akurat dan Konsisten Selama Pemindahan?
Pengendali wajib memastikan akurasi, kelengkapan, dan konsistensi data serta melakukan verifikasi, menurut Pasal 29 UU PDP. Dalam migrasi, kewajiban ini berarti hasil pemindahan harus dicocokkan dengan sumbernya, bukan dianggap benar karena skrip selesai tanpa pesan galat.
Pasal 29 ayat (2) menyatakan bahwa dalam memastikan akurasi, kelengkapan, dan konsistensi, pengendali wajib melakukan verifikasi. Pasal 30 menambahkan tenggat: perbaikan atau pembaruan data wajib dilakukan paling lambat 3 x 24 jam sejak permintaan diterima, lalu hasilnya diberitahukan kepada pemilik data. Menurut RSM Indonesia, PP 33/2026 memperkuat prinsip akurasi dengan kewajiban operasional tentang kualitas data dalam Pasal 69.
Migrasi biasanya merusak akurasi lewat cara-cara yang bisa diperkirakan. Format tanggal berbeda antara sistem lama dan baru. Karakter khusus pada nama hilang saat konversi. Kolom teks bebas terpotong karena panjang kolom baru lebih pendek. Data ganda muncul ketika dua sistem digabung dan tidak ada aturan pencocokan yang jelas. Kesalahan seperti ini tampak kecil, tetapi bagi pemilik data, nama yang salah atau tagihan yang tertukar adalah masalah nyata.
Verifikasi yang layak mencakup tiga lapis. Lapis pertama membandingkan jumlah baris dan jumlah total per tabel antara sumber dan tujuan. Lapis kedua mengambil sampel acak, lalu membandingkan isi kolom penting satu per satu. Lapis ketiga meminta pemilik proses bisnis membuka data di sistem baru dan memastikan angka serta nama yang mereka kenal tampil benar. Ketiganya dicatat, termasuk selisih yang ditemukan dan cara memperbaikinya.
Simpan hasil verifikasi sebagai bukti. Jika suatu hari pemilik data meminta koreksi atau pengawas bertanya bagaimana perusahaan memastikan data tetap akurat sesudah migrasi, catatan itu menjawabnya dalam satu berkas. Tanpa catatan, perusahaan hanya bisa berkata sudah dicek, dan itu bukan bukti.
Satu kelemahan yang sering muncul adalah aturan pencocokan identitas. Dua sistem bisa menyimpan orang yang sama dengan ejaan nama atau format nomor yang berbeda, dan skrip penggabungan akan menebak jika tidak diberi aturan. Tentukan kunci pencocokan, apa yang dilakukan jika kecocokannya meragukan, dan siapa yang memutuskan. Data yang meragukan sebaiknya masuk antrean tinjauan manual, bukan digabung otomatis, karena penggabungan yang keliru sulit dibatalkan dan menyatukan data dua orang berbeda menjadi satu profil.
Bagaimana Mengamankan Data Saat Dipindahkan dan Siapa yang Boleh Memegangnya?
Keamanan data saat migrasi harus sepadan dengan sifat dan risiko data, dan pengawasan terhadap setiap pihak yang terlibat adalah kewajiban pengendali. Pasal 35 UU PDP mewajibkan langkah teknis operasional dan penentuan tingkat keamanan sesuai risiko, sedangkan Pasal 37 menuntut pengawasan terhadap setiap pihak yang terlibat.
Pasal 37 berbunyi: "Pengendali Data Pribadi wajib melakukan pengawasan terhadap setiap pihak yang terlibat dalam pemrosesan Data Pribadi di bawah kendali Pengendali Data Pribadi." Pasal 39 ayat (2) menambahkan bahwa pencegahan akses tidak sah dilakukan dengan sistem keamanan yang andal, aman, dan bertanggung jawab. Dalam migrasi, pihak yang terlibat mencakup vendor, penyedia cloud, dan siapa pun yang memegang berkas ekspor.
Risiko terbesar migrasi sering bukan peretas, melainkan salinan yang tertinggal. Berkas ekspor basis data disimpan di laptop pengembang, diunggah ke penyimpanan sementara untuk dibagikan antartim, atau dilampirkan di surel. Setelah migrasi selesai, tidak ada yang ingat menghapusnya. Karena itu, rencana migrasi perlu daftar semua salinan sementara, pemiliknya, tempat penyimpanannya, dan tenggat penghapusannya.
Beberapa kontrol dasar yang layak masuk rencana adalah data uji disamarkan sebelum keluar dari lingkungan produksi, kanal transfer dienkripsi, akses ke berkas migrasi dibatasi per orang dan dicatat, kredensial vendor dicabut begitu tugasnya selesai, dan penghapusan salinan dibuktikan dengan catatan. DDS Law Office juga menyebut pengendalian akses, pengelolaan akun, pencatatan aktivitas, pengelolaan vendor, dan penghapusan data sebagai hal yang perlu dinilai perusahaan.
Menurut RSM Indonesia, penunjukan prosesor harus berdasarkan ketentuan minimum menurut Pasal 14 PP 33/2026, dan prosesor yang melibatkan prosesor lain juga diatur. Pembahasan pembagian peran pengendali dan prosesor, lengkap dengan klausul kontrak, ada di Siapa yang Bertanggung Jawab atas Data Pribadi Saat Proyek IT Dikerjakan Vendor?.
Siapkan juga jalan mundur. Salinan sumber sebaiknya tetap utuh sampai verifikasi selesai, dan keputusan membatalkan migrasi dibuat berdasarkan kriteria tertulis, misalnya selisih jumlah baris di atas batas tertentu. Namun salinan sumber yang dipertahankan itu sendiri adalah data pribadi, sehingga ia perlu kontrol akses dan tenggat penghapusan yang sama ketatnya dengan data di sistem baru. Jalan mundur yang tidak punya tanggal berakhir mudah berubah menjadi arsip liar yang dilupakan.
Strategi Migrasi Apa yang Masuk Akal untuk Sistem Besar?
Untuk migrasi besar, panduan AWS menyarankan rehost, replatform, relocate, atau retire, dan tidak menyarankan refactor. Alasannya, refactor menggabungkan pemindahan dengan modernisasi aplikasi, sehingga paling kompleks dikelola. Aplikasi dipindahkan lebih dulu, baru dimodernisasi setelah migrasi selesai.
AWS Prescriptive Guidance menyebut tujuh strategi: retire, retain, rehost, relocate, repurchase, replatform, serta refactor atau re-architect. Untuk program migrasi besar, rekomendasinya mempersempit pilihan ke rehost, replatform, relocate, dan retire. Kalimat kuncinya: refactor tidak disarankan untuk migrasi besar karena melibatkan modernisasi aplikasi di tengah pemindahan.
Pelajaran ini berlaku juga untuk aspek data. Ketika perpindahan lokasi dan perubahan struktur data dikerjakan sekaligus, sulit memisahkan penyebab jika angka tidak cocok: apakah karena proses pemindahan atau karena transformasi? Pemisahan dua tahap memberi titik verifikasi yang jelas. Tahap pertama memastikan data tiba utuh, tahap kedua mengubah struktur dengan sumber yang sudah terbukti benar.
Pemisahan tahap juga memudahkan penilaian dampak dan pembuktian. Pada tahap pindah, risikonya terutama keamanan dan akurasi salinan. Pada tahap modernisasi, risikonya bergeser ke penggabungan data, fitur baru, dan penggunaan teknologi baru yang bisa memicu penilaian dampak. Dua tahap dengan dua catatan lebih mudah dijelaskan kepada pengawas daripada satu tahap besar yang mengubah semuanya.
Fondasi server, jaringan, dan cadangan yang menopang kedua tahap itu dibahas di Panduan Infrastruktur IT untuk Perusahaan dan BUMN di Indonesia. Untuk sistem yang sudah tidak punya sambungan masuk selama 90 hari atau lebih, AWS menyebutnya kandidat retire, jadi periksa dulu apakah sistem itu benar-benar perlu dipindahkan.
Contoh urutan yang bisa dipakai untuk sistem besar adalah tiga tahap. Tahap pertama memindahkan sistem ke infrastruktur baru lewat rehost atau relocate, dengan verifikasi jumlah dan sampel data. Tahap kedua membersihkan data yang sudah melewati masa retensi, dengan bukti pemusnahan. Tahap ketiga memodernisasi aplikasi dan struktur datanya, disertai penilaian dampak jika pemicunya muncul. Urutan ini sejalan dengan saran AWS untuk memodernisasi setelah migrasi selesai, dan memberi tiga paket bukti yang mudah diaudit.
Apa yang Berubah Jika Migrasi Terjadi karena Merger atau Pengambilalihan?
Jika data berpindah karena penggabungan, pemisahan, pengambilalihan, peleburan, atau pembubaran badan hukum, PP 33/2026 mengatur mekanisme pengalihan data pribadi secara khusus. Pengendali lama dan baru wajib memperhatikan ketentuan pelindungan data, termasuk pemberitahuan kepada pemilik data sebelum dan sesudah aksi korporasi.
Menurut FWP, PP 33/2026 mengatur mekanisme pengalihan data pada aksi korporasi mulai dari penilaian terhadap pemenuhan hak pemilik data dan kewajiban pelindungan data, pemberitahuan kepada pemilik data sebelum dan sesudah aksi korporasi, hingga penyusunan perjanjian pelindungan data pribadi antara pengendali lama dan baru. Ketentuan itu juga memperjelas tanggung jawab masing-masing pengendali.
DDS Law Office menekankan bahwa uji tuntas hukum tidak cukup hanya memeriksa kepemilikan aset, kontrak, dan perizinan. Data pribadi yang menjadi bagian dari kegiatan usaha juga perlu dipetakan, termasuk dasar pemrosesan, tujuan penggunaan, penyimpanan, akses, dan pengalihannya. Bagi tim IT, ini berarti peta data dari bagian sebelumnya menjadi bahan uji tuntas, bukan dokumen internal semata.
Skenario ini relevan bagi BUMN dan anak usahanya yang sedang ditata ulang. Ketika dua unit digabung, sistem kepegawaian, pelanggan, dan pengadaan mereka biasanya dilebur. Migrasi data menjadi bagian dari aksi korporasi itu, sehingga jadwal migrasi perlu menunggu penilaian hak pemilik data dan pemberitahuan yang diwajibkan, bukan sebaliknya.
Langkah praktisnya: libatkan bagian hukum sejak rencana aksi korporasi dibuat, bukan sesudah sistem selesai. Siapkan daftar kelompok data yang akan berpindah, draf pemberitahuan kepada pemilik data, dan draf perjanjian pelindungan data antarpengendali. Dengan begitu tim teknis bisa menjadwalkan cutover sesudah dokumen siap, dan bukan menunggu dokumen sambil sistem lama masih menyala.
Pengendali baru sebaiknya meninjau data yang diterima sebelum memasukkannya ke sistem produksi. Periksa apakah tujuan awal pengumpulan masih sesuai, apakah ada data yang seharusnya sudah dihapus, dan apakah catatan hak pemilik data ikut berpindah. DDS Law Office mengingatkan bahwa data yang dikumpulkan hanya karena dianggap mungkin berguna perlu dievaluasi kembali. Peninjauan ini memakai peta data dan catatan retensi yang sama dengan migrasi biasa, sehingga tim tidak perlu membuat metode baru.
Bagaimana Menyusun Daftar Periksa Migrasi yang Bisa Dibuktikan?
Daftar periksa migrasi paling mudah disusun dalam tiga tahap: sebelum, selama, dan sesudah migrasi. Setiap tahap menghasilkan bukti tertulis yang bisa ditunjukkan saat audit. RSM Indonesia mencatat PP 33/2026 menguatkan harapan agar organisasi dapat menunjukkan kepatuhan, bukan hanya menyatakannya.
Diagram tiga tahap migrasi data yang bisa dibuktikan. Diolah Burung Hantu Infratek dari UU 27/2022, RSM Indonesia, FWP, dan AWS Prescriptive Guidance.
Pada tahap sebelum migrasi, bukti yang disiapkan adalah peta data, keputusan pindah, ubah, arsipkan, atau musnahkan untuk tiap kelompok data, hasil penilaian dampak jika dipicu, perjanjian dengan vendor, dan daftar semua salinan sementara yang akan dibuat. Persetujuan dari pemilik data bisnis dan wakil hukum dicatat di dokumen yang sama.
Pada tahap selama migrasi, bukti berupa catatan akses ke berkas migrasi, hasil verifikasi jumlah baris dan sampel isi, catatan galat beserta perbaikannya, dan catatan pencabutan akses vendor. Jika ada permintaan koreksi atau akses dari pemilik data selama proyek, catat juga bagaimana permintaan itu dilayani dalam batas 3 x 24 jam yang diatur UU PDP.
Pada tahap sesudah migrasi, bukti berupa bukti penghapusan salinan sementara, bukti pemusnahan data yang sudah melewati masa retensi, pembaruan catatan kegiatan pemrosesan, dan pematian sistem lama yang terdokumentasi. Menurut RSM Indonesia, PP 33/2026 juga mengatur audit pelindungan data pribadi internal maupun eksternal bagi pengendali dalam Pasal 138, sehingga dokumen ini akan terpakai.
Terakhir, hubungkan daftar periksa ini dengan kontrak pemeliharaan, karena kewajiban tidak berhenti saat serah terima. Pembahasan klausul pemeliharaan, termasuk waktu respons dan pembaruan keamanan, ada di Apa yang Harus Ada dalam Kontrak Pemeliharaan Aplikasi Setelah Go-Live?. Dengan sekitar dua bulan menuju 16 Januari 2027, proyek yang sedang berjalan masih punya waktu untuk menyusun bukti ini dengan tenang.
Tunjuk satu penanggung jawab bukti, dan simpan semua dokumen di satu tempat yang bisa dibuka cepat. Menurut DDS Law Office, fungsi pejabat pelindungan data pribadi mencakup pemberian informasi dan saran kepatuhan, pemantauan kepatuhan, pemberian saran mengenai penilaian dampak, serta menjadi narahubung untuk isu pemrosesan data pribadi. Jika perusahaan sudah punya pejabat seperti itu, jadikan ia pemeriksa akhir daftar periksa sebelum sistem lama dimatikan, agar tidak ada langkah yang terlewat.
Pertanyaan yang Sering Diajukan
Apakah memindahkan data pelanggan ke sistem baru termasuk pemrosesan data pribadi?
Ya. Memindahkan, menyalin, mengubah format, dan menyimpan data pribadi ke sistem baru termasuk pemrosesan menurut UU PDP. Karena itu perusahaan sebagai pengendali tetap wajib menjaga keamanan, akurasi, dan mencatat kegiatan migrasi, sama seperti pemrosesan lain.
Apakah migrasi data wajib dilengkapi penilaian dampak pelindungan data?
Tidak otomatis, tetapi sering. Pasal 34 ayat (2) UU PDP menyebut pencocokan atau penggabungan sekelompok data, pemrosesan skala besar, dan penggunaan teknologi baru sebagai pemicu. Jika migrasi memenuhi salah satunya, penilaian dampak wajib dilakukan sebelum pemrosesan dimulai.
Apakah data lama yang sudah tidak dipakai harus ikut dipindahkan?
Tidak. Pasal 42 UU PDP mewajibkan pengendali mengakhiri pemrosesan saat masa retensi tercapai atau tujuan pemrosesan selesai. Data seperti itu sebaiknya dihapus atau dimusnahkan dengan bukti, sedangkan data yang masih wajib disimpan dipindahkan ke penyimpanan terbatas.
Kapan PP 33 Tahun 2026 mulai berlaku?
PP 33 Tahun 2026 diundangkan pada 16 Juli 2026 dan menurut Pasal 225 berlaku enam bulan kemudian, yaitu 16 Januari 2027. Kewajiban dasar dalam UU PDP sudah berlaku lebih dulu, sehingga proyek migrasi yang berjalan sekarang tetap harus patuh.
Apa yang berubah jika migrasi data dilakukan karena merger atau akuisisi?
PP 33/2026 mengatur mekanisme pengalihan data pada aksi korporasi, termasuk penilaian hak pemilik data, pemberitahuan sebelum dan sesudah aksi, serta perjanjian pelindungan data antara pengendali lama dan baru. Karena itu jadwal migrasi perlu menunggu langkah-langkah tersebut.
Kesimpulan
Migrasi data yang memuat data pribadi adalah pemrosesan yang diatur UU PDP, bukan sekadar pekerjaan salin dan tempel. Perusahaan perlu memetakan data, menilai apakah penilaian dampak diperlukan, menyaring data yang sudah melewati masa retensi, memverifikasi akurasi hasil pindah, mengawasi vendor dan salinan sementara, serta mencatat semuanya sebagai bukti. Strategi bertahap, pindah dulu baru modernisasi, membuat setiap langkah lebih mudah diverifikasi.
Langkah pertama yang paling murah adalah membuka rencana migrasi yang sedang berjalan dan mencocokkannya dengan daftar periksa di atas. Untuk proyek baru, masukkan pemetaan data dan keputusan retensi ke dokumen perencanaan sejak awal. Dengan sekitar dua bulan sebelum PP 33/2026 berlaku pada 16 Januari 2027, perusahaan yang menyusun bukti sekarang akan masuk tahun baru dengan sistem baru dan catatan yang siap diperiksa.
(Burung Hantu Infratek / Berbagai Sumber)
⚠️ Artikel ini seluruhnya diriset, ditulis, dan dikembangkan oleh AI internal Burung Hantu Infratek.
🦉 Burung Hantu Infratek adalah software house dan system integrator yang sudah berpengalaman lebih dari 5 tahun dalam pengembangan dan implementasi generative AI pada berbagai perusahaan dan institusi.
Sumber dan Referensi
[1] Undang-Undang Nomor 27 Tahun 2022 tentang Pelindungan Data Pribadi - JDIH Kemkomdigi
[2] Peraturan Pelaksana UU PDP Terbit: Ketentuan Penting PP 33 Tahun 2026 - FWP
[3] PP 33 Tahun 2026 tentang Pelindungan Data Pribadi dan Kewajiban Penting Perusahaan - DDS Law Office
[4] PP 33/2026: Six Implementation Priorities before 16 January 2027 - RSM Indonesia
[5] About the migration strategies - AWS Prescriptive Guidance