9. HubSpot SFDC Migration
(the transcript is below)
Action Step
Complete this before moving on.
Watch the full overview video above and read through the transcript below. Pay attention to why a migration is a system redesign with a data move inside it (not the other way around), and why the ELT approach has a documented failure mode.
Part 1: Hook / Open
A Head of RevOps sits down with leadership and says "we need to move to Salesforce" and everybody agrees, it needs to happen.
But then three months go by, six months go by, and the migration still hasn't started.
Because every time it comes up, the same fear kicks in: what if we break what's working, what if the sales team loses productivity for weeks, what if we end up worse off than where we started.
That's the situation at a lot of the companies we talk to that have outgrown their CRM. They know they need to move, but nobody wants to be the one who breaks what's working.
And the project that gets them through it is what we call the HubSpot to Salesforce Migration.
This is the project that takes an organization from one CRM platform to another without losing data, breaking integrations, or killing team productivity during the transition.
My name is Yasin from LeanScale, and in this video I'm going to break down for you our entire HubSpot to Salesforce Migration Playbook... what it is, the core concepts, how it gets built, and what changes once it's in place.
Part 2: What the HubSpot to Salesforce Migration Is
So when we talk about the migration project, what we're actually talking about under the hood is a system redesign with a data move inside it, not the other way around.
On the input side of this project there are five categories of decisions that need to be made: how accounts get structured, how opportunities map over, how contacts get split into leads and contacts in Salesforce, what happens to all the third-party tools connected to HubSpot, and what the overall data structure needs to look like in the new system.
On the output side, once the project is complete, the organization has a fully configured Salesforce instance with clean data, rebuilt automations, reconnected integrations, and a team that knows how to use it.
And here's the part most people don't expect: the migration itself is the single best opportunity to clean up years of accumulated technical debt, because you're already touching every record and every field.
The way I describe it to clients is that a CRM migration is like moving houses.
The wrong way to move is to throw everything into boxes, haul it to the new place, and figure it out later. You end up with the same mess in a nicer house.
The right way is to go room by room, decide what's worth keeping, what needs to be updated, and what should be thrown out, so when you move in, the new place actually works better than the old one.
That's what a structured migration does. It's not just a change of address, it's an upgrade to how the entire operation runs.
Part 3: Migration Pro Tips
Now the Playbooks Library below this video goes deep on the full methodology behind the HubSpot to Salesforce migration project, but before we get into how it gets built, here are a couple things you really don't want to get wrong when implementing this into a startup.
First — a migration is not a data move. HubSpot uses a single Contact object for both leads and customers. Salesforce splits that into two completely different objects: Leads and Contacts. Every single contact in HubSpot needs an architectural decision about where it goes. If that decision isn't made deliberately upfront, the downstream automations, reporting, and lifecycle tracking all break.
Second — almost every company we talk to says "let's just move everything over and clean it up later." That's what we call the ELT approach, and it has a documented failure mode. We've seen it firsthand. The time saved upfront always gets lost in post-launch cleanup, except now the team is also trying to learn a new system at the same time. The migration is the cheapest time to fix data problems because you're already touching every record. Cleaning up later means paying twice.
Third — if HubSpot has native quoting and the team is using it, Salesforce doesn't have an equivalent out of the box. That CPQ gap needs to be identified during scoping, not discovered on launch day.
Part 4: The Problem in Context
And the data backs up why this project is so key for startups who are scaling.
According to industry research, over 80% of data migration projects exceed their timelines or budgets, with cost overruns averaging 30% and time delays reaching 41%.
Gartner found that poor data quality costs organizations an average of $12.9 million per year, and 59% of organizations don't even measure their data quality.
CRM.org reports that 20 to 70% of CRM projects fail, with the leading cause being poor user adoption, and only 26% average adoption rates across sectors.
And a Dun and Bradstreet study found that sales teams spend approximately 546 hours per year dealing with data quality issues alone, which is time that could be spent selling.
So it's not just an ops problem. Sales is losing productivity to bad data, marketing is running blind without proper lifecycle tracking, finance can't get clean pipeline numbers for the board, and leadership is making decisions on a system the company has already outgrown.
Part 5: How It Gets Built
So how does a HubSpot to Salesforce migration actually get implemented?
At LeanScale, for all of our projects, we follow a four-phase approach: Strategy, Engineering, Enablement, and Handoff.
Strategy
In the migration project, the strategy phase is all about scoping, and it runs for roughly the first 30 days.
This is where we work with the stakeholders, the VP of Sales, RevOps, the operations lead, and we step through what we call "The Big Five," which are the five categories of architecture decisions that have to be made in every migration: how accounts get structured, how opportunities map from HubSpot deals to Salesforce, how the contact-to-lead split works, what happens with every third-party tool, and what the overall data transformation strategy looks like.
The reason this phase matters is that every one of those decisions cascades into the engineering build. If the contacts-to-leads architecture is wrong, every downstream automation, report, and workflow breaks. So nothing gets built until the architecture is locked.
Before the project even kicks off, our team gains admin access to the HubSpot instance and begins an initial inventory: fields per object, active workflows, connected integrations. We assemble a V1 of what the scoping recommendations need to look like, based on having implemented this project for dozens of startups before, combined with the unique data from the instance we're working with.
We also lean heavily on AI agents throughout this process, agents trained on our playbooks that know how to analyze HubSpot field structures, identify transformation opportunities, and put together a V1 scoping output. We go deeper into how we use AI in the implementation of this project in the full playbooks in the library.
From there, we iterate on those recommendations with the stakeholders across four to five scoping sessions, two meetings per week, and at the end of that process the Big Five decisions are documented, the ETL versus ELT approach is decided, and a workback plan with all milestones and dependencies is signed off.
Engineering
Phase two is the technical build, and this is where the bulk of the project lives, roughly 60 to 80% of the total effort.
There are five parallel workstreams that run during engineering: field mapping and data transformation, automations and workflows including what we call "The Hits" which are foundational automations every Salesforce instance should have (like stage timestamps, conversion tracking, renewal infrastructure, and ACV/TCV calculations). Then there's layout design and UX configuration, the actual data migration itself, and third-party tool installations and cutovers.
The field audit alone is where a massive amount of value gets captured. If a HubSpot instance has 500 fields, we're not lifting and replacing. We analyze every single field: is it being used, what's the fill rate, is it referenced in any workflow, is it a duplicate of something else. Typically 30 to 50% of fields have low fill rates or are no longer in use.
We've been building AI agents that connect to each of the major systems in go-to-market. We've built a Migration Agent that uses a schema mapping layer with all of the field mappings, object relationship translations, and data transformation rules codified. Using APIs and MCPs, that agent connects directly to both HubSpot and Salesforce simultaneously, and starts building out the lead-contact architecture, workflow recreations, and integration reconnections from the strategic output.
What used to be a purely manual 150-hour engineering effort now gets delivered in a fraction of the time because the agents handle the repetitive build work, the field analysis, and the workflow mapping, while our human engineers focus on quality assurance, orchestration and the transformation decisions.
The full details of the AI agents we use and the five-workstream migration process are broken down inside the playbook library if you're curious.
Enablement
Phase three is enablement, because the system is useless if the team doesn't know how to use it.
For the migration project:
We train end users, the sales reps, marketing, and customer success teams, on how to navigate the new Salesforce instance, complete their common daily tasks, and understand what changed from HubSpot.
We train the admins, RevOps and the Salesforce admin, on system management, workflow maintenance, how to troubleshoot, and how to make field and layout changes going forward.
And then there's a 2 to 4 week hypercare period where we provide reactive support for the issues that inevitably come up once real users are in the system at scale.
Handoff
From there, phase four is the handoff, and this is where maintenance expectations get set.
Now here's what trips people up after go-live: the most common post-migration failure is not a broken system. It's a system that slowly becomes irrelevant because no one is monitoring workflow health, data quality, or integration status.
Every time a new tool gets added, every time a workflow needs updating, every time data quality starts drifting, someone needs to catch it. If nobody owns that, what happens is workflows start failing silently, duplicate records accumulate, integrations fall out of sync, and within a quarter or two the team is back to the same complaints they had about HubSpot, just in a more expensive system.
So the handoff isn't just about transferring ownership. It's about making sure after the migration is complete... someone on the team understands the system deeply enough to keep it running the way it was designed.
Part 6: What It Unlocks + Close
So let's bring this all together to where we started. Once the migration project is in place, what actually changes?
The organization gets a CRM platform that actually supports their operational scale, with proper lead and contact architecture, clean data, and accurate pipeline reporting.
They get a foundation for every advanced revenue operations project that comes after it, whether that's full attribution, CPQ, territory management, or advanced analytics, because all of those require a properly structured Salesforce instance to work.
Teams that were spending 546 hours a year dealing with data quality issues are now working in a system with audited fields, deduplicated records, and automations that actually match how the business operates.
And the biggest thing that changes after this project is knowing the new system actually works better than the old one.
That Head of RevOps who kept delaying the migration because the risk felt too high can now walk into the next leadership meeting and show that the move is done, the team is trained, the data is clean, and the system is built to scale.
The sales team stops working around the CRM and starts working in it. And finance gets the pipeline visibility the board has been asking for, without anyone manually building reports.
Everything covered in this video about this project — the concepts, the methodology, the full implementation process — all of it is broken down in detail in our Playbooks Library for each project. Our Advisory Overview Playbook covers the problem, approaches, and strategic understanding behind this project. The Methodology Playbook goes deep on every concept we talked about for this project. And the Implementation walks through the step-by-step build process.
And if you're a revenue leader at a fast growing startup who's feeling good about the migration side after watching this, but you're thinking, okay, now that we're on the new CRM, how do I build the lead routing and inbound infrastructure on top of it, we have a whole playbook on exactly that called Automated Inbound. It's broken down the same way in our Playbook Library. And while you're there, you'll see we have playbooks on every major GTM project, from Market Map and Growth Model to Quote to Cash and more. Feel free to check those out next.
Again, this is Yasin from LeanScale, and I'll see you in the next one!
Comment in Slack
Post your answer in your onboarding channel.
What did you learn? What clicked?
Any questions — or will you have more questions once you actually get into the hands-on trainings? Either is fine. Just capture where you are right now.