Menguji Migrasi dengan Shadow Import

Shadow import adalah perbedaan antara "kami menemukan 3 error pemetaan di sandbox" dan "kami menemukan 3 error pemetaan pada hari cutover dengan 30 rep yang menunggu." Proses ini membutuhkan 2–3 jam untuk dijalankan dengan benar. Ini mencegah jenis masalah yang menunda go-live selama seminggu.

Satu tim migrasi melewatkan shadow import karena mereka sudah menguji di spreadsheet. Mereka memverifikasi field mapping terlihat benar di Excel, mengkonfirmasi nilai picklist sudah sesuai, dan merasa yakin. Pada hari cutover, mereka menemukan bahwa field relasi antara Kontak dan Deal tidak terselesaikan — alat import menangani lookup asosiasi secara berbeda dari yang disarankan oleh perbandingan spreadsheet. Setiap deal dalam sistem terputus dari kontaknya. Cutover ditunda selama lima hari sementara mereka menyelesaikan asosiasi secara manual. Jenis kegagalan relasi ini lebih sulit untuk dikenali jika Anda belum memetakan desain model data CRM tujuan sebelum menjalankan uji.

Shadow import di sandbox yang sebenarnya akan menangkapnya dalam 10 menit pertama.

Panduan ini memandu Anda melalui proses shadow import lengkap: setup, pemilihan dataset uji, proses import itu sendiri, verifikasi QA, dan kriteria persetujuan yang mempersiapkan Anda untuk cutover.

Langkah 1: Siapkan Sandbox atau Lingkungan Uji

Anda memerlukan instance nyata dari CRM tujuan — bukan perbandingan spreadsheet, bukan pemeriksaan visual berdampingan. Tujuannya adalah menjalankan tooling import Anda yang sebenarnya terhadap lingkungan CRM yang sebenarnya dan melihat apa yang terjadi.

HubSpot: Akun sandbox HubSpot tersedia di tingkat Professional dan Enterprise. Pergi ke Pengaturan > Manajemen Akun > Sandbox. Buat sandbox, kemudian konfigurasikan properti kustom, tahap pipeline, dan definisi lifecycle stage yang sama yang ada di akun produksi Anda. Sandbox harus mencerminkan setup produksi — jika tidak, Anda menguji terhadap konfigurasi yang berbeda dari yang akan Anda gunakan pada hari cutover. Dokumentasi sandbox HubSpot mencakup apa yang tersinkronisasi secara otomatis dari produksi dan apa yang harus Anda konfigurasikan secara manual.

Salesforce: Salesforce memiliki beberapa jenis sandbox. Untuk pengujian migrasi, sandbox Developer sudah cukup — memiliki konfigurasi yang sama (objek, field, nilai picklist) dengan produksi. Setup > Lingkungan > Sandbox > Sandbox Baru.

Pipedrive: Pipedrive tidak memiliki sandbox native. Buat akun trial gratis dengan alamat email yang berbeda. Konfigurasikan agar sesuai dengan tahap pipeline dan field kustom produksi Anda. Batas tier gratis sudah cukup untuk pengujian dengan 500–1.000 record.

Zoho CRM: Zoho memiliki lingkungan sandbox yang tersedia di Setup > Developer Space > Sandbox. Konfigurasi mencerminkan instance produksi Anda.

Ketika sandbox tidak tersedia:

Buat akun produksi baru dengan nama perusahaan uji dan email admin khusus
Gunakan tag import yang berlabel jelas ("UTEST IMPORT - HAPUS") pada semua record uji
Setelah pengujian, hapus semua record dengan tag tersebut sebelum cutover

Sandbox harus memiliki:

Semua field kustom yang dibuat dan dikonfigurasi (tipe yang sama, nilai picklist yang sama dengan produksi)
Tahap pipeline dan lifecycle stage yang ditentukan agar sesuai dengan konfigurasi tujuan Anda
Akun pengguna yang disiapkan jika Anda menguji field penetapan pengguna
Webhook integrasi dinonaktifkan — Anda tidak ingin import uji memicu notifikasi nyata

Langkah 2: Siapkan Dataset Uji yang Representatif

Dataset uji adalah tempat sebagian besar shadow import gagal. Tim menggunakan 50 record bersih dan berformat baik dan menyimpulkan bahwa migrasi berhasil. Kemudian dataset lengkap mencakup 40 record dengan karakter beraksent, 200 dengan field relasi null, dan 15 dengan catatan yang berisi tag HTML — dan import penuh rusak dengan cara yang tidak diprediksi oleh uji tersebut.

Ukuran target: 500–1.000 record. Cukup besar untuk mengekspos kasus tepi tetapi cukup kecil untuk di-QA secara manual.

Kriteria Pemilihan Dataset Uji

Bangun dataset Anda dengan sengaja menyertakan record bermasalah, bukan hanya yang bersih:

Kategori	Jumlah record	Yang perlu diuji
Record bersih, terisi penuh	150	Dasar — semua field ada, pemformatan standar
Nomor telepon yang hilang	60	Penanganan null di field telepon
Email yang hilang	40	Bagaimana null di field wajib ditangani
Karakter tidak biasa di field nama	50	O'Brien, Müller, José, Li Wei, nama ganda
Panjang field maksimum	30	Nama perusahaan 255 karakter, catatan panjang, URL panjang maksimum
Kandidat duplikat (2 kontak, email sama)	20	Bagaimana alat import menangani duplikat
Kontak tanpa asosiasi perusahaan	30	Kontak standalone tanpa tautan Account/Company
Kontak yang terkait dengan beberapa deal	30	Record relasi multi-asosiasi
Record dengan HTML di field catatan atau deskripsi	20	Rendering field catatan di tujuan
Record dengan tanggal tertua dalam dataset	20	Kasus tepi pemformatan field tanggal
Record dari setiap nilai lifecycle stage	1 per nilai	Cakupan pemetaan picklist
Record dari setiap nilai sumber lead	1 per nilai	Cakupan pemetaan picklist
Total	~500

Export set ini secara spesifik — jangan ambil 500 baris pertama saja. 500 baris pertama biasanya adalah record yang paling baru dibuat, yang biasanya lebih bersih dari record yang lebih lama. Anda menginginkan kekacauan dalam dataset uji Anda.

Langkah 3: Jalankan Import dengan Tooling yang Tepat

Ini sangat penting: gunakan alat import yang sama, file field mapping yang sama, dan aturan transformasi yang sama yang akan Anda gunakan pada hari cutover. Jika Anda menggunakan metode berbeda untuk uji import, Anda menguji proses yang berbeda.

Alat import umum berdasarkan kombinasi sumber/tujuan:

HubSpot → CRM lain: Export CSV native + import CSV CRM tujuan, atau alat migrasi seperti wizard import native HubSpot untuk objek datar. Dokumentasi import HubSpot merinci format header kolom yang diperlukan untuk setiap objek — CSV uji Anda harus mengikuti ini dengan tepat atau import akan melewatkan baris secara diam-diam.
Salesforce → CRM lain: Salesforce Data Loader (gratis, alat Salesforce sendiri) untuk export CSV, atau alat migrasi yang dibuat khusus. Mode batch Data Loader sangat penting untuk proses uji — ini menghasilkan log sukses/error per baris yang membuat QA jauh lebih cepat.
Pipedrive → CRM lain: Export CSV native + wizard import tujuan
Apa saja → Apa saja: Alat migrasi pihak ketiga seperti Trujay, Migrate.io, atau Import2 menangani resolusi relasi secara otomatis

Sebelum Anda menjalankan: Muat dokumen field mapping dan aturan transformasi Anda. Anda harus mengikuti dokumen, bukan berimprovisasi. Jika Anda membuat keputusan secara spontan selama uji import, dokumen belum selesai — kembali dan selesaikan sebelum proses sebenarnya. Jika Anda beralih dari HubSpot, beralih dari HubSpot ke Rework mencakup keanehan urutan import khusus untuk sistem sumber tersebut.

Urutan import (ini penting):

Perusahaan / Akun terlebih dahulu
Kontak kedua (agar asosiasi perusahaan dapat terselesaikan)
Deal / Opportunity ketiga (asosiasi kontak harus ada)
Aktivitas terakhir (asosiasi deal dan kontak harus ada)

Jalankan import dalam urutan ini bahkan untuk uji. Menyimpang dari urutan adalah salah satu penyebab paling umum dari field relasi yang rusak.

Pantau log import secara real time. Jangan pergi dan kembali nanti. Log akan menampilkan error validasi field, kegagalan konversi tipe, dan record yang dilewatkan. Catat setiap error dengan ID record dan pesan error — Anda akan membutuhkan daftar ini untuk langkah QA.

Langkah 4: Checklist QA Pasca-Import

Setelah import selesai, jangan asumsikan berhasil karena selesai tanpa error. Kerjakan checklist ini secara sistematis.

Checklist QA Pasca-Import

Verifikasi jumlah record:

Total kontak yang diimpor sesuai dengan jumlah yang diharapkan (dasar minus semua skip yang disengaja)
Total perusahaan yang diimpor sesuai dengan jumlah yang diharapkan
Total deal yang diimpor sesuai dengan jumlah yang diharapkan
Jumlah error import sesuai dengan log error (tidak ada skip diam-diam)

Ketepatan tipe field:

Field tanggal ditampilkan sebagai tanggal (bukan string teks, bukan Unix timestamp)
Field angka (Annual Revenue, jumlah deal) ditampilkan sebagai angka, bukan teks
Field mata uang diformat dengan benar di tujuan
Field telepon ditampilkan dalam format yang konsisten
Field checkbox adalah True/False (bukan "1"/"0" atau "Yes"/"No" kecuali itu targetnya)

Pemetaan nilai picklist:

Semua nilai lifecycle stage dipetakan ke nilai tujuan yang valid (tidak ada lifecycle stage kosong)
Nilai sumber lead dipetakan dengan benar
Nilai tahap deal dipetakan dengan benar
Semua field picklist kustom dipetakan dengan benar

Integritas relasi:

Buka 20 record kontak dan verifikasi asosiasi perusahaan sudah benar
Buka 10 record deal dan verifikasi asosiasi kontak sudah benar
Verifikasi bahwa setidaknya 3 record deal memiliki pemilik deal yang ditetapkan dengan benar
Untuk record multi-asosiasi (kontak yang terhubung ke beberapa deal), verifikasi semua asosiasi ada

Hasil field formula dan yang dihitung:

Jika CRM tujuan menghitung field (hari sejak aktivitas terakhir, usia deal, dll.), spot-check 5 record untuk nilai yang masuk akal

Pemeriksaan pemicu otomasi:

Verifikasi bahwa record uji import tidak memicu workflow/sequence langsung (penting jika Anda menjalankan di lingkungan yang berdekatan dengan produksi)

Catat setiap kegagalan. Pemeriksaan QA yang "sebagian besar berhasil" bukan lulus — setiap kegagalan adalah cacat dalam dokumen field mapping Anda yang akan memengaruhi import penuh.

Langkah 5: Uji Tiga Laporan yang Paling Sering Digunakan

Verifikasi tingkat field menangkap error record individual. Verifikasi laporan menangkap masalah pemetaan sistemik yang hanya muncul ketika data diagregasi.

Identifikasi tiga laporan yang paling sering digunakan:

Biasanya: ikhtisar pipeline per tahap, kontak per lifecycle stage, dan deal yang dibuat bulan ini
Tanya tim penjualan Anda laporan mana yang mereka buka setiap hari — itulah yang perlu diverifikasi. Artikel tinjauan pipeline mingguan menjelaskan format laporan pipeline mana yang paling diandalkan tim penjualan.

Untuk setiap laporan:

Jalankan laporan yang sama terhadap sistem sumber pada sampel uji 500 record Anda
Jalankan laporan yang sama (difilter ke record yang diimpor) di tujuan
Bandingkan angka-angkanya

Jumlah harus cocok. Jika sistem sumber Anda menampilkan 85 kontak SQL dalam sampel uji dan tujuan menampilkan 79, Anda memiliki error pemetaan lifecycle stage yang memengaruhi 6 record. Temukan sebelum import penuh.

Ketidakcocokan laporan yang umum dan penyebabnya:

Perbedaan jumlah di lifecycle stage: Nilai picklist yang tidak dipetakan dengan benar
Total pendapatan berbeda: Field mata uang diimpor sebagai teks (tidak dijumlahkan dengan benar)
Filter berbasis tanggal mengembalikan record yang salah: Format tanggal diimpor salah; record dikaitkan ke periode yang salah
Laporan pemilik kosong: Penetapan pengguna tidak terselesaikan

Langkah 6: Minta Rep Penjualan Menguji Lima Record dari Awal hingga Akhir

QA teknis menemukan error teknis. Rep penjualan menemukan error kegunaan — field yang terlihat benar dalam log import tetapi terasa salah saat Anda mencoba mengerjakan deal.

Pilih rep yang mengenal data sumber dengan baik. Berikan mereka ID record dari lima kontak dan minta mereka untuk:

Menemukan record di sistem baru
Memverifikasi informasi terlihat benar — perusahaan, jabatan, telepon, email, lifecycle stage
Memeriksa riwayat aktivitas untuk kontak tersebut
Membuka deal yang terkait dan memverifikasi informasi deal
Melaporkan apapun yang terlihat salah atau hilang

Jangan beri mereka checklist QA. Reaksi mereka yang tidak dipandu terhadap kualitas data lebih berharga daripada pemeriksaan terstruktur. Feedback yang Anda inginkan adalah "ini terlihat benar" atau "di mana tahap deal yang saya gunakan?" — itulah sinyal yang memberitahu Anda apakah migrasi akan menyebabkan masalah bagi tim pada hari pertama.

Langkah 7: Dokumentasikan Setiap Error dan Perbaiki Sebelum Cutover

Setelah QA, Anda akan memiliki daftar error. Setiap error memiliki salah satu dari dua penyebab:

Kesalahan dalam dokumen field mapping
Kasus tepi dalam data yang tidak diperhitungkan dalam dokumen pemetaan

Keduanya perlu diperbaiki dalam dokumen pemetaan sebelum cutover. Jangan perbaiki error dengan mengedit record secara manual di tujuan — itu menambal 3 record dan membiarkan akar penyebab di file pemetaan Anda, di mana itu akan menyebabkan error yang sama untuk 47.000 record berikutnya.

Untuk setiap error:

Identifikasi akar penyebab: aturan transformasi yang salah, penanganan tipe yang salah, pemetaan picklist yang salah
Perbarui dokumen pemetaan
Jalankan kembali record uji yang terpengaruh melalui proses yang sudah diperbaiki
Verifikasi output sudah benar

Jika memperbaiki error mengharuskan menjalankan kembali uji import penuh, lakukan. Ya, membutuhkan waktu 2–3 jam lagi. Tetapi menemukan pada hari cutover bahwa perbaikan Anda memperkenalkan error sekunder jauh lebih buruk.

Simpan log semua error yang ditemukan dan cara perbaikannya. Log ini menjadi bagian dari dokumentasi migrasi Anda dan berguna jika masalah pasca-cutover muncul yang tidak terdeteksi dalam pengujian.

Checklist Persetujuan Sebelum Menjadwalkan Cutover

Jangan jadwalkan cutover sampai setiap item dalam daftar ini selesai:

Verifikasi data:

Jumlah record dalam uji import sesuai dengan jumlah yang diharapkan dalam 0,5%
Nol error tipe field yang belum terselesaikan dalam log import
Tingkat null lifecycle stage < 1% dari record yang diimpor
Semua field relasi terselesaikan dengan benar (tidak ada kontak atau deal orphan)

Verifikasi laporan:

Semua tiga laporan kunci sesuai dengan jumlah sistem sumber dalam 2%
Total pendapatan/mata uang sesuai dengan sumber dalam 0,1%
Filter berbasis tanggal mengembalikan set record yang benar

Persetujuan stakeholder:

QA rep penjualan selesai — setidaknya satu rep telah menguji 5+ record dan mengkonfirmasi data terlihat benar
Kepemimpinan penjualan telah melihat laporan kunci dan mengkonfirmasi terlihat benar
IT/admin telah memverifikasi akses pengguna dan setup izin

Kesiapan proses:

Dokumen field mapping diselesaikan (semua error dari uji import diperbaiki)
Urutan import didokumentasikan
Rencana rollback didokumentasikan
Komunikasi cutover sudah dibuat

Jangan jadwalkan cutover sampai setiap checkbox dicentang. Daftar persetujuan bukan birokrasi — ini adalah titik pemeriksaan yang memisahkan "kami pikir ini akan berhasil" dari "kami telah memverifikasi ini berhasil."

Kesalahan Umum

Menguji dengan terlalu sedikit record untuk mengekspos kasus tepi. Uji 50 record dengan semua data bersih akan lulus QA dan masih gagal pada import penuh ketika mencapai 200 record dengan HTML di field catatan. Gunakan 500+ record dengan kasus tepi yang disengaja.

Tidak menguji relasi — hanya field kontak yang datar. QA field kontak adalah bagian yang mudah. QA relasi adalah tempat migrasi rusak. Setiap asosiasi deal-ke-kontak, setiap tautan kontak-ke-perusahaan perlu diuji secara eksplisit, tidak disimpulkan dari pemeriksaan tingkat field.

Melewatkan langkah QA rep penjualan. Pengguna teknis memeriksa apakah field sudah benar. Rep memeriksa apakah data dapat digunakan. Itu standar yang berbeda. Nomor telepon yang secara teknis valid tetapi dalam format yang tidak dapat digunakan (tanpa kode area, kode negara yang salah) lulus QA teknis dan gagal dalam uji rep.

Memperbaiki error di tujuan alih-alih dalam dokumen pemetaan. Ini adalah kesalahan paling umum. Anda menemukan 5 record di mana lifecycle stage kosong, mengaturnya secara manual ke "SQL" di tujuan, dan melanjutkan. Pada hari cutover, 500 record diimpor dengan lifecycle stage kosong. Perbaiki akar penyebab dalam dokumen pemetaan.

Menjadwalkan cutover sebelum shadow import selesai. Tekanan dari kepemimpinan untuk mencapai tanggal go-live tertentu memang nyata. Tetapi menjadwalkan cutover sebelum kriteria persetujuan terpenuhi adalah bagaimana migrasi gagal secara publik, dengan kepemimpinan penjualan menyaksikannya. Penundaan satu minggu dalam shadow import mengalahkan rollback cutover.

Langkah Selanjutnya

Jadwalkan shadow import setidaknya 5 hari kerja sebelum cutover yang direncanakan. Buffer itu memberi Anda waktu untuk memperbaiki error, menjalankan kembali uji import jika diperlukan, dan mendapatkan persetujuan stakeholder tanpa tergesa-gesa. Dan setelah Anda mendapatkan persetujuan, rollout dan adopsi CRM memiliki langkah pelatihan rep dan manajemen perubahan yang mengubah migrasi data yang bersih menjadi sistem yang benar-benar digunakan tim.

Shadow import harus menjadi aktivitas terakhir sebelum penjadwalan cutover — bukan salah satu dari beberapa tugas paralel yang terjadi secara bersamaan. Berikan perhatian yang dibutuhkannya.

Setelah checklist persetujuan selesai, Anda siap untuk menjadwalkan cutover dan menyiapkan panduan hari-H. Proses tersebut dibahas dalam panduan cutover day.

Data Migration Guide