A Salesforce to HubSpot migration is judged by what you decide not to copy. Records, automations and reports fall into three buckets: copy, archive or rebuild. Teams that sort them on purpose end up with a CRM people trust, and teams that skip the sorting move their mess across in six weeks.
I'm not against speed. One HubSpot partner advertises a six-week move without business interruption, and that is a reasonable promise for the mechanical part. The problem is that the timeline measures the part that is easy to measure.
Why the six-week timeline measures the wrong thing
A timeline tells you when data lands in the new system. It says nothing about whether the data means the same thing once it arrives. A Salesforce to HubSpot migration can finish on schedule and still leave you with a broken year of reporting.
The two platforms are built on different data models. Salesforce lets you stack custom objects, record types and validation rules over years, and the Salesforce developer docs show how much of that structure is configurable. HubSpot uses a flatter model of objects, properties and associations, described in the HubSpot developer docs. Anything that depended on a Salesforce-specific structure has to be translated or redesigned.
A customer we talked to was staring down around 1,300 duplicate records and pipeline stage transitions nobody had tested, with a migration window already set. The date was fine. The unanswered questions were the risk.
The Salesforce to HubSpot migration sort: copy, archive or rebuild
Here is the framework I use. For every data object, automation and report, we ask one question: does the business still act on this? If yes and it's clean, copy it. If it has historical value but nobody acts on it, archive it. If people act on it but the way it works is a workaround, rebuild it.
| Asset | Default call | Reason |
|---|---|---|
| Accounts, contacts, open deals | Copy after dedupe | Reps work these daily |
| Closed-lost deals and old activity | Archive | Useful for analysis, noise in the live CRM |
| Lifecycle stages and deal stages | Rebuild | Old stages encode old habits |
| Workflow-style automations | Rebuild | Most were patches on patches |
| Source and campaign attribution | Copy with care | Timestamps are costly to recreate |
For better or worse, the rebuild column is where the time goes. It's also where the value is.
Data: dedupe before you move, archive instead of copying everything
The cheapest duplicate to fix is the one you fix before import. Another customer told us their Salesforce database was hard to clean at its scale because they lacked both the headcount and the enrichment credits. Moving it unchanged would have turned a data problem into a HubSpot problem, with per-contact pricing on top.
So here is a rule of thumb. If a record has had no activity and no open association in a window your sales cycle makes sensible, archive it outside the CRM. You can bring it back if a use appears. You can't easily un-pollute a live portal once reps have built habits on it.
Attribution is the exception. Source data and first-touch timestamps are very hard to reconstruct after the fact, and mishandled fields often surface later as traffic filed under direct, a pattern we describe in how AI referrals end up as direct traffic in HubSpot.
Automations and billing logic: rebuild from the outcome
Copying a Salesforce automation into HubSpot copies its quirks. A customer's billing schedule is a good example: sales closed on the 15th were billed half then and half on the first of the following month, and Salesforce handled that awkwardly. The right move isn't to recreate the awkward workaround. It's to decide what the finance outcome should be, then build the shortest path to it in the new system.
My feeling is that about a third of long-lived automations in a mature org exist only because of an old constraint. That figure is my own working estimate from projects, not a study. When you list the automations, write the outcome next to each one. Any without a living outcome is a candidate to retire.
Reports: rebuild from the questions leadership asks
A report migrated unchanged is a report built on an old definition of a stage, a source or a "qualified" lead. Start from the five or six questions your leadership asks weekly, and rebuild those first on the new data model. Then compare them against the old numbers and write down every difference you can explain.
That comparison matters more than the dashboard itself. If the new pipeline number is 8% lower than the old one, you want to know whether the cause is deduplication, a changed stage definition or a bug. Without it, the first forecast meeting after go-live turns into an argument about the tool.
What a Salesforce to HubSpot migration really costs beyond licences
The search results I see on this topic mostly stop at timelines and field mapping. They leave out total cost. Here is a worked example, using my assumptions and not a benchmark: a team of 12 reps loses two hours a week each for six weeks while they relearn the system and fix records. That is about 144 hours, before any consultant time or integration rework. Add a reporting rebuild nobody scoped, and the invoice for what didn't transfer exceeds the invoice for the move.
Adoption in the first 90 days follows the same logic. Reps use the new CRM when the stages match how they sell and the data on the record is something they can trust. That is a rebuild outcome, not a training outcome.
When to stay on Salesforce
I don't have a clean rule for this. Complex territory hierarchies, deep permission models and heavily customised objects are places where HubSpot may not match what you have. Sometimes the honest recommendation is to stay, or to move in phases. If a partner never says that, ask why.
The case-study checklist for a Salesforce to HubSpot migration covers what proof to demand before signing, and our HubSpot implementation partner scorecard covers how to grade the people doing the work. If you have already moved and the portal feels wrong, telling a broken portal from a rebuild quote is the next read. For how we run these projects, see our Salesforce to HubSpot migration service and the wider revenue operations practice.
My recommendation: treat the six weeks as the easy part in any Salesforce to HubSpot migration, and spend your attention on the sort.