Memetakan Field Antara Sistem Lama dan Baru

Field mapping adalah bagian migrasi CRM yang terlihat mudah sampai tiba-tiba tidak. "First Name dipetakan ke First Name" — tentu saja. Tetapi apa yang terjadi ketika sistem sumber Anda memiliki satu field Full Name dan tujuan memerlukan First Name dan Last Name secara terpisah? Atau ketika Lead Status di Salesforce memiliki 8 nilai dan tujuan hanya mendukung 5? Atau ketika Annual Revenue diimpor sebagai field teks alih-alih field mata uang, merusak setiap laporan pendapatan pada hari pertama?

Skenario terakhir itu bukan hipotetis. Ini terjadi sepanjang waktu. Dan dapat dicegah — jika Anda membangun dokumen field mapping sebelum proses import pertama, bukan selama proses tersebut.

Panduan ini memandu Anda melalui proses field mapping lengkap: pemetaan tingkat objek terlebih dahulu, kemudian field standar, kemudian kasus-kasus sulit (field kustom, nilai picklist, field relasi, ketidakcocokan tipe). Kerjakan langkah-langkah ini secara berurutan sebelum Anda menyentuh CRM tujuan.

Langkah 1: Pemetaan Tingkat Objek Terlebih Dahulu

Sebelum Anda memetakan satu field pun, petakan objek-objeknya. Setiap CRM menggunakan terminologi yang sedikit berbeda untuk konsep yang sama, dan pemetaan objek yang salah merusak data relasi dalam skala besar.

Pemetaan Objek Standar

Sistem sumber	Objek sumber	Konsep tujuan	Catatan
Salesforce	Lead	Contact (pra-konversi)	Salesforce Lead dikonversi menjadi Contact + Account + Opportunity
Salesforce	Contact	Contact	Peta langsung
Salesforce	Account	Company
Salesforce	Opportunity	Deal
Salesforce	Activity (Task/Event)	Activity
HubSpot	Contact	Contact	Peta langsung
HubSpot	Company	Company	Peta langsung
HubSpot	Deal	Deal	Peta langsung
HubSpot	Ticket	Ticket / Support Case	Bergantung pada tujuan
Pipedrive	Person	Contact
Pipedrive	Organization	Company
Pipedrive	Deal	Deal	Peta langsung
Pipedrive	Activity	Activity
Zoho CRM	Lead	Contact (pra-konversi)	Mirip dengan model Salesforce Lead
Zoho CRM	Contact	Contact
Zoho CRM	Account	Company

Masalah konversi Salesforce Lead: Salesforce memiliki Lead dan Contact. Lead adalah pra-konversi; Contact adalah pasca-konversi. Kebanyakan CRM lain hanya memiliki Contact (dengan lifecycle stage). Sebelum Anda memetakan apapun, putuskan: apakah Anda memigrasikan Salesforce Lead sebagai Contact dengan lifecycle stage "Lead", atau apakah Anda hanya memigrasikan Contact yang sudah dikonversi? Keputusan ini memengaruhi ribuan record. Beralih dari Salesforce ke Rework menjelaskan bagaimana konversi Lead-ke-Contact ini berlaku khusus dalam model data Rework.

Ketika model objek tidak cocok: Jika sumber Anda memiliki objek kustom tanpa padanan di tujuan, dokumentasikan secara eksplisit. Jangan paksa-masukkan data objek kustom ke dalam objek standar — ini menciptakan kebingungan. Migrasikan sebagai objek kustom di tujuan, atau putuskan bahwa tidak layak dimigrasikan sama sekali.

Langkah 2: Pemetaan Field Standar

Field standar tampak mudah. Seringkali tidak.

First Name / Last Name vs. Full Name: Salesforce menyimpan nama depan dan belakang secara terpisah. Beberapa sistem menyimpan satu field "Full Name". Jika bermigrasi ke sistem yang memerlukan nama depan/belakang terpisah dari sumber yang hanya memiliki Full Name, Anda memerlukan transformasi split — dan ini tidak sempurna (apa yang Anda lakukan dengan "Dr. María José García-López"?).

Multiplisitas field telepon: Salesforce Contact memiliki Phone, MobilePhone, OtherPhone, HomePhone, AssistantPhone — lima field telepon terpisah. Kebanyakan CRM memiliki satu telepon utama dan satu sekunder. Putuskan sebelum import field sumber mana yang dipetakan ke field tujuan mana. Jangan buang nomor telepon tanpa mendokumentasikan keputusan tersebut.

Multiplisitas email: Masalah yang sama. Salesforce memiliki Email dan email sekunder melalui metode Contact. HubSpot mendukung beberapa email per kontak. Jika tujuan hanya mendukung satu email utama, Anda memerlukan aturan untuk menentukan mana yang menang.

Field website: Format URL yang tidak konsisten menyebabkan error validasi. Beberapa record memiliki "example.com", beberapa memiliki "https://www.example.com", beberapa memiliki "www.example.com/products/page". Tentukan format target dan tambahkan sebagai aturan transformasi.

Langkah 3: Inventaris Field Kustom

Di sinilah sebagian besar migrasi terhambat. Setiap CRM yang matang memiliki puluhan field kustom yang terakumulasi selama bertahun-tahun proses yang berubah. Sebagian besar tidak layak dimigrasikan.

Export semua field kustom dari sumber Anda:

Salesforce: Setup > Object Manager > Pilih objek > Fields & Relationships. Export sebagai daftar.
HubSpot: Pengaturan > Properties. Filter berdasarkan "Dibuat oleh" = tim Anda untuk melihat properti kustom.
Pipedrive: Pengaturan > Data Fields. Field kustom terdaftar per objek.
Zoho CRM: Setup > Customization > Fields.

Untuk setiap field kustom, terapkan tes tiga pertanyaan. Panduan field kustom membahas lebih dalam tentang konvensi penamaan, pilihan tipe field, dan proses tata kelola untuk pembuatan field kustom di tujuan:

Apakah Anda melaporkannya? Jika tidak ada laporan yang menggunakan field ini, kemungkinan tidak memberikan nilai bisnis.
Apakah Anda mensegmentasikannya? Jika tidak ada workflow, sequence, atau filter daftar yang mereferensikan field ini, mungkin tidak aktif.
Apakah Anda mengotomasi darinya? Jika tidak ada pemicu otomasi yang menggunakan field ini, pertimbangkan apakah perlu dimigrasikan.

Jika jawaban untuk ketiganya adalah tidak, arsipkan di sistem sumber. Jangan buat field tersebut di tujuan.

Dokumentasikan keputusan simpan/lewati untuk setiap field kustom. Ketika rep bertanya di minggu ketiga mengapa field "Partner Type" mereka hilang, Anda ingin catatan tertulis mengapa keputusan tersebut dibuat — bukan hanya mengangkat bahu.

Template Inventaris Field Kustom

Nama field	Objek	Tipe	Laporan yang menggunakannya	Penggunaan segmentasi	Penggunaan otomasi	Keputusan	Catatan
Partner Type	Contact	Picklist	Ya (1 laporan)	Ya (1 daftar)	Tidak	Migrasikan	Digunakan dalam pelaporan mitra
Legacy Territory	Account	Text	Tidak	Tidak	Tidak	Arsipkan	Digantikan oleh model wilayah baru
MQL Score (manual)	Contact	Number	Tidak	Tidak	Tidak	Lewati	Digantikan oleh scoring otomatis
Referral Source Detail	Contact	Text	Ya (2 laporan)	Tidak	Tidak	Migrasikan

Langkah 4: Transformasi Nilai Picklist

Field picklist adalah tipe field berisiko tertinggi dalam migrasi apa pun. Terlihat sederhana tetapi menyembunyikan kompleksitas — nilai sumber seringkali tidak cocok dengan nilai tujuan, dan nilai yang tidak cocok diimpor sebagai kosong atau menimbulkan error.

Prosesnya:

Export semua nilai yang berbeda untuk setiap field picklist dari sumber
Export semua nilai yang diizinkan untuk field yang cocok di tujuan
Bangun pemetaan nilai-ke-nilai yang eksplisit
Putuskan apa yang harus dilakukan dengan nilai sumber yang tidak memiliki padanan di tujuan

Template Pemetaan Picklist

Contoh: Lead Status / Lifecycle Stage

Nilai sumber	Jumlah	Nilai tujuan	Penanganan
New	1.450	Lead	Peta langsung
Working	680	Lead	Petakan ke Lead
Nurturing	320	Lead	Petakan ke Lead
Marketing Qualified	290	MQL	Peta langsung
Sales Accepted	175	SQL	Peta langsung
Sales Qualified	210	SQL	Gabung dengan atas
Demo Scheduled	88	SQL	Petakan ke SQL + tambahkan catatan aktivitas
Proposal Sent	62	SQL	Petakan ke SQL
Customer	2.400	Customer	Peta langsung
At Risk	155	Customer	Petakan ke Customer, tambahkan tag "at-risk"
Churned	310	Customer	Petakan ke Customer (inactive)
Dead	890	Disqualified	Petakan ke Disqualified
Not Interested	430	Disqualified	Petakan ke Disqualified

Apa yang harus dilakukan dengan nilai yang tidak memiliki padanan di tujuan: Jangan biarkan kosong. Petakan ke nilai tujuan yang paling dekat (dengan catatan di dokumen transformasi) atau buat field kustom di tujuan untuk mempertahankan perbedaan tersebut. Nilai kosong di lifecycle stage berarti record tersebut tidak akan diambil oleh otomasi yang memfilter berdasarkan lifecycle stage.

Langkah 5: Pemetaan Field Relasi

Relasi adalah bagian field mapping yang paling sering rusak dan paling sulit diperbaiki setelah kejadian.

Asosiasi Account → Contact (Salesforce): Setiap Contact di Salesforce terhubung ke Account melalui lookup AccountId. Di kebanyakan CRM tujuan, ini menjadi asosiasi Contact → Company. Alat import perlu menyelesaikan relasi tersebut — biasanya dengan mencocokkan nama Company dari record Contact ke record Company yang ada.

Urutan operasi penting: Import Perusahaan terlebih dahulu, kemudian Kontak. Jika Anda mengimpor Kontak sebelum Perusahaan ada di tujuan, relasi tidak dapat dibuat.

Asosiasi Deal → Contact: Deal di Salesforce (Opportunity) memiliki Kontak Utama dan mungkin memiliki kontak tambahan melalui Opportunity Contact Role. Periksa apakah CRM tujuan Anda mendukung beberapa asosiasi kontak per deal, dan putuskan kontak mana yang akan dimigrasikan.

Record multi-relasi: Beberapa kontak berasosiasi dengan beberapa perusahaan (konsultan, anggota dewan). Kebanyakan CRM menangani ini berbeda dari Salesforce. Dokumentasikan bagaimana ini akan diimpor dan uji beberapa record khusus ini di shadow import Anda.

Hierarki akun parent-child: Salesforce Account dapat memiliki Account induk (untuk relasi anak perusahaan). Tidak semua CRM tujuan mendukung ini secara native. Ketahui sebelum Anda memetakan apakah hierarki parent-child akan bertahan melewati migrasi.

Langkah 6: Ketidakcocokan Tipe Field

Ketidakcocokan tipe field adalah masalah pemetaan paling berbahaya karena sering diimpor tanpa error — tipe yang salah hanya secara diam-diam merusak data.

Tabel Referensi Konversi Tipe

Tipe sumber	Tipe tujuan	Aman?	Transformasi yang diperlukan
Text	Text	Ya	Tidak ada
Text	Picklist	Berisiko	Nilai harus cocok dengan picklist; nilai yang tidak dipetakan gagal
Picklist	Text	Ya	Nilai diimpor apa adanya
Number	Text	Ya	Tidak ada
Text	Number	Berisiko	Karakter non-numerik menyebabkan error import
Currency	Number	Berisiko	Hapus simbol mata uang dan pemisah koma
Number	Currency	Ya	Tidak ada
Date	DateTime	Ya	Tambahkan T00:00:00Z
DateTime	Date	Ya	Hapus komponen waktu
Text (format-tanggal)	Date	Berisiko	Harus dikonversi ke ISO 8601 terlebih dahulu
Checkbox (Boolean)	Text	Ya	True/False sebagai string
Text	Checkbox	Berisiko	Harus distandarisasi ke True/False dengan tepat
Lookup (ID)	Association	Berisiko	Memerlukan logika resolusi — kebanyakan alat import tidak menangani ini secara otomatis

Masalah Annual Revenue: Ini sering muncul. Salesforce menyimpan Annual Revenue sebagai field mata uang. Beberapa CRM tujuan menyimpannya sebagai Number biasa. Jika Anda mengimpor string mata uang yang diformat seperti "$1.250.000,00" ke field Number, import akan error. Hapus tanda dolar dan koma sebelum import: transformasikan $1.250.000,00 menjadi 1250000. Untuk tampilan yang lebih luas tentang bagaimana model data CRM berbeda di berbagai platform — termasuk penanganan tipe field — Rework vs. HubSpot CRM adalah referensi yang berguna.

Field Checkbox: Sistem yang berbeda merepresentasikan nilai boolean dengan cara yang berbeda. Salesforce mengekspor True/False. Beberapa CRM mengimpor 1/0. Beberapa memerlukan "Yes"/"No". Ketahui apa yang diharapkan alat import Anda dan transformasikan sesuai.

Langkah 7: Dokumen Aturan Transformasi

Untuk setiap field yang bukan peta langsung, tuliskan aturan transformasinya secara eksplisit. Dokumen ini menjadi panduan import Anda — orang yang menjalankan import mengikutinya tanpa perlu membuat keputusan secara spontan.

Notasi Transformasi

Gunakan format yang konsisten untuk semua aturan transformasi:

IF [source_field] = "[source_value]"
THEN [destination_field] = "[destination_value]"
ELSE [default_behavior]

Contoh:

IF lead_status = "Dead" OR "Not Interested"
THEN lifecycle_stage = "Disqualified"

IF annual_revenue = format teks "$N.NNN.NNN,NN"
THEN annual_revenue = REPLACE("$","") + REPLACE(",","") [hanya numerik]

IF phone = format apapun
THEN phone = format E.164 (+CC + nomor pelanggan, tanpa pemisah)

IF close_date = NULL
THEN close_date = [biarkan kosong, jangan default ke tanggal manapun]

IF contact.account_id IS NOT NULL
THEN [selesaikan AccountId → Company melalui pencocokan company_name di tujuan]
ELSE [buat kontak standalone tanpa asosiasi perusahaan]

Tulis aturan untuk setiap pemetaan non-trivial. Jika Anda tidak bisa menulis aturannya, Anda belum membuat keputusannya — dan itulah tepatnya masalah yang coba Anda hindari.

Langkah 8: Validasi Field Map dengan 100 Record Uji

Sebelum menjalankan import penuh, validasi setiap keputusan pemetaan terhadap sampel uji 100 record Anda.

Jalankan uji import menggunakan tooling yang tepat. Jangan uji dengan metode import yang berbeda dari yang akan Anda gunakan pada hari cutover. Tujuannya adalah untuk menemukan error dalam dokumen pemetaan Anda, bukan dalam alat import Anda.

Periksa setiap field yang dipetakan dalam output:

Apakah field teks memiliki nilai yang benar?
Apakah field picklist menampilkan nilai tujuan (bukan nilai sumber)?
Apakah field tanggal ditampilkan dalam format yang benar?
Apakah field mata uang/angka diimpor sebagai angka, bukan teks?
Apakah field relasi diselesaikan ke record perusahaan/deal yang benar?

Cari error diam-diam: Proses import yang selesai tanpa error tidak sama dengan proses import yang benar. Buka 10 record secara manual dan bandingkan field-demi-field terhadap sumber. QA otomatis melewatkan error konversi tipe diam-diam yang terlihat bersih dalam log import.

Jika Anda menemukan error dalam uji import, perbaiki dokumen pemetaan terlebih dahulu. Jangan perbaiki record secara manual di tujuan — itu menambal gejala dan membiarkan akar penyebab di file pemetaan Anda, di mana itu akan menyebabkan error yang sama untuk 10.000 record berikutnya.

Kesalahan Umum

Memetakan field kustom tanpa memutuskan apakah masih diperlukan. Langkah inventaris field kustom ada karena alasan tertentu. Memigrasikan field yang tidak digunakan siapapun menambahkan noise ke CRM tujuan dan membingungkan rep yang melihat field yang tidak mereka kenali.

Mengabaikan ketidakcocokan tipe field. "Mungkin tidak apa-apa" adalah bagaimana Annual Revenue menjadi field teks yang merusak dashboard pendapatan Anda pada hari pertama. Periksa setiap ketidakcocokan tipe secara eksplisit.

Tidak mendokumentasikan aturan transformasi dan kemudian melupakannya. Anda akan menghabiskan 90 menit mengerjakan pemetaan nilai lifecycle stage. Tiga minggu kemudian, ketika seseorang bertanya mengapa Lead menampilkan "Unknown" dalam laporan, Anda akan menginginkan dokumen tersebut.

Memperlakukan field lookup/asosiasi sama seperti field biasa. Field relasi memerlukan record yang terkait untuk sudah ada di tujuan. Jika Anda mengimpor Kontak sebelum Perusahaan, semua asosiasi Perusahaan gagal secara diam-diam. Urutan import adalah bagian dari keputusan field mapping.

Menguji hanya dengan record bersih. Sampel uji Anda harus menyertakan kasus tepi: record dengan nilai null, record dengan panjang field maksimum, record dengan karakter tidak biasa. Pemetaan yang berfungsi pada data bersih akan gagal pada data nyata jika Anda melewati kasus yang berantakan.

Langkah Selanjutnya

Export skema objek sumber minggu ini. Kebanyakan CRM memiliki cara untuk mengunduh daftar field dengan informasi tipe:

Salesforce: Schema Builder (visual) atau panggilan describe() melalui Salesforce Workbench
HubSpot: Pengaturan > Properties > Export
Pipedrive: Pengaturan > Data Fields
Zoho: Setup > Customization > Fields

Buat spreadsheet dengan setiap field sumber dan mulai mengisi kolom field tujuan. Pada tahap ini, bahkan draf kasar pertama pun berharga — Anda akan menemukan kasus sulit (ketidakcocokan picklist, konflik tipe, field tanpa padanan tujuan) dan dapat mulai membuat keputusan sebelum menjadi krisis pada hari cutover. Setelah field mapping selesai dan diuji, rollout dan adopsi CRM mencakup cara mempersiapkan tim untuk hari pertama — karena import yang bersih tidak menjamin adopsi yang lancar.

Data Migration Guide