Every Salesforce to HubSpot migration I have seen fail has failed for one of eight reasons. None of them are technology failures. Every single one is a planning failure, a scoping failure, or an alignment failure that was visible before the migration started and was ignored in the interest of timeline or budget.
This is the list. Each failure mode has a cause, a consequence, and a prevention. If you are planning a migration and you recognize your current plan in any of these descriptions, stop and fix the problem before you start moving data.
What happens: The project starts with field mapping in HubSpot before anyone has pulled a data quality report from Salesforce. The migration executes on a timeline. Data arrives in HubSpot. Six weeks later the marketing team discovers that 23% of their contacts have no company association, lead scoring is producing unexpected MQL volumes, and the pipeline attribution report is showing numbers that do not match what the CMO remembers from Salesforce.
Why it happens: The data audit adds two to three weeks to the timeline. Most migration projects are already under schedule pressure before they start. The audit gets deprioritized as "nice to have" and dropped.
The consequence: Post-migration remediation. Deduplication, contact re-association, and lead score recalibration in a live HubSpot environment where new data is arriving daily. The remediation takes longer than the audit would have. It also runs the risk of creating new data quality issues while fixing the original ones.
The prevention: Make the data audit non-negotiable. Budget two weeks for it. Audit duplicate rate, contact-to-account association completeness, custom field population, and custom object inventory before writing a single HubSpot property name.
What happens: The data audit was completed and the team knows there are 18% duplicate contacts, 12% of contacts without account associations, and several thousand records with field values that reflect an ICP from four years ago. The decision is made to migrate anyway and clean the data in HubSpot "once we are settled in."
Why it happens: Cleaning data in Salesforce feels like a separate project. The migration timeline is already tight. The assumption is that it is easier to clean in the new system.
The consequence: It is not easier to clean in the new system. HubSpot's deduplication tools work differently from Salesforce's. Contacts that need to be merged have already accumulated new HubSpot engagement history that complicates the merge. The "once we are settled in" clean-up stretches to 12 months and is never fully completed.
The prevention: Clean data before you migrate it. The sequence is: audit, clean, migrate. Not: audit, migrate, clean. Every data quality problem that enters HubSpot compounds in the new environment.
What happens: The migration moves all contacts, accounts, opportunities, and activities. But the Salesforce campaign member records, which document which contacts responded to which marketing campaigns, are not migrated as HubSpot timeline events because that step was scoped out of the engagement to reduce cost and timeline.
Why it happens: Attribution history migration is technically complex. It requires mapping Salesforce campaign member records to HubSpot contact timeline events with the correct timestamps, campaign names, and response types. It adds time and cost to the migration scope. It is frequently descoped as a post-migration enhancement.
The consequence: The CMO cannot produce a marketing-sourced pipeline report that covers deals closed before the migration date. Marketing's pipeline contribution for the past 12 to 24 months is invisible. In a CFO conversation about marketing's budget justification, that is a significant problem.
The prevention: Include attribution history migration in the original scope. Define the attribution history period (typically 24 months), identify the campaign records that cover that period, and migrate them as timeline events. Do not treat this as optional.
What happens: The Salesforce instance has a lead scoring model that has been running for three years. Nobody is sure exactly how it works anymore because the person who built it left 18 months ago. The decision is made to replicate it in HubSpot exactly as it exists in Salesforce because changing it during a migration is considered too risky.
Why it happens: Migrations create enough change for organizations to manage. Changing the lead scoring model simultaneously feels like piling change on top of change. Replication is the path of least resistance.
The consequence: The new HubSpot instance inherits a lead scoring model that was probably never properly validated against closed-won data and has certainly not been updated to reflect the current ICP. MQL quality in HubSpot is the same as or worse than MQL quality in Salesforce, which means the sales team's frustration with lead quality transfers to the new platform along with the data.
The prevention: Validate the lead scoring model against closed-won data before migration. Pull the last 50 closed-won deals and check the lead score of the primary contact at the time of MQL conversion. If the scores are not concentrated in the top scoring tiers, the model is not reflecting actual buying signals. Fix it before replicating it.
What happens: The migration focuses on the Salesforce-to-HubSpot data transfer. The question of what happens to the 6 other systems integrated with Salesforce (the marketing data warehouse, the CPQ tool, the customer success platform, the sales engagement tool, the data enrichment vendor, and the business intelligence platform) is deferred until after go-live.
Why it happens: Integration architecture is complex and involves stakeholders outside the marketing and sales teams. It is easier to defer than to resolve before the migration.
The consequence: Go-live happens and within 72 hours the sales team realizes their CPQ tool is no longer writing closed deal data to the CRM. The marketing data warehouse is not receiving HubSpot event data. The customer success platform has lost its contact sync. Each integration requires its own remediation engagement. The migration has technically succeeded but the business is operating with disconnected systems for weeks to months post-go-live.
The prevention: Map every Salesforce integration before migration begins. Make an architecture decision for each one before the migration goes live. Not after.
What happens: Migration planning focuses on the technical execution: data, fields, workflows, integrations. Sales team training is scheduled for week two or three after go-live because the team is too busy during the migration build. Go-live happens. The sales team opens HubSpot, cannot find what they are looking for, logs back into Salesforce, and continues working there for the next six weeks while the project team tries to force adoption.
Why it happens: Training is easy to defer. It does not block the technical migration. It is treated as a parallel track that can happen any time.
The consequence: Adoption failure. The technical migration succeeds but the business outcome does not materialize because the sales team is not using the new platform. In the worst cases, data quality in HubSpot degrades during the adoption delay as the team logs some activities in HubSpot and some in Salesforce.
The prevention: Train the sales team before go-live. Schedule training in the final week of the migration build. Make it role-specific: what does a sales rep do in HubSpot every day, how do they log activities, how do they manage their pipeline, how do they read the reports that were previously in Salesforce. Go-live should not be the first time the sales team opens HubSpot.
What happens: Go-live arrives. The project team and sales leadership agree that they will run both Salesforce and HubSpot in parallel "for a month" to make sure everything works before decommissioning Salesforce. The month passes. Someone asks about decommissioning Salesforce and is told the team is not comfortable yet. Three months pass. Six months pass. Both systems are being maintained at full Salesforce licensing cost while the HubSpot investment is not producing its intended ROI.
Why it happens: There is no defined cutover criteria. The parallel running period has a soft end condition ("when everyone is comfortable") rather than a hard one ("when X, Y, and Z validation criteria are met").
The consequence: Double the infrastructure cost for an indefinite period. Data divergence between the two systems as each accumulates activity that is not synchronized. Ongoing confusion about which system is the authoritative source of record. The migration investment is not recovered because the team is still operating in Salesforce.
The prevention: Define cutover criteria at the start of the engagement. Specific, measurable criteria that, when met, trigger Salesforce decommission. Typical criteria include: all active deals migrated and verified, all integrations live and tested, sales team training completed, and the post-migration attribution report validated. Set a hard cutover date. Hold to it.
What happens: The migration goes live. The project team closes the engagement. Everyone moves on. Three weeks later the marketing team notices that the marketing-sourced pipeline number in HubSpot has been declining unexpectedly. Investigation reveals that a workflow built during the migration phase is triggering on historical contact records and reassigning lifecycle stages incorrectly, which is removing contacts from pipeline attribution calculations.
Why it happens: Post-go-live monitoring is not scoped into the migration engagement. The assumption is that if the validation protocol passed, the system is working correctly.
The consequence: Data quality issues that develop in the first 30 days of operation accumulate undetected. The longer they run, the harder the remediation. Issues that are caught at day 7 cost hours. The same issues caught at day 45 cost days.
The prevention: Establish a daily attribution data review for the first 30 days post-go-live. Assign a named owner who pulls the marketing-sourced pipeline report every morning and investigates any unexpected changes. Document a 30-day hypercare period in the migration SOW with specific monitoring responsibilities.
Which of these eight failures is most common? In TPG's experience, failure 3 (not preserving attribution history) and failure 7 (indefinite parallel running period) are the most frequent. Attribution history migration is the step most often descoped to reduce cost. Indefinite parallel running is the outcome most often produced by migrations that did not define cutover criteria. Both are fully preventable with proper scoping.
Can a migration be recovered if one of these failures has already occurred? Yes, but the recovery cost is proportional to how long the issue has been running. Attribution history that was not migrated can be reconstructed from Salesforce data, but the effort increases significantly if Salesforce has already been decommissioned. Data quality issues in HubSpot can be remediated but take longer in a live environment. The earlier a failure is identified, the less expensive the recovery.
What is the most expensive migration failure to recover from? Loss of attribution history after Salesforce decommission, combined with an extended period of dirty data accumulation in HubSpot. Recovering clean historical attribution data after both the source system and the window for clean migration have closed requires either manual data reconstruction from backup files or accepting a permanent gap in attribution history.
The Pedowitz Group has been implementing HubSpot and Salesforce at enterprise scale since 2007. We have seen all eight of these failures. Our migration methodology is built specifically to prevent them. Talk to TPG about your migration.