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.
What happens: The project starts with field mapping in HubSpot before anyone has pulled a data quality report from Salesforce. Six weeks later the marketing team discovers that 23% of contacts have no company association, lead scoring is producing unexpected MQL volumes, and the pipeline attribution report shows numbers that do not match 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 consequence: Post-migration remediation in a live environment where new data is arriving daily. The remediation takes longer than the audit would have.
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 revealed 18% duplicate contacts, 12% of contacts without account associations, and records with outdated ICP field values. 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 assumption is that it is easier to clean in the new system.
The consequence: It is not easier to clean in the new system. Contacts that need to be merged have already accumulated new HubSpot engagement history that complicates the merge. The clean-up stretches to 12 months and is never fully completed.
The prevention: Clean data before you migrate it. Audit, clean, migrate. Not audit, migrate, clean.
What happens: The migration moves all contacts, accounts, opportunities, and activities. But the Salesforce campaign member records 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 and adds time and cost. 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.
The prevention: Include attribution history migration in the original scope. Define the attribution history period, identify the campaign records that cover it, 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. The decision is made to replicate it in HubSpot exactly as it exists because changing it during a migration is considered too risky.
Why it happens: Migrations create enough change for organizations to manage. 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. MQL quality in HubSpot is the same as or worse than in Salesforce.
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. Fix the model before replicating it.
What happens: The migration focuses on the Salesforce-to-HubSpot data transfer. The question of what happens to the six other systems integrated with Salesforce is deferred until after go-live.
Why it happens: Integration architecture is complex and involves stakeholders outside marketing and sales. It is easier to defer than to resolve before 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. Each integration requires its own remediation engagement.
The prevention: Map every Salesforce integration before migration begins. Make an architecture decision for each one before the migration goes live.
What happens: 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, and logs back into Salesforce for the next six weeks.
Why it happens: Training is easy to defer. It does not block the technical migration.
The consequence: Adoption failure. 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. Make training role-specific. Go-live should not be the first time the sales team opens HubSpot.
What happens: Go-live arrives. The teams agree to run both systems in parallel "for a month." The month passes. Three months pass. Six months pass. Both systems are being maintained at full Salesforce licensing cost.
Why it happens: There is no defined cutover criteria. The parallel running period has a soft end condition rather than a hard one.
The consequence: Double the infrastructure cost for an indefinite period. Data divergence between two systems. Ongoing confusion about which system is the authoritative source of record.
The prevention: Define cutover criteria at the start of the engagement. Set a hard cutover date. Hold to it.
What happens: The migration goes live. The project team closes the engagement. Three weeks later the marketing-sourced pipeline number has been declining unexpectedly. A workflow built during migration is triggering on historical contact records and removing contacts from pipeline attribution calculations.
Why it happens: Post-go-live monitoring is not scoped into the engagement.
The consequence: Data quality issues accumulate undetected. Issues 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. Document a 30-day hypercare period in the migration SOW with specific monitoring responsibilities.
Which of these eight failures is most common? Failure 3 (not preserving attribution history) and failure 7 (indefinite parallel running period) are the most frequent. 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. 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. 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 is a HubSpot Platinum Partner and 3x Marketo Partner of the Year and Eloqua Partner of the Year. Our migration methodology is built specifically to prevent these eight failures. Talk to TPG about your migration.