Resources
The Salesforce fields that never migrate cleanly, and what to do about them
February 4, 2025
When a team plans a Salesforce to HubSpot migration, the worry is almost always the data. Will the contacts come across, will the history survive. Those parts are the easy parts. The data moves. What does not move is the logic that sat around the data, and that is where a migration quietly goes wrong.
Formula fields
Salesforce formula fields calculate a value on the fly. HubSpot does not read a Salesforce formula, so these arrive as empty or as a frozen snapshot. The fix is to rebuild them as HubSpot calculated properties where the math allows, or as workflow-maintained fields where it does not. The point is that they keep updating after the move, rather than sitting stale.
Roll-up summary fields
A roll-up summary counts or sums child records up to a parent, for example total open opportunities on an account. HubSpot handles this differently, so these do not carry as live values. We rebuild the important ones with a mix of calculated properties and workflows, and we quietly drop the ones nobody was reading.
Record types
Record types are one of the most misread parts of a migration. A record type in Salesforce often maps to a combination of a HubSpot pipeline, a property value, and sometimes a separate object. There is no single correct mapping. It is a design decision, and getting it wrong here shows up months later as reporting that will not segment the way you expect.
Validation rules and Apex
Validation rules and Apex triggers enforce logic on save. HubSpot enforces data quality differently. Each rule is reviewed, and the ones that still matter are rebuilt as required properties, workflow logic, or form validation. Many turn out to be legacy guards for a process that no longer exists.
The rule that saves you
Inventory the logic before you touch the data. Most failed migrations are not failed data loads. They are successful data loads into a system where the logic was assumed to come along for the ride, and it did not. Map the logic first, decide what to rebuild and what to retire, and the data becomes the simple part it always was.
This is the work we scope in a migration audit before anything moves. See how a Salesforce migration runs.