From the May 27th, 2026, edition of How Teams Work
Since founding Process Pro, we've completed dozens of Salesforce-to-HubSpot migrations.
At least a third of those came to us as rescue projects, after someone else took a shot at it first.
Not because migrations are impossibly hard.
They're not.
But because the mistakes people make while attempting them aren't random. They're the same ones, project after project, company after company.
Something's changed over the last year or two.
More of our clients are having the conversation, not just about integrating Salesforce and HubSpot, but about whether they still need both. Rising platform costs, high administrative overhead, and the pressure to get all your data in one place are pushing mid-market SaaS companies to look at platform consolidation seriously.
Which means more migrations. Which means more of the same mistakes.
Here's what we keep seeing.
Get this one wrong, and everything else gets harder.
The typical scenario: someone's Salesforce contract is up in December, so they figure they'll start the migration in October.
That's two months.
We tell them the project should take three to four. They say they can probably do it in three if they push. So they start on October 1st, cut corners on everything, and end up on the phone with Salesforce in December asking for a contract extension.
And Salesforce knows you're leaving. They have every incentive to make that extension expensive.
What good looks like: Plan for 90-120 days for the migration project itself, then add a 30-60 day buffer where both systems are running at the same time. That overlap isn't wasted time. It's what lets you move things in phases, catch issues before they become emergencies, and stabilize before you're fully off Salesforce.
It's also what gives you the room to do everything else on this list the right way. If you don't have time, you take shortcuts. And shortcuts tend to compound.
Most teams approach data migration the same way they approach moving apartments: they box up everything, move the boxes, and figure out what to do with it later.
That works fine for furniture. It doesn't work for CRM data.
We've seen companies with 500 fields on the contact object in Salesforce, of which they're actually using maybe 200. They bring all 500 over. Now, HubSpot is messy from day one.
We've seen 100,000 contact records where the last activity on 40,000 of them was three years ago. They bring all 100,000 over. Now your new CRM is already full of junk.
What good looks like: Before you move anything, audit your data across three dimensions: accuracy (is it right?), completeness (is it full?), and usefulness (do you actually need it?).
If the answer is no on any of those three, it probably shouldn't follow you to HubSpot. For data you do want to bring, deduplicate, enrich where needed, and map it to how HubSpot is actually structured, not how Salesforce was.
A migration is a rare chance to clean house. Use it.
When you've spent years in Salesforce, it's easy to assume every CRM works the same way.
They don't.
Salesforce and HubSpot are not the same tool. While they have similar features, they are structured in very different ways.
For example, in Salesforce, a Lead is its own distinct object that converts into a Contact and Account once it is qualified. In HubSpot, Leads are objects that exist alongside Contacts that represent the Pre-Deal sales process. Object definitions are different. Property defaults are different. Lifecycle stage logic is different.
The mistake is assuming your Salesforce data model maps cleanly to HubSpot. It usually doesn't. And when you build workflows or automations based on how Salesforce worked, you end up with processes that don't translate, and nobody notices until they're already in production.
What good looks like: Before you build anything, get your team comfortable with how HubSpot actually works. Spin up a dev account. Build and test automations. Understand the object structure.
If you're working with someone like us, this is the conversation we have at the start of every project. Figuring out the differences after you've migrated is a lot more expensive than figuring them out before.
Data is the obvious thing to move. Automations are what people often forget to account for, and more specifically, all the steps it actually takes to move them to a new system.
This includes Salesforce Flows, workflows built with middleware tools like Make or Zapier, and any other custom processes that leverage Salesforce data. All of it needs to be mapped out before you start.
What seems like a straightforward transfer rarely stays that way. As you work through each automation, you'll often find yourself needing to rework the logic, and sometimes the underlying process too. That's the right thing to do, but it compounds the time it takes.
A migration is one of the few moments where you have a legitimate reason to stop and ask whether the way something was built still reflects how the business actually operates. Taking that opportunity is worth it. Be sure to account for additional planning and build time in your integration timeline.
What good looks like: Do a full automation inventory before you move anything. Separate what's actively running and business-critical from what was built years ago and never touched since.
Taking inventory is just the starting point, though. For each automation you decide to bring over, you need a clear plan for how it gets migrated. Account for any process changes you want to make along the way, just a straight rebuild of what you had before. Some automations will move natively into HubSpot workflows. Others will require updates to third-party middleware connections. Custom-coded actions or webhooks need to be reviewed and updated to work with the new system.
Done right, this process doesn't just move your automations. It gives you a chance to clean up the technical debt you've been carrying and build something that actually reflects how your team works today.
Salesforce doesn't exist in a vacuum. It's probably pushing data to your ERP. Pulling from your data warehouse. Connected to your outbound sequencer. Triggering your support tickets. Somewhere in your tech stack, there's a web of processes all running through Salesforce.
When you move to HubSpot, every one of those connections needs to be rebuilt or replaced. The teams that don't map this out ahead of time discover it mid-migration when something breaks.
What good looks like: Map out your full tech stack and take inventory of every integration connected to Salesforce. For each one, decide: does this get rebuilt in HubSpot on day one? Does it move in a later phase? Does this become an opportunity to simplify?
And for the ones that have downstream dependencies, data flowing to or from other tools, workflows triggering in other systems, make sure you understand the full scope before you start pulling things apart.
You can do everything else right on this list and still have a painful migration if your team isn't ready when the system goes live.
The classic mistake: everyone gets access on go-live day, training happens the following week, and for the first month, nobody knows what they're doing. Salespeople can't find their deals. Marketing can't run a campaign. The ops team fields questions constantly.
Everyone's frustrated, and the verdict is that HubSpot is worse than Salesforce. That verdict sticks.
What good looks like: Get your team into the system before it's live. Put them in a sandbox with dummy data and let them play with it. Run them through HubSpot Academy on the areas of the platform they'll actually use.
And do UAT (user acceptance testing), not internal QA for bugs, but actual end-users stress-testing whether the system is set up for how they work. A salesperson will find problems an ops team never would. That's the point.
When you do this right, go-live day is anticlimactic. People are already comfortable. They're already seeing value. The goal is for day one in production to feel like week three.
Every mistake on this list comes from the same place: moving fast without a plan.
Migrations fail when teams treat the technical cutover as the project. It's not. The cutover is the last twenty percent. The first eighty percent is planning, your data, your assets, your integrations, your team's readiness, and enough time to do all of it right.
The teams that get it right aren't necessarily better at HubSpot. They're just more honest about how long it actually takes to do this well.
If you're mid-process on a migration or starting to think about one, feel free to throw some time on my calendar. Happy to share what we're seeing.
Want to get the "How Teams Work" newsletter sent to your inbox? Subscribe Now.
