The Salesforce to HubSpot Migration Playbook

Migrations fail on model and process, not on export

The CSV moves in an afternoon. The revenue engine takes a quarter.

Almost every failed Salesforce to HubSpot migration gets blamed on the wrong thing. Leadership hears "the data didn't come over" and assumes a technical export problem. In practice the records almost always arrive. What breaks is everything wrapped around them: the object relationships that made the data mean something, the automation that moved deals forward, the reports that leadership trusted, and the daily habits of the team that has to live in the new system. Move the data and skip the rest, and you get a clean-looking CRM that nobody uses and no one believes.

This is a good outcome, to be clear. HubSpot's data model is simpler, its automation is more accessible to the people who actually run the process, and the total cost of ownership usually drops. But "simpler" is exactly why a one-to-one copy fails. You cannot pour a decade of Salesforce customization into HubSpot unchanged, because the two platforms model the same business differently. The migration is a chance to shed the accumulated complexity most Salesforce instances carry. Teams that treat it as a lift-and-shift waste that chance and import the mess along with the data.

Treat this as a RevOps project with a data component, not a data project with a RevOps footnote. The sequence that follows is deliberately ordered: decide why you're moving, understand what actually breaks, map the model, clean, cut over, rebuild automation with intent, and drive adoption. Skip a step and it comes back as a fire drill three weeks after go-live.

A migration is not a copy. It is a rebuild of your revenue process on a platform that happens to already have your data in it.

Move for a reason you can name, or don't move yet

The strongest reason to migrate is process pain, not license cost.

Most teams that move from Salesforce to HubSpot are not leaving because Salesforce can't do the job. They're leaving because the cost of getting Salesforce to do the job, in admin time, consultant hours, and integration glue, has quietly outgrown the value. The system has become something only two people understand, the marketing and sales data live in separate worlds stitched together by a sync that breaks, and shipping a simple process change takes a ticket and a sprint. If that's your reality, HubSpot's unified model and lower operating overhead are a real answer.

The honest counter matters just as much. There are situations where you should not move, at least not now. If your business depends on deeply bespoke Salesforce logic, heavy Apex and custom development, complex CPQ, or a mature partner and integration ecosystem built specifically on Salesforce, HubSpot may ask you to give up capability you actually use. If a migration is being driven purely by this year's license renewal, pause. A rushed move to dodge a renewal date tends to cost more in lost productivity and rework than the contract you were trying to escape. Migrate when the process case is clear and the timing is yours to control.

Name the reason in one sentence a VP would repeat back to you. "We're moving because our go-to-market data is split across three systems and we can't report on the funnel end to end" is a reason that will survive the hard weeks. "Salesforce is expensive" will not.

What actually breaks when you migrate

The failure modes are predictable, which means they're preventable.

The records land. What breaks is the meaning around them. Four things account for nearly every painful migration, and none of them show up in a row count. Knowing them in advance is most of the defense, because each one has a clear owner and a clear fix if you plan for it rather than discover it at go-live.

The data model is the first and biggest. Salesforce and HubSpot don't structure the same business the same way, so a literal copy either loses relationships or invents junk objects to preserve them. The automation logic is the second: Salesforce workflow rules, Process Builder flows, and assignment logic don't translate line for line into HubSpot workflows, and rebuilding them one to one usually recreates old problems. Reporting is the third and the most politically dangerous, because leadership judges the migration by whether the numbers they trust still match. And history and attribution, the activity timelines, the field-change audit trail, the campaign influence, are the fourth, and the one teams most often assume will "just come across." It won't, not fully, and you need to decide on purpose what's worth bringing.

Notice that three of the four are decisions, not data problems. That's the point of this playbook. You de-risk the move by making those decisions deliberately and early, before a single record is imported.

Map the data model before you touch a record

Get the object mapping right and the rest of the migration gets dramatically easier.

Salesforce and HubSpot share a lot of vocabulary and mean slightly different things by it. Salesforce Accounts become HubSpot Companies. Salesforce Contacts become HubSpot Contacts. Salesforce Opportunities become HubSpot Deals, and you'll map the opportunity stages onto a deal pipeline. Custom objects map to HubSpot custom objects, which are an Enterprise-tier capability, so confirm your subscription supports them before you design around them. The relationships between records are handled by HubSpot associations, and modern HubSpot supports labeled associations, so a company can relate to a contact as, for example, "decision maker" or "billing contact" rather than just a generic link.

The place people trip is the Lead. In Salesforce, a Lead is a fully separate object with its own ID, a holding pen for prospects that exists independently of Contacts until conversion. HubSpot does not work that way. The native Salesforce integration maps Salesforce Leads into HubSpot Contacts, and the state you tracked with the Lead object is expressed through the contact lifecycle stage and lead status properties. HubSpot does now have a Leads object of its own, available with a Sales Hub Professional or Enterprise seat, but it is not a standalone bucket like Salesforce's. A HubSpot Lead always sits on top of an existing Contact or Company and represents an active "hand raise" to work in the prospecting workspace. Trying to recreate the Salesforce Lead object one to one is the single most common modeling mistake in this migration. Map Leads to Contacts, carry the qualification state into lifecycle stage, and use the HubSpot Leads object for what it's built for.

Spend real time here. Model decisions cascade into every downstream step: how you clean, how you import, how you rebuild automation, and how your reports reconcile. This is the chapter that pays for itself. Our HubSpot implementation playbook goes deeper on structuring objects and pipelines from a blank slate, which is a useful companion when you're reshaping the model rather than copying it.

Clean before you migrate, not after

Every dirty record you import is a dirty record you now maintain in two systems' worth of habits.

A migration is the best chance you will ever get to clean house, because you're touching every record anyway and no one is emotionally attached to the old system yet. Do the work in the export staging layer, before anything lands in HubSpot. Deduplicate contacts and companies, because Salesforce instances accumulate duplicates over years and HubSpot's contact model, keyed on email, will surface every one of them. Rationalize fields ruthlessly: most Salesforce orgs carry hundreds of custom fields, and a large share are empty, redundant, or haven't been written to in years. If a field has no owner and no report depends on it, it does not earn a seat in the new system.

Then make the explicit decision most teams skip: what history do you actually bring? Open and recently closed deals, active contacts, current-year and prior-year data for reporting continuity, these clearly come. Ten years of closed-lost opportunities, activity logs on dead accounts, and the audit trail of field changes on records no one will open again, these are a choice, not a default. Bringing everything is expensive, slows the import, and clutters the new system on day one. A common and defensible pattern is to migrate the live operating set into HubSpot and keep a read-only Salesforce export or archive for the deep history you're legally or analytically required to retain.

Write the rules down before you run them. "We keep deals closed within the last three years, all open pipeline, and any contact with activity in the last 18 months" is a rule your whole team can see and challenge. Cleaning is where a migration quietly becomes a data-governance reset, and that's a feature, not a detour.

Cut over in phases, and run in parallel

Big-bang cutovers are seductive and risky; phased cutovers are boring and they work.

There are two ways to flip the switch. A big-bang cutover moves everything and everyone at once on a set date. It's simpler to coordinate and there's no dual-system period, but it concentrates all the risk into a single day, and if reporting or automation is wrong, the whole revenue team feels it at the same time. A phased cutover moves in controlled slices, by team, by object, or by business unit, so problems surface small and get fixed before they reach everyone. For most mid-market and larger teams, phased is the safer default. Big-bang can be right for a small, clean org where the coordination cost of running two systems outweighs the risk.

Whichever you choose, plan a freeze window and a parallel period. The freeze is a short, communicated window where you stop changes in Salesforce so the final data snapshot is stable while it imports; nothing is worse than migrating data that shifted mid-load. The parallel period is the stretch where HubSpot is live but Salesforce is still available read-only, so you can reconcile numbers, confirm nothing critical was lost, and give the team a safety net while confidence builds. Set a firm end date for the parallel period up front. An open-ended "we'll keep both for a while" quietly becomes forever, and paying for and maintaining two CRMs is its own failure mode.

Import order matters more than it looks. Companies before contacts before deals, with associations built as you go, so every record has something to attach to when it lands. Load deals before their companies exist and you get a pile of orphaned records and a bad first impression on day one.

Rebuild automation, integrations, and reports on purpose

The one-to-one rebuild is a trap. Rebuild for how HubSpot works, not how Salesforce did.

This is where discipline pays off. The instinct is to recreate every Salesforce workflow rule, every Process Builder flow, and every report exactly as it was, so nothing "changes." Resist it. Much of your Salesforce automation exists to compensate for Salesforce's structure or to patch a process that drifted years ago. Porting it verbatim into HubSpot workflows imports the workarounds along with the intent. Instead, list what each automation is supposed to accomplish in business terms, lead routing, stage progression, task creation, notifications, then build the shortest HubSpot path to that outcome. You will usually end up with fewer, cleaner automations that a marketer or RevOps specialist can maintain without a developer.

Do the same audit for integrations. Every tool wired into Salesforce needs a decision: does HubSpot replace this natively, does it connect through the HubSpot ecosystem, does it need a middleware layer like a connector or an iPaaS, or does it retire because the migration made it redundant? Some Salesforce integrations exist only because Salesforce needed them; in HubSpot they simply disappear. Map each one deliberately rather than assuming you must rebuild the whole stack.

Reports are the trust test. Leadership will judge the migration by whether the numbers they check every Monday still hold. Rebuild the handful of reports and dashboards that leadership actually uses first, and reconcile them against Salesforce during the parallel period until pipeline value, win rates, and stage counts agree. Definitions will have shifted underneath, a HubSpot deal stage is not always a one-to-one match for a Salesforce opportunity stage, so document the differences and get sign-off on the new definitions rather than silently letting the numbers move. A report that's technically correct but doesn't match what the CRO expects will get the whole migration labeled a failure, fairly or not.

Ask what each automation and report is for, not what it looked like. Rebuild the intent, retire the workaround.

Adoption is the migration; start where risk is lowest

A perfect migration with a team still living in spreadsheets is a failed migration.

The technical cutover is finished the day the data lands and the reports reconcile. The migration is finished the day the team stops reaching for the old system and does its real work in HubSpot. Those are different dates, and the gap between them is closed by enablement, not engineering. Salesforce-native reps have muscle memory, saved views, and personal workflows built over years. HubSpot is more approachable, which helps, but "more approachable" is not the same as "already familiar." Plan role-based training that shows each team the exact daily motions they care about, a rep working a deal, a manager reading a pipeline, a marketer building a list, rather than a generic platform tour.

Recruit a few respected people from sales and marketing as early champions before go-live, give them access first, and let them shape the setup and answer peers' questions in the first weeks. Adoption spreads through trusted colleagues faster than through any training deck. Watch leading indicators in the first month, logins, deals updated in HubSpot rather than a side spreadsheet, activities logged, and treat a dip as a signal to coach, not a verdict. And decide the moment you turn Salesforce off for good. As long as the old system is one click away, some of the team will keep one foot in it, and you'll never get a clean read on adoption.

So where do you start? Start with the two chapters most teams skip: name the reason you're moving in a sentence leadership will repeat, and map the data model before touching a record. Those two decisions shape everything downstream. From there, clean in staging, cut over in phases with a real parallel period, rebuild automation and reports for how HubSpot works, and treat adoption as the actual finish line. If you want a partner who has run this specific move many times and can pressure-test your plan before you commit, a strategy call with INSIDEA is an option. As the World's #1 rated Elite HubSpot Partner serving 1,500+ businesses across 25+ countries, this is the exact work our RevOps and HubSpot teams do, and the goal is always the same: your revenue engine lands intact and your team actually switches.