Map Custom CRM Fields Without Losing Data

Start With a Complete Field Inventory

The foundation of any successful CRM field mapping exercise is a complete inventory of every field in your source system. Export your field list from the source CRM's admin interface (in Salesforce, this is Object Manager; in HubSpot, it's Settings → Properties) and for each field record: internal field name, display label, data type (text, number, dropdown, date, boolean), allowable values (for dropdown/picklist fields), current population rate (what % of records have a non-null value), and whether it's used in any automation rules or reports. Fields with high population rates and automation usage are your critical fields, any migration error here has cascading effects on your workflows and reporting.

Data Type Mismatches: The Hidden Migration Killer

The most common source of data corruption in CRM migrations is data type mismatch between source and target systems. Common scenarios: a text field in Salesforce that stores dates in "MM/DD/YYYY" format being mapped to a date property in HubSpot (which requires ISO 8601 format); a number field storing revenue as "€1,200" (string with currency symbol) being mapped to a currency number property; a multi-select checkbox in the source storing comma-separated values being mapped to a single-value dropdown. For each high-priority field, validate not just the field type but the actual data format stored in the 10 most recently modified records.

Building the Mapping Document

Your mapping document should have one row per source field and include: Source Object, Source Field Name, Source Data Type, Target Object, Target Field Name, Target Data Type, Transformation Required (yes/no), Transformation Logic (if yes), and Validation Criteria. The transformation column is where you document any data cleaning required, for example, "strip currency symbol and convert to float" or "split comma-separated values into separate records." Build this document collaboratively with your sales and marketing ops teams who understand the business logic behind custom fields, not just their technical definitions.

Testing Migration With Subsets Before Full Import

Never migrate all records in a single batch without subset testing. Create three test groups: 50 recently active contacts, 50 contacts with the most complex custom field values, and 50 contacts that have been through your most complex automation sequences. Migrate these 150 records first, validate every field value against the source system, run your key reports on the subset to verify data integrity, and only then proceed to the full migration. This subset approach typically catches 80% of data quality issues with 1% of the migration effort.

Preserving Historical Data That Won't Migrate Directly

Some historical data simply can't be migrated directly due to platform differences, Marketo engagement scores, Pardot Prospect Grades, or Salesforce custom rollup fields. For this data, two options: (1) store it as a frozen historical reference in a custom text property named appropriately (e.g., "Legacy Marketo Score as of [migration date]") so it's accessible for reporting even if no longer updated; (2) export it to a data warehouse (BigQuery, Snowflake) for long-term archival. Either approach is preferable to simply deleting historical data that may be needed for future analysis. Contact Excel to discuss your specific field mapping requirements.