Migration
Salesforce to HubSpot migration service
The hard part is not moving the rows. It is deciding what a Lead becomes when there is no lead table to load it into, which record types survive as properties, and what happens to every formula field, validation rule and dashboard that assumed the old shape.
The mechanics
What a record becomes on the way between the two systems
Both platforms are relational, which makes this crossing easier than most. The friction is that Salesforce carries several concepts HubSpot has no slot for — a separate lead table, record types, formula fields, sharing rules — and each of those has to be given a destination by a person before a single row moves.
The lead problem, first. Salesforce keeps Lead as its own object, distinct from Contact and Account, and conversion is a one-way event that spawns an account, a contact and usually an opportunity. HubSpot has no equivalent table to load a lead export into: the prospecting tools present a leads view, but the underlying record is a contact, and position in the funnel is carried by a lifecycle stage property. So every lead status has to be mapped to a lifecycle stage, and already-converted leads have to be excluded from the import or the same person arrives twice under two identities.
Record types have no counterpart. In Salesforce a record type changes the page layout and the available picklist values on the same object — a Renewal opportunity and a New Business opportunity can share an object and behave nothing alike. HubSpot applies one property set per object, so a record type usually resolves into a property, a separate pipeline, or conditional logic on a form. Which of the three is a business decision, and it is the one most often deferred until the import is already running.
Derived values stop being derived. Formula fields and roll-up summaries compute on read in Salesforce. HubSpot calculation properties cover arithmetic and some rollups from associated records, but they are narrower. Each derived field ends up in one of three places: recreated as a calculation property, recomputed by a workflow on change, or frozen as a static value at cutover. Validation rules are the same story — HubSpot has required properties and stage requirements, not arbitrary cross-object expressions evaluated on save, so a rule that guarded data quality either becomes a workflow check or it stops existing.
Matching is the quiet risk. HubSpot deduplicates contacts on email address and companies on domain. Salesforce enforces neither, so an export containing two contacts on one address, or a block of records with no address at all, is exactly where an import merges people you meant to keep apart. The defence is cheap: carry the Salesforce record ID — the 18-character, case-insensitive form, not the 15-character one — into a dedicated HubSpot property on every record. It makes reconciliation arithmetic instead of guesswork, and it is what any surviving integration will key on afterwards. Both sides publish the mechanics: extraction through Salesforce's Bulk API (opens in new window) and loading through HubSpot's CRM imports API (opens in new window).
| Salesforce object | How Salesforce models it | Where it lands in HubSpot | The decision it forces |
|---|---|---|---|
| Lead | Its own object, converted once into account, contact and opportunity | A contact carrying a lifecycle stage — there is no separate lead table | Which lead statuses map to which lifecycle stage, and how converted leads are kept out of the import |
| Account | A record with its own fields, hierarchy and sharing rules | A company, deduplicated on domain, associated to contacts and deals | What happens to parent-child account hierarchies, which have no direct equivalent |
| Contact | Belongs to an account; email is not required and not unique | The central record, deduplicated on email address | How contacts with duplicate or missing email addresses are resolved before load, not during it |
| Opportunity and products | Stages with probability, plus line items drawn from a price book | A deal in a pipeline, with line items from a product library | Whether the product library is built first so line items survive, or deals collapse to a single amount |
| Record types | Different layouts and picklist values on one object | No equivalent — one property set applies per object | Whether each record type becomes a property, a separate pipeline, or conditional form logic |
| Formula and roll-up fields | Values computed on read, including across related records | Calculation properties, workflow-maintained properties, or static values | Which derived fields must stay live and which can be frozen at their cutover value |
| Profiles, roles and sharing rules | Record-level visibility driven by hierarchy and sharing settings | Teams and permission sets, with a flatter visibility model | Which record-level restrictions genuinely have to be reproduced, and which were habit |
| Email opt-out state | An opt-out flag on the record, alongside campaign membership | Subscription types, plus the marketing versus non-marketing contact designation | Which imported contacts are marketable at all — a decision with billing consequences in HubSpot |
Consent is the one mapping you cannot get wrong. An opt-out recorded in the old org has to arrive as the correct suppression on the other side, because the first send from the new portal will otherwise reach people who already said no. Opt-out state is reconciled as its own step with its own count, against the baseline in the FTC's CAN-SPAM compliance guide (opens in new window), and nothing sends until those numbers agree.
Sequence
The order the work has to happen in
Schema map before any export
Objects, fields, record types, picklists and pipelines listed on one page with a destination named for each. Anything without a destination is decided now, not discovered mid-import.
Scaffold the portal first
Users, pipelines, deal stages, custom properties and every dropdown option created before the first row loads. Import into a property that does not exist yet and the value is dropped without an error.
Sample import and reconcile
A few hundred records first, counted in and counted out. Deduplication behaves differently on each side, so this is where merges nobody intended show up while they are still cheap to undo.
Rebuilding Flows as workflows, not converting them
There is no converter between the two automation engines, and each piece of logic is read and rebuilt by hand. Record-triggered Flows usually translate cleanly, because a HubSpot workflow enrols on a property change or an association event in much the same spirit. Scheduled Flows become date-based enrolment. Screen Flows have no equivalent and become a form, a sequence of tasks, or a small internal tool. Apex triggers and scheduled jobs have no counterpart at all: if the logic needs real retries, reconciles two systems that both claim to own a field, or has to read unstructured text and decide something, it belongs outside the CRM in an automation platform you also own — which is the territory of workflow automation proper.
Approval processes deserve their own note. Salesforce approvals lock a record and route it through named approvers; HubSpot has approvals in specific tools rather than as a general record mechanism. The honest rebuild is usually a workflow that assigns a task, sets a status property, and blocks the pipeline stage until it is set — different in shape, same in effect, and worth agreeing before anyone expects a like-for-like copy.
Pipeline parity, products and what a stage means
Stages are copied by meaning, not by name. A Salesforce stage carries a probability and can require fields before an opportunity advances; HubSpot deal stages carry their own probability and can require properties at each stage, so most of this survives if it is set up deliberately. Multiple sales processes map to multiple pipelines. Line items only survive if the product library exists first, and a closed-lost reason that lived in a required field needs a property to land in — or the win-loss reporting you rely on disappears the day you switch.
Cutover, reconciliation, and everything still pointed at Salesforce
Cutover runs per pipeline, not big-bang. Record counts are compared in both directions, opt-out counts are compared separately, and a delta load catches everything created during the freeze window. At the same time the outside world has to be repointed: web-to-lead forms, mailbox and calendar connectors, the website tracking code, quoting and billing integrations, and any middleware still writing records. Miss one and the migration is never actually finished — new records keep appearing in the org you stopped watching. The old org stays live and read-only for a lookback period, which is the cheapest insurance in the project.
Where this sits next to the rest of the work
This page is about the crossing itself. Once you have landed and the question becomes how the portal should be built — lifecycle stages, lead routing, sequences, reporting that people actually open — our HubSpot automation consulting page covers that build at tool level, sales and marketing automation covers the same ground as an outcome rather than a platform, and how engagements work explains how a scope gets agreed before any of it starts.
If you are reading this from the other direction — already on HubSpot and weighing a move to an agency-style platform instead — that is a different crossing with a different mapping problem, and our HubSpot to GoHighLevel migration page covers it on its own terms — and if it is your own Salesforce org making that move, the same flattening problem arrives with leads, Apex and custom objects attached, which our Salesforce to GoHighLevel migration page maps out. If the org you are leaving is Zoho rather than Salesforce, the destination is the same but almost none of the artefacts are — custom modules, subforms, Deluge functions and Blueprint states in place of record types, formula fields and Apex — and our Zoho CRM to HubSpot migration page maps that crossing separately. If the org you are leaving is Dynamics 365, the artefacts rhyme without matching — business process flows, calculated columns and plug-ins in place of record types, formula fields and Apex — and the motive is usually mid-market seat cost rather than a wish for a second suite, which our Microsoft Dynamics to HubSpot migration page covers. Coming from Pipedrive the problem inverts entirely — there was never a custom object to inherit, so the work is untangling what the deal fields and spare pipelines were standing in for, which our Pipedrive to HubSpot migration page covers. Coming from Copper it inverts differently again: the source is a Google Workspace-native CRM whose Related Records relate almost anything to anything without saying why, so a Copper CRM to HubSpot migration spends its effort naming relationships rather than re-homing declarative logic. If you are leaving the same org but the reason is licence and admin cost rather than a wish for a marketing suite, the honest destination may be a plain pipeline instead — and a Salesforce to Pipedrive migration changes the decisions completely, because there are no custom objects, record types or formula fields waiting on the far side to receive the ones you are leaving. If the automation layer is moving at the same time as the CRM, the Zapier to n8n migration page deals with that half: scenarios, retries and error handling rather than objects and record history.
The honest part
What genuinely does not come across
Most of the record moves, and more of it than on a typical CRM change, because both platforms model companies and deals as real objects. Some of it still does not move, and a vendor who says otherwise has not read your org. Knowing which is which before you commit is what makes the lookback decision a choice rather than a discovery.
| What | Treatment | Why |
|---|---|---|
| Account, contact and opportunity field values | Moves | Values load cleanly once the destination properties and every dropdown option exist first |
| Open pipeline and stage position | Moves | Stage, amount, close date and owner land on a deal once pipelines and users have been created |
| Tasks, events, notes and logged emails | Moves deliberately | They load as engagements against the matching record, which is worth doing for open accounts and rarely worth doing for all history |
| Attachments and files | Moves deliberately | Files transfer and re-associate, but volume drives effort, so this is scoped rather than assumed |
| Field history and time in stage | Stays behind | The change trail belongs to the org that recorded it; historical stage-duration reporting cannot be rebuilt after the fact |
| Chatter, report snapshots and dashboards | Stays behind or is rebuilt | Chatter has no destination; reports are rebuilt in HubSpot's report builder against the new property names |
| Flows, Process Builder and Apex | Rebuilt | Different enrolment model and different branching — and Apex has no counterpart, so that logic moves outside the CRM or goes away |
| Web-to-lead forms, connectors and integrations | Replaced | Anything still calling the old org keeps creating records there after cutover |
You own the result outright: records in your own portal, workflows documented against the trigger that starts them, a field map showing where every Salesforce field went, and a written note of what was deliberately left behind. If your own team would rather run the load, we will build the schema map and the scaffold and stay on as backup — and if the honest answer on the call is that you should stay where you are, that is what you will hear.
Questions
Common questions before the move
Where do Salesforce leads go if there is no lead table to import into?
They become contacts. HubSpot's prospecting tools layer a leads view over contacts, but the record you import into is the contact, and where someone sits in the funnel is carried by a lifecycle stage property. The work is deciding which lead statuses map to which lifecycle stage, and what happens to leads that were already converted in Salesforce so they do not arrive twice.
Do we have to switch Salesforce off on cutover day?
No. It stays live and read-only for a lookback period, because field history, report snapshots and Chatter threads do not migrate and are still worth being able to open. What stops on cutover day is writing: web-to-lead forms, mailbox connectors and any integration still creating records get repointed as part of the cutover, not after it.
Do Flows, Process Builder and validation rules convert automatically?
No, and no converter would be honest about it. Each one is read, its real purpose identified, and rebuilt as a HubSpot workflow or dropped. Apex triggers have no counterpart at all and either become a workflow, a form requirement, or logic that moves outside the CRM entirely. A migration is the cheapest moment you will ever get to retire the ones nobody has needed in a year.
Can activity history come across, or does it stay behind?
Tasks, events, notes and logged emails can be loaded onto the matching records, and that is usually worth doing for open accounts. What does not reconstruct is the per-field change trail, campaign-level send statistics, and Chatter. Those belong to the system that recorded them, which is the argument for keeping the old org readable rather than for trying to import everything.
What breaks in reporting the day we switch?
Anything that measured duration or change rather than current state. Reports and dashboards are rebuilt in HubSpot's report builder, which is straightforward for pipeline and activity reporting. Time-in-stage and historical field values are the exception: if you need them, the numbers are exported and archived before cutover, because they cannot be reconstructed afterwards.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.