You made the call months ago. Salesforce had gotten too expensive, too complicated, or too hard for your team to actually use, so you committed to switching to HubSpot. You scoped the project, picked a cutover date, and your team spent weeks getting the data out. Now it's done. The record counts in HubSpot line up with what you exported, give or take. Everyone exhales and starts working in the new system.
Then, three weeks in, the reports stop making sense. The pipeline totals don't match what leadership saw last quarter. Deals are sitting there with no associated contacts. Marketing can't show what sourced the deals that closed before the cutover. Somewhere along the way, data got lost. Nobody can say exactly when.
Here's the thing, though. None of it got lost in transit. The export ran fine. The import ran fine. What went wrong was decided weeks earlier, in the choices nobody treated as decisions: what data to bring, what to leave behind, how to map a Salesforce structure onto a HubSpot one that works differently, and how much time to give the whole thing.
By the time anyone clicked a button, the outcome was mostly already set. That's the part most migration advice skips right over.
"Data loss" is a misleading phrase. It makes the problem sound like a transfer failure, a corrupted file, a sync that dropped half your records. So that's where teams go looking when something breaks. They check the import logs. They blame the tool.
But that's rarely what happened. What actually happened is one of three things:
The industry has a name for the first one: "lift and shift." You replicate your Salesforce setup as closely as you can, the same objects, the same fields, the same data model, and rebuild your old automations and reports to match. It feels safe because nothing gets left out. In practice, it just rebuilds the mess you were trying to escape, in a new system, on day one. You don't end up with a clean CRM. You end up with your old CRM's problems wearing a new interface.
When we see a migration described as "losing data," what's usually true is that the data was never going to survive the move intact, because the decisions that would have protected it never got made. A clean migration isn't a file transfer. It's a sequence of decisions about what your data is for. The transfer is the easy part.
Do a Google search for ‘How to move from Salesforce to HubSpot’, and you'll get the same answer almost everywhere: turn on HubSpot's native Salesforce integration, let it sync your data across, then disconnect it. Done.
It sounds clean. It's the thing we most often have to talk teams out of.
The native integration is a genuinely good tool. It's just built for a different job. It's a sync engine, designed to keep two live systems in agreement with each other over time. It is not a migration engine, and when teams repurpose it as one, the seams show fast.
When you connect it, it auto-creates its own batch of properties on the HubSpot side, and you don't get to map those before they exist. So the order of operations runs backwards: the integration creates the fields, then you remap your data to the ones you actually want, then you go delete the duplicates it made. You're cleaning up after the tool instead of directing it.
The two-way sync also keeps doing its job while it's on. So records keep getting created in Salesforce after the cutover, from a web-to-lead form still pointed at it or an integration nobody switched off, and the sync faithfully carries them into HubSpot, re-creating the very records you thought you'd left behind.
There are harder limits too. The native connector won't create net-new historical objects after the initial sync; it caps how many custom objects it'll handle, and on large databases, it runs into Salesforce API rate limits that throttle the whole thing to a crawl.
The real issue isn't that the integration is bad. It's that "sync it and disconnect" treats a one-time, high-stakes move like an ongoing background process. Those are different problems.
Now, the nuance, because this matters. If you're planning to run both systems side by side for a couple of months, the native integration is exactly right. That's what it's for. The trap is specifically using it as a migration shortcut and then severing it.
For an actual migration, purpose-built tools are a better fit. Import2 and Sync Matters, among others, let you prepare and validate your field mappings before anything goes live. You stage the whole thing, check it, and run it on your schedule rather than reacting to whatever a live sync decides to do. That control, the ability to look at exactly what's going to happen before it happens, is the entire point. It's also what the "easy button" takes away from you.
Almost every data problem on this list has the same root cause sitting upstream of it: not enough time. The timeline is the first thing a migration gets wrong, and it's the one that quietly forces all the others.
A migration has a fixed amount of careful work in it: auditing the data, mapping fields with intent, validating what landed, and training the team. That work doesn't get smaller because your calendar is tight. So when the schedule is too short, the work doesn't shrink. The attention to detail does.
The audit becomes a skim. Validation becomes a record-count glance. The sync-and-disconnect shortcut starts looking attractive precisely because it promises to skip steps. None of those skipped steps announce themselves at the time; they show up three weeks after go-live as missing data nobody can explain.
The trap is that the timeline usually gets set backwards. A team picks a go-live date first, often anchored to when the Salesforce contract lapses, then works backwards to fit the project into whatever weeks are left. That's the wrong order. The scope of the work should set the date, not the other way around.
Compressing the schedule also has a cost that most teams don't see coming. If you run short and have to ask Salesforce for more time, you're negotiating from the weakest possible position, because they already know you're on your way out.
The fix is simpler than it sounds. Give the migration itself three to four months, then plan for a stretch afterward where both systems stay live in parallel before you fully commit to the cutover. Larger or more tangled environments need more, and that's normal.
That parallel window isn't padding. It's what lets you move in phases, find problems while they're still small, and get stable before Salesforce goes dark. It's the breathing room that makes doing everything else properly possible.
When data goes missing or lands in the wrong place, it traces back to a decision that didn't get made. Here are a few of the patterns we see most often.
A migration is the one moment you have a clean reason to decide what's actually worth keeping. Most teams skip that decision and move everything, because moving everything feels safer than choosing.
It isn't. In Salesforce, the same person can exist as both a lead and a contact under the same email address, depending on your duplication rules. Those two records collapse into one when they land in HubSpot, and if you didn't plan for it, you don't find out until the counts don't match. Missing data compounds the problem: Salesforce doesn't require a domain on company records or an email on contacts, so whatever gaps existed there come across as gaps here.
The migration didn't create any of that. It just faithfully copied it and amplified whatever was already wrong.
This is the most consequential loss precisely because it's invisible at go-live. Salesforce stores the connection between a marketing touch and a closed deal across campaign member records, activities, and the object relationships underneath them. HubSpot models all of that differently.
If you map contacts across without deliberately preserving that history as HubSpot timeline activity, the touchpoints are gone. Not hidden. Gone.
Nobody notices until a few weeks later, when someone runs a marketing-sourced pipeline report for anything that closed before the migration, and the number is wrong. This is the one that's nearly impossible to reconstruct after the fact, which is exactly why it has to be a decision made before the move.
Salesforce record IDs are 15-18 character alphanumeric strings, and they're case-sensitive. That last part is the killer.
When you're matching data across spreadsheets during a manual export, with a VLOOKUP or an Excel match, those functions treat the IDs as case-agnostic by default. So two genuinely different records whose IDs differ only by case get read as the same record and silently collapse into one.
We've seen this exact thing happen on a database of roughly 80,000 contacts, where 35 pairs of genuinely different records collapsed into one because a case-insensitive match read their IDs as identical. The total record count still looked right, which is exactly why nobody caught it until later.
Real validation means spot-checking a meaningful sample of records field by field across both systems, not eyeballing the totals.
When you export a field that references another record in Salesforce, a contact's associated company, say, the value you get isn't the label you see in the interface. It's the underlying record ID. Export that company, and you don't get "Acme Corp," you get a string of characters.
If nobody catches that during mapping, you import a column of meaningless IDs where you expected names, and the associations don't rebuild the way you assumed.
Salesforce flows don't migrate, and neither do your reports; both have to be rebuilt natively in HubSpot.
Property history is a common false expectation. Salesforce only tracks history on a handful of fields to begin with, usually the important ones like opportunity stage, so the "complete history" people assume they're bringing often didn't fully exist on the Salesforce side either.
Line items are their own trap. Historical line items don't come through the native sync at all, and even when you migrate them deliberately, you have to create the products in HubSpot first, or the import fails.
If you assumed any of this would just make the trip, that's not a tool failure. It's a planning gap, and the time to find it is before go-live, not after.
In Salesforce, the link between a contact and an opportunity lives in a separate join object called Opportunity Contact Roles; it's how the buying committee on a deal gets recorded. In HubSpot, that same information lives as association labels between a contact and a deal. Because it's a different table on each side, it seldom registers as something that needs to be mapped, so it quietly evaporates.
Converted leads are a similar blind spot. In Salesforce, a converted lead is technically its own data source, and if you pull "leads" without accounting for the converted ones, you miss a chunk of your history without realizing it.
These don't disappear because the tool dropped them. They disappear because no one decided they were worth keeping, and so no one mapped them.
Every one of these is a process decision wearing a technical costume.
The work that actually prevents data loss happens before the cutover, not during it.
It's the unglamorous part. Clean the data first. Decide explicitly what's worth bringing and what gets left behind. Map your fields to how HubSpot is actually built, not how Salesforce was. Preserve your Salesforce record IDs as a property in HubSpot, so you have proof of migration and a key to validate against later. Set a downtime window, and hold the line on it.
When that groundwork is done, the cutover is almost boring, which is the goal. On one of our migrations, we told the client to stop touching Salesforce after 5 pm on a Wednesday. The run started that evening. By Thursday morning, 70% of the records were in HubSpot, and total downtime came in under 24 hours. That speed wasn't luck. It was the payoff for the mapping and validation work done in the weeks before. Slowing down up front is what makes the cutover fast.
This is the whole point, and it's not just our opinion. The teams that study failed CRM migrations keep landing in the same place: most failures trace back to planning, not to the tools. The cutover itself is the smallest part of the job. The real work is everything that comes before it: your data, your integrations, your team's readiness, and a timeline honest enough to fit all of it.
If you're leading this from a RevOps seat, the readiness check isn't "is the import tool configured." It's whether you can answer a handful of questions before you move anything.
What data actually matters to the business? What's safe to leave behind? What has to be rebuilt natively in HubSpot rather than migrated, because it won't come across at all? That last category is bigger than people expect: your reports, your automations, and every integration hanging off Salesforce, including the downstream ones feeding your ERP, your data warehouse, or your customer support tools. Who owns validation, and what does "validated" actually mean in concrete terms? Has your team even touched HubSpot before the day it goes live?
That last one decides more than people expect. A team that sees the new system for the first time on launch day spends its first weeks frustrated, hunting for deals that used to be one click away and processes that don't sit where they expect. That early impression hardens into a conclusion about the platform, and it's hard to reverse later. A technically clean migration can still be judged a failure, because whether people adopt the system is what decides if any of the work mattered.
If you can't answer those questions, the platform won't answer them for you. A tool can move data. It can't decide what your data is for.
We don't open HubSpot until we understand how the business actually works. That sounds simple, and it's the thing that separates a migration that sticks from one that gets rebuilt in six months.
Everything above points to the same conclusion: the decisions that make or break a migration happen before anything moves. That's the principle our whole process is built around.
We take a phased approach to all migrations. Discovery, design, and approval all come before we build anything. We start by mapping the existing Salesforce environment, including the custom objects and the automations nobody documented. Then we translate that architecture into HubSpot deliberately, deciding what to recreate, what to consolidate, and what to leave behind. We get agreement on that structure before a single record moves, because these are the decisions that are expensive to reverse later.
We also plan for what happens after. A migration that nobody governs erodes on its own. New fields pile up, workflows start to conflict, reporting stops being accurate, and the clean system you launched slowly turns back into the one you left. Ownership and governance aren't a post-launch nicety. They're part of the design.
When HubSpot can't model something natively, that's not the end of the road. It's where the architecture work starts. We've taken Salesforce environments built on person accounts, a structure HubSpot doesn't support out of the box, and reconfigured them into HubSpot's contact and company model, without forcing a change to how the business actually operates. The hard cases get designed around. They don't get jammed into a template.
The tool moves the data. The process decides whether it's worth moving.
Migrations don't fail in the transfer. They fail in the planning, in the decisions that didn't get made, and the corners that got cut because the clock was already against them. The teams that get this right aren't better at HubSpot than anyone else. They're just more honest about how long it takes to do it well, and they spend that time before the cutover, not cleaning up after it.
Need help planning your migration? Contact the Pros.