The short version: A Salesforce to HubSpot migration is an 8-week project, not a 2-week one. The work is 30% technical and 70% decisions. Real cost for a 50-rep team is $50,000-$100,000 once you count labor, rep time, and the revenue dip nobody budgets for.
The honest version: Sometimes the right answer is to stay on Salesforce. We tell you exactly when below, including the situations where we've told our own clients not to migrate.
Who this is for: B2B SaaS teams between 10-200 employees running Salesforce for 18+ months and wondering whether the overhead still makes sense.
HubSpot has no native equivalent. Preserve it upfront or lose it.
No many-to-many in HubSpot. Flatten, archive, or rebuild.
Field-level errors quietly distort every report built on them.
Scoring, nurtures, and attribution all need rebuilds.
Before you read a word of migration advice, you should know how the person writing it makes money. We're a RevOps agency. We run CRM migrations for a living. Every "should you leave Salesforce" guide you'll find, including this one, was written by someone who profits when you say yes.
So here's the part a pitch would leave out: one of our deepest client engagements runs entirely on Salesforce, and we've never advised them to migrate. Another client came to us evaluating a move right before their Salesforce renewal, and after we worked through it together, they renewed. If your Salesforce is working, stay on it.
This guide is for the teams where it isn't. I run growth operations at RevOps Shop, and over the past few years our team has moved companies onto HubSpot from Salesforce and Microsoft Dynamics, or built their HubSpot environment from the ground up when they had no CRM at all. That includes a national freight brokerage that went from kickoff to go-live in 10 weeks because their old CRM contract had a hard expiration date, and a solar company where 107 people logged into the new system at the go-live all-hands. What follows is what I'd tell a friend who runs RevOps and is staring at this decision: the real timeline, where the costs hide, what breaks when teams rush, and the honest version of when to stay.
The real migration timeline: 8 weeks, not 2
If you're running Salesforce with 20 to 150 reps and you've been on it for 18+ months, plan for 8 weeks. Not 2. Not 4. Eight.
The technical work is maybe 30% of the effort. The other 70% is decisions: what migrates, what gets archived, and how your automation logic gets rebuilt in a platform that thinks differently. Teams that budget for the technical 30% and improvise the rest are the ones who call us in month four.
- Inventory every object and field
- Map custom objects
- Catch the dedup traps
- Validate every contact
- Reps flag the live deals
- Archive the rest
- Rebuild routing
- Consolidate workflows
- Recreate reporting logic
- Sandbox-test every import
- Run parallel if you can
- Support go-live week hard
Weeks 1-2: Audit and object mapping
You need to know what you actually have before you move it. Every audit we run turns up things nobody at the company knew were there. Real findings from portals we've audited: 8,000+ contact properties, roughly 6,000 of them redundant. 231 web forms doing the job of 2. More than 300 undocumented workflows and 47 connected apps with read/write access that nobody could explain. None of those teams thought their instance was that messy. Count first.
Object mapping is where most first-time migrations get stuck. Salesforce lets you build custom objects and relationships that HubSpot doesn't natively support. You might have a custom object linked to Accounts with a many-to-many relationship. HubSpot doesn't do many-to-many. You have to decide: flatten it into a line-item structure, archive it, or build a workaround. That decision takes time, and it can't be delegated to whoever is running the import tool.
The traps only show up in the data. One company we migrated had a customer with 212 site-level accounts all sharing a single corporate email domain. HubSpot's default domain-based deduplication would have quietly merged all 212 into one record on import. We caught it in the audit and built a parent-child structure keyed on a unique ID instead. If we'd caught it after import, that's a week of unwinding.
Weeks 3-4: Data cleaning and transformation
Your Salesforce database is dirtier than you think. On a recent cleanup we validated 167,000 contacts and 62,000 came back invalid. That's not an outlier. That's a normal result for a database that's been accumulating for five years.
This phase is 70% of the migration work, and it's not technical. It's decisions. Do you migrate inactive contacts? Closed opportunities from 2022? Custom fields nobody uses? Every "yes" adds complexity. Every "no" is a conversation with the team that might need that data.
One rule we learned the hard way: reps are the only people who know which deals are actually alive. Close dates, stage fields, last-activity timestamps, all unreliable. Before any import, we put the open pipeline in a shared sheet and have each rep highlight the deals that are real. Only highlighted deals enter the new active pipeline. Everything else lands in a two-stage archive pipeline where it's searchable but not polluting the forecast. At one client, this exercise surfaced something uncomfortable: the sales team's weekly planning spreadsheet was more accurate than the CRM itself. That's not a reason to skip the exercise. That's the reason to do it.
Weeks 5-6: Workflow and automation rebuild
Salesforce Process Builder, Flow, and custom code don't port to HubSpot. There's no import tool. You're rebuilding every automation from scratch, and if you have 50 workflows, that's 50 rebuilds.
But this is also your once-in-a-decade chance to not recreate the mess. When we rebuilt Terraboost's lead routing, the old setup had roughly 16 workflows per lead source. We replaced them with 2 master workflows, one inbound, one outbound. Nobody plans to build 16 workflows per source. It accretes, one urgent request at a time. If you port your automation one-to-one, you're paying to move the mess.
A simple nurture sequence might take a day. A routing system that survives rep turnover takes a week. Read more in our guide to HubSpot lead routing for B2B SaaS sales teams.
Weeks 7-8: Testing, training, and cutover
Run parallel systems for one to two weeks if your calendar allows it. Reps log into both. You validate that data is flowing, workflows are firing, and reporting matches. I'll be honest: when a deadline forces it, we've run hard cutovers instead, with the whole team on standby through launch week. It's survivable. But if you have the room, run parallel.
Either way, don't test in production. We test imports in roughly 200-record cycles against a sandbox before touching the live portal, and we sequence imports deliberately: deals and tickets first, contacts second, files third, associations last. Teams that skip the buffer go live and discover on day one that lead routing is broken or a custom field didn't map. Reps lose trust in a new system fast, and you don't get that trust back with a Slack apology.
What actually breaks in Salesforce to HubSpot migrations
These are the specific failures we've either caught in audits or been hired to clean up:
Lead conversion history disappears
Salesforce tracks which lead converted into which contact and opportunity. That history is valuable for attribution and forecasting, and HubSpot has no direct equivalent. You can preserve it with a custom object or linked record, but you have to decide that upfront. If you don't, it's gone.
Custom object relationships break
If your custom objects relate to each other in ways HubSpot doesn't support, you choose: rebuild the relationship in HubSpot's structure, archive the object, or accept the loss. We've flattened custom objects into line items and built workaround objects. It works, but it's not the same structure, and your team needs to understand that before go-live, not after.
The sync can lie to you
If you run HubSpot and Salesforce side by side during transition, validate the fields the sync touches, not just the record counts. At one company we audited, the HubSpot-Salesforce sync had silently stamped incorrect creation dates on every deal that predated HubSpot. Nobody noticed for months, until the board asked for reporting precise enough to expose it. Silent corruption is worse than a visible sync error, because every report built in between inherits it.
Deduplication tools merge people who aren't duplicates
Migration is when most teams finally run dedup, and aggressive matching rules do real damage. We were brought in after a dedup pass incorrectly merged roughly 1,200 contacts out of 4,000 processed, combining unrelated people into single records. Here's the part that hurts: HubSpot cannot un-merge a contact. The only fix is recreating records, and a recreated record loses its activity history forever. Merge on conservative rules (we use name plus LinkedIn URL, or name plus email domain) and exclude active customers and open deals from any automated merge.
Pardot and Marketo sync dies
If you're running Salesforce with Pardot or Marketo, that integration ends the moment you leave. You're moving to HubSpot's native marketing automation, which means rebuilding lead scoring, nurture sequences, and your attribution model. And don't underestimate what split attribution was already costing you: at one company running marketing and sales in separate systems, only 25 of 207 leads over two and a half years had their source tracked into the CRM. Marketing couldn't prove its own pipeline. Consolidating fixes that, but only if you rebuild attribution on purpose. Learn more in our HubSpot Marketing Hub implementation guide.
Reporting and dashboards are manual rebuilds
Your Salesforce dashboards don't migrate. If you have 30 dashboards, that's 30 rebuilds. Most teams don't account for this in the timeline. (There's an upside buried here too, covered in the post-migration section: most of those 30 dashboards weren't being used anyway.)
The real cost of migration
Migration costs come in three buckets: software, labor, and opportunity.
Software costs
HubSpot's pricing is lower than Salesforce for most SaaS teams. A 50-rep team on Salesforce Professional ($165/user/month) is spending $8,250/month. HubSpot Sales Hub Professional ($120/user/month) is $6,000/month. That's $27,000/year in savings. But if you need Sales Hub Enterprise ($165/user/month), the license math is a wash. The real savings come from what falls away: managed packages, Pardot licenses, and the third-party tools you bought to glue Salesforce together.
One more thing worth knowing: HubSpot no longer offers professional migration services itself. The work lands on your team or a partner either way. Budget accordingly.
Labor costs
In-house, you're looking at 200-300 hours: one person for two months or two people for one. At $100/hour loaded cost, that's $20,000-$30,000. An agency runs $15,000-$40,000 depending on complexity.
The hidden labor cost is rep time. Reps spend 5-10 hours learning the new system. For a 50-rep team, that's 250-500 hours. At $50/hour loaded cost, that's $12,500-$25,000 in lost selling time that never shows up on an invoice.
Opportunity cost
During migration, your team is distracted. Revenue can dip 5-15% during the transition weeks. For a $5M ARR company with 20% margins, a 10% dip is roughly $83,000 in lost margin for one week. Nobody selling you a migration leads with that number. Plan for it, staff support for launch week, and time the cutover away from your biggest closing month.
Total for a 50-rep SaaS company: $50,000-$100,000 across all three buckets.
When to stay on Salesforce
We make money when companies migrate, so weigh this section knowing that we wrote it anyway.
You have complex custom objects and dependencies
If your Salesforce is deeply customized with multiple custom objects, complex relationships, and custom code that works, migration means rebuilding your entire data model. The client I mentioned in the intro, the one we've never advised to migrate, has exactly this profile: a global software business with revenue infrastructure built into Salesforce over years. We build on their Salesforce instead. The platform isn't their problem, so switching it wouldn't solve anything.
Your team is small (under 10 reps)
Salesforce's admin overhead doesn't hurt until you have 15+ reps and complex routing. If you're small and it works, the savings don't justify the disruption.
You have heavy Pardot integration
If marketing and sales are deeply integrated through Pardot with sophisticated scoring and nurture logic, leaving Salesforce means rebuilding all of it. If it's working well, the rebuild may cost more than the platform ever will.
Your admin situation is stable
A strong Salesforce admin who knows your instance inside out is worth more than the license savings. The honest corollary: this calculus flips the day that person resigns. We've watched a departing admin turn "we're fine on Salesforce" into "we need to understand what we're even running" within a month. If your entire CRM lives in one person's head, that's a risk conversation worth having before it's an emergency, whichever platform you're on.
You're renewing under time pressure
A migration decision made six weeks before a renewal deadline is a bad migration decision. One of our clients was in exactly that spot: evaluating HubSpot with the renewal clock running and real risk of losing data access if the contract lapsed mid-evaluation. The right call was to renew Salesforce and run the sales team's day-to-day motion in HubSpot on top of it, with a sync between them. Dual-CRM isn't elegant, but it's a legitimate landing spot, and it beats a rushed cutover. Decide your CRM strategy on your calendar, not your vendor's.
When to migrate: the real reasons teams leave Salesforce
Salesforce rarely breaks because the software is bad. It breaks because the cost of keeping it running quietly compounds.
Your admin overhead is outpacing the value
You're spending 20+ hours a week on Salesforce maintenance and every change request takes a week. The scariest version of this is the instance one person built over six years. We rebuilt a CRM after exactly that person left: 32+ round robins, 300+ undocumented workflows, and every fix a three-hour archaeology dig. Nobody could tell which automations were load-bearing. If reading that gave you a flicker of recognition, your migration trigger isn't the license bill.
Your reps don't trust the data
Your Monday pipeline review is a debate about which numbers are real. Reps keep private spreadsheets. Your forecast is a guess. We've opened a portal and found 3,864 leads sitting in open stages that dated to before the prior year. That's not a Salesforce problem, strictly speaking. It's a data quality and adoption problem. But if you've genuinely tried to fix it and the platform keeps fighting you, a migration can reset trust, with one warning below that most guides skip.
Here's the warning. There's a line we hear in discovery calls almost word for word: "Salesforce was the same story. We don't want a repeat." That fear is earned, and switching platforms alone will not fix it. We've migrated a company off Salesforce and watched the same adoption problems resurface in HubSpot within a quarter. The migration fixed the data model. It didn't fix managers running forecasts from memory. If nobody inspects pipeline in the new system, you'll be writing this same evaluation doc again in three years. Migrate the platform and the operating habits, or don't bother.
You're paying for features you don't use
You're on Salesforce Enterprise because you needed one advanced feature three years ago, and you're paying $200+/user/month for complexity your team doesn't touch. HubSpot's simpler model means paying for what you use.
Your reps hate the UI
Salesforce is powerful but dense. If reps are complaining about clicks, that's a real adoption cost, and better UX genuinely helps. Just don't expect UX alone to carry adoption (see above).
You're stuck on a managed package treadmill
You're paying for three managed packages to do what HubSpot does natively, and every Salesforce update breaks one of them. Fewer dependencies means fewer 2am surprises.
The migration sequence, compressed
The method we run on every migration, whatever the source system: audit, map, clean, import, validate.
Inventory every object, field, workflow, and integration. The object mapping document you produce here is the north star for the whole project.
Dedupe, archive, standardize. Have reps flag the deals that are actually alive. Document every keep/kill decision.
Build the portal, rebuild the automations, and write the matching contract before anyone writes an import script: match on record ID first, then email, then name plus domain, and label every record with which rule matched it so a human can review the weakest tier.
Import in sequence, run parallel if you can, then support the team hard for two weeks.
For the object-mapping traps specifically (lead conversion, campaign history, opportunity contact roles), read our companion piece: Salesforce to HubSpot Migration for B2B SaaS: The Operator's Playbook.
Building your HubSpot portal for adoption
The migration is the technical work. The real project is a portal your reps actually use, and most HubSpot implementations stall here: reps don't adopt, pipelines don't reflect reality, leadership stops trusting the reports. It happens because the portal was built for the CRM, not for how your reps actually sell.
Three things we've learned running these rollouts:
Train managers first. If managers don't understand and enforce the new system, reps ignore it within two weeks. We train managers on dashboards and inspection before reps ever see the tool, because reps notice where the Monday pipeline review actually happens. If the manager runs it from HubSpot, adoption follows. If the manager runs it from a spreadsheet, the reps' spreadsheets are staying too. The fix for low adoption is almost never more training. It's managers inspecting the pipeline inside the tool.
Gate something reps need. The single most effective adoption lever we've deployed: at Worldwide Logistics, the pricing team agreed not to quote any deal that wasn't in the CRM. No record, no price. Adoption stopped being a training problem overnight, because the system became the only door to something reps wanted.
Guardrails beat handcuffs. If you lock the system down too hard, reps route around it entirely. We once watched a rep respond to a restrictive edit permission by sending the email from a personal account, and the CRM captured nothing. Enforce with SLAs, dashboards, and coaching, not permission walls.
And a diagnostic for the weeks after go-live: if adoption drops in the first 30 days, it's process friction, so fix the UX. If it drops after 60+ days, it's cultural, so add enforcement.
For the full build-for-adoption playbook, see HubSpot Implementation for SaaS Companies That Actually Gets Used.
Post-migration: the first 90 days
Go-live is not the finish line.
Week 1: Your team is confused, reps are slow, and you're fixing workflows in real time. This is normal. Have ops on standby, and treat every rep complaint in week one as gold. That feedback is free QA.
Weeks 2-4: Reps get faster. Edge cases surface. You train the people who were on vacation during go-live.
Weeks 5-12: Adoption stabilizes and you run your first full month of reporting in HubSpot.
Don't build your dashboards before go-live. Build them after you understand how your team actually uses the system. Your first month of real data will show you which of those 30 old Salesforce dashboards mattered. In our experience, it's usually about five.
If you're inheriting someone else's migration or want a third-party read on your plan, we offer a fixed-scope, one-week HubSpot portal audit: we review data quality, workflows, lead routing, pipeline architecture, and reporting, and hand you a prioritized fix list with the cost to implement each one.
Should you hire an agency or do this in-house?
Do it in-house if you have a strong ops person who knows both platforms, 200-300 hours of genuine capacity, and the desire to own the knowledge afterward. That's a real option and plenty of teams take it.
Hire help if you don't have the bandwidth, need to move faster, or want someone else to own the risk and the timeline.
If you hire us, here's what you're getting, stated plainly: we've shipped 500+ HubSpot workflows, we've run migrations from Salesforce and Dynamics, and we've done it at both ends of the size spectrum, from 10-rep startups to a national freight brokerage on a contract deadline. When we rebuilt DealRoom's lead routing and data quality, demo-to-SQL conversion doubled from 10% to 20% in 90 days, on the same team and budget. We handle the audit, the mapping, the build, the migration, and the first 90 days of support.
The bottom line
A Salesforce to HubSpot migration is an 8-week project: 30% technical, 70% decisions about what to keep, what to archive, and how your automation gets rebuilt. Real cost for a 50-rep team is $50,000-$100,000 across software, labor, and the revenue dip nobody budgets for. The teams that get it right plan the object mapping before touching either platform, clean before they import, and treat manager adoption as part of the project, not an afterthought.
And one last thing, since this whole post was written by people who sell migrations: the cheapest migration is the one you don't run. If your Salesforce works, keep it. We give that answer to real prospects, and we'll give it to you, because we'd rather keep your trust than win one project. Our business runs on engagements that last years, and a migration that shouldn't have happened doesn't last.
If you want a second opinion either way, get in touch. We'll give you a straight read on whether Salesforce or HubSpot is the right platform for your stage. 20 minutes. No deck.
