RevOps Strategy
July 29, 2026 · 6 min read · by Ananda Narasimhan
Every HubSpot-to-Salesforce migration we've inherited from another vendor looked clean in the sales deck and broke in the same three places three months later: object model mismatches, workflows that never got rebuilt, and reporting that quietly stopped meaning what it used to mean.
This is the checklist we run before touching a live HubSpot instance that's moving to Salesforce, whether the trigger is a Series B raise, a new sales leadership team, or simply outgrowing what HubSpot's CRM object model can do.
HubSpot treats contacts as the center of gravity, with companies and deals hanging off them. Salesforce splits leads and contacts into separate objects with separate lifecycles, and a lead only becomes a contact through conversion. If you migrate contacts straight into Salesforce contacts without deciding which records should have been leads, you end up with thousands of contacts on no account, no owner, and no path through a normal sales process.
Every custom property in HubSpot needs a matching field in Salesforce, and matching means the same data type, the same picklist values, and the same field-level security, not just the same name. We've seen a HubSpot dropdown with eight values map to a Salesforce picklist with five, silently truncating the other three into a blank field. Build the field mapping spreadsheet before you touch the migration tool, not while it's running.
HubSpot workflows do not translate into Salesforce Flow. There is no export button. Every enrollment trigger, every branch, every re-enrollment rule has to be read, understood, and rebuilt natively in Salesforce, which usually means Flow Builder plus whatever your MAP still owns if HubSpot stays on as the marketing layer. Budget real time for this. It is usually the single most underestimated line item in a migration plan.
HubSpot's attribution reporting is built on its own event model: page views, form submissions, email interactions tied to a contact timeline. Salesforce has no native equivalent unless you're running a tool like Bizible or building custom objects to hold it. Decide before cutover whether historical attribution needs to survive the move, because reconstructing it after the fact from a CSV export is close to impossible.
HubSpot's lifecycle stage and Salesforce's lead status and opportunity stage are three different fields tracking three overlapping concepts. Map them explicitly, field by field, stage by stage, and decide which system is the system of record for each one going forward. Without this, marketing and sales will report different funnel numbers for the same underlying pipeline within the first reporting cycle.
We run a batch of test records through every branch before flipping DNS on the new system of record: a lead with a duplicate email already in Salesforce, a contact tied to a closed-won deal, a company with multiple contacts at different lifecycle stages, a record missing a required custom field. We confirm deduplication logic, confirm owner and territory assignment map correctly, and confirm every dashboard sales leadership actually looks at still returns the same numbers it did in HubSpot, not just numbers that look plausible.
Field mapping and object model decisions come first, on paper, before opening Salesforce setup. Rebuild workflows in a sandbox, not production, and test them against real historical data before go-live. Run both systems in parallel for at least one full sales cycle if the deal cycle is longer than a month, so reps and reports have a comparison point before the old system disappears. And keep HubSpot's data exportable and archived for at least a year after cutover, because the question "what did this field say six months ago" always comes up eventually.
None of this is exotic. It is the difference between a migration that holds up under a board deck and one where sales and marketing spend the next two quarters arguing about whose numbers are right.