Most enterprise teams treat a Salesforce to HubSpot migration as a data transfer project. Move the records, map the fields, go live, done. That framing is why so many migrations require a second cleanup engagement 6 months later.
A CRM migration is not a data transfer. It is a revenue infrastructure rebuild. The decisions you make about data architecture, field mapping, and attribution configuration during the migration determine whether your HubSpot instance produces clean pipeline data from day one or spends its first year accumulating data quality debt that compounds with every new campaign you run.
This guide covers what enterprise marketing operations teams get wrong in Salesforce to HubSpot migrations and exactly how to prevent each failure. It is written for MOps leaders who are either planning a migration or mid-engagement and starting to sense that something is off.
The single most consequential migration failure is the loss of historical attribution data. Here is how it happens.
In Salesforce, campaign attribution is stored as a combination of Campaign Member records, Activity records, and Task records. The contact-to-account association that ties those activities to a pipeline opportunity lives in Salesforce's object relationship model.
HubSpot's data model is different. Contacts are associated to companies. Deals are associated to both contacts and companies. The pipeline attribution that connects a marketing touchpoint to a closed deal flows through that contact-company-deal chain.
When a migration maps Salesforce contacts to HubSpot contacts without preserving the campaign member records and activity history as HubSpot timeline events, those touchpoints disappear. The CMO's ability to show marketing-sourced pipeline contribution for any deal that closed before the migration date is gone. Not impaired. Gone.
How to prevent it: Before migration, identify every Salesforce campaign that contributed to a closed-won opportunity in the last 24 months. Map those campaign member records to HubSpot contact timeline activities. This adds time and complexity to the migration. It is non-negotiable if the CMO needs to defend marketing's pipeline contribution in a post-migration revenue review.
Every Salesforce instance that has been in production for more than 3 years has the same four data quality problems: duplicate contact records, orphaned contacts not associated to accounts, field values that reflect an old ICP rather than the current one, and custom fields that nobody uses but everybody is afraid to delete.
Migrating those problems to HubSpot does not fix them. It moves them to a new environment where they immediately degrade lead scoring accuracy, contact segmentation, list quality, and attribution completeness.
The data audit is the step that most migration timelines skip because it adds two to three weeks. Those two to three weeks pay for themselves within the first quarter of HubSpot deployment. Here is the minimum a data audit should cover.
Duplicate rate assessment. Pull a duplicate contact report from Salesforce. A healthy B2B database runs 3 to 7% duplicate rate. Enterprise Salesforce instances commonly run 15 to 25%. Migrating duplicates to HubSpot produces double-counted contacts in lists, inflated MQL numbers, and incorrect lead scoring because both records accumulate partial engagement history.
Contact-to-account association completeness. Every contact that is not associated to an account in Salesforce will arrive in HubSpot as an unassociated contact. Check the percentage. If more than 15% of your contacts are not account-associated, that is a remediation project that needs to happen in Salesforce before migration, not in HubSpot after.
Field population audit. For every custom field you plan to migrate, check the population rate. Fields with less than 30% population are usually not worth migrating as standalone properties. Either map their content to a notes field or archive the data rather than creating property clutter in the new instance.
Custom object inventory. List every custom object in Salesforce and document what it is used for, how many records it contains, and which integrations depend on it. This list determines which custom objects need to be recreated in HubSpot, which can be mapped to standard HubSpot objects, and which need to remain in Salesforce through an integration.
The most efficient migration sequence is: design the HubSpot instance architecture completely, then migrate data into it. The least efficient sequence is: migrate data first, then configure the instance around what arrived.
The instance architecture that needs to exist before migration includes these five elements.
Lifecycle stage definitions. HubSpot's default lifecycle stages need to be mapped to your actual revenue process. If your sales process uses "Discovery," "Proposal," and "Negotiation" as pipeline stages, those need to be defined as HubSpot deal stages before any opportunity data migrates.
Lead scoring model. Configure the lead scoring model in HubSpot before contacts migrate. Contacts that arrive without a score will not trigger MQL workflows. Migration is the right moment to redesign the model, not replicate a broken one.
UTM taxonomy standard. Define the UTM taxonomy that will be applied to every marketing link in HubSpot before any campaigns launch post-migration. If your Salesforce-era UTM taxonomy was inconsistent, create a new standard and apply it going forward.
Pipeline stage mapping. Map every Salesforce opportunity stage to a HubSpot deal stage. What cannot happen is migrating opportunity records into a deal stage that does not exist in the target instance.
Integration dependency map. Document every system that currently integrates with Salesforce and determine whether each integration will be rebuilt natively in HubSpot, maintained through a Salesforce-HubSpot sync during a transition period, or replaced with a HubSpot-native alternative.
The order in which records migrate matters. Companies first. Then contacts with company associations. Then open deals. Then closed-won historical deals. Then activity and campaign history.
Companies must migrate before contacts because HubSpot's association model requires the company record to exist before contacts can be properly associated to it. Reversing this sequence produces orphaned contact records that require manual remediation.
Closed-won deals from the attribution history period need to migrate in a format that preserves historical revenue data, not as active pipeline records. Activity and campaign history migration is the most technically complex step and the most important one for attribution completeness.
Before the migration goes live, run three validation checks.
Check one: Contact-to-company association rate. Pull the association rate from HubSpot and compare it to the pre-migration baseline from Salesforce. If the rate is lower, contacts migrated without their account associations.
Check two: Pipeline attribution coverage. Select five recently closed-won deals from the pre-migration period. For each deal, check whether the associated contacts have campaign and activity history visible on their HubSpot timeline.
Check three: Revenue reporting baseline. Run the marketing-sourced pipeline report in HubSpot against the 24-month window you migrated. Compare to the same report pulled from Salesforce for the same period. A large discrepancy indicates a migration gap.
Establish a daily attribution data review for the first 30 days. Pull the marketing-sourced pipeline report every morning. If the number changes overnight in a way that is not explained by new deals entering the pipeline, investigate. Early identification of data quality issues in the first 30 days costs hours. The same issues identified at 90 days cost weeks.
How long does a Salesforce to HubSpot migration take? A standard enterprise migration with a proper data audit, instance architecture design, phased data migration, integration rebuild, and validation runs 6 to 8 weeks. Migrations with significant custom object complexity or large data volumes run 10 to 12 weeks. Any timeline estimate provided before a data audit is a guess.
Should we clean data in Salesforce before migrating or in HubSpot after? In Salesforce before. Cleaning data after migration requires working in a live environment where new records are being created simultaneously. The data audit identifies what needs to be cleaned. The cleaning happens in Salesforce where the data has context and history. Then the clean data migrates.
What happens to Salesforce contacts that are not associated to accounts? They migrate to HubSpot as unassociated contacts. Unassociated contacts do not contribute to account-level engagement reporting or deal attribution. The right approach is to identify unassociated contacts in the audit phase, attempt to associate them to accounts in Salesforce before migration, and migrate only the records that cannot be associated as a flagged remediation backlog in HubSpot.
Do we need both Salesforce and HubSpot running at the same time during migration? A short parallel running period of 15 to 30 days is standard and useful for validating data integrity before decommissioning Salesforce. A parallel running period longer than 30 days creates synchronization problems. Define the parallel running period and the hard cutover date at the start of the engagement.
What is the biggest risk in a Salesforce to HubSpot migration? Loss of attribution history is the highest-consequence risk because it is not immediately visible and is very difficult to recover after the fact. Custom object complexity that was not identified in an audit is the most common cause of timeline overruns. Sales team adoption failure is the most common cause of migrations that technically succeed but produce no business value.
The Pedowitz Group is a HubSpot Platinum Partner and 3x Marketo Partner of the Year and Eloqua Partner of the Year with 19 years of B2B revenue marketing implementation experience. If you are planning a Salesforce to HubSpot migration and want to know what your specific instance requires, a migration assessment is the right starting point. Talk to TPG.