A Salesforce to HubSpot migration checklist only earns its place if it starts before the technical transfer does, because a straight field-by-field import drags years of accumulated clutter into the new system unfiltered. This checklist starts from the approach Equanax already publishes: work out what a Salesforce org genuinely contains before trusting what its documentation claims, then make a deliberate decision on every object and field before anything transfers.
Audit the Org Before Migrating Anything
The order matters more than any individual step on this checklist. Migrate first and clean up afterwards, and every duplicate, every abandoned field, every validation rule nobody remembers the reason for lands in HubSpot exactly as it sat in Salesforce. Cleaning up after the fact is harder, because the migration has now scattered the evidence of what each field was actually for across two systems instead of one.
Auditing the org means checking what is actually in use, not what the documentation says should be there. Pulling a live field-usage report, which fields are actually populated on recent records versus which sit empty, is a faster and more honest starting point than reading through an outdated data dictionary.
The same divergence shows up in automation, not just fields. Record-triggered Flows, any legacy workflow rules or Process Builder processes still running in older orgs, and any Apex triggers that fire on record changes need the same live-state check, because a rule that fired correctly when it was built several admins ago can easily have been quietly broken by an unrelated field rename since, and nobody noticed because the rule still runs, it just no longer does anything meaningful. Reviewing what automation actually fires on a sample of recent records, not what the rule’s own configuration claims it should do, catches this class of drift before it gets carried across as though it were still working logic.
Ownership of the audit matters as much as its scope. A migration run by whoever is available, without the person who understands why a given field or rule exists, tends to default every ambiguous case to transfer as-is, since that is the path of least resistance when nobody present can make the restructure or leave-behind call with confidence. Involving the sales or operations lead who relies on the data day to day, even briefly, on the ambiguous cases specifically, is usually enough to avoid that default.
The audit is also the point to check what personal data the org actually holds and why, since a migration is a natural moment to notice a field or record type that has drifted beyond what the business originally had a lawful basis to collect. The ICO’s guidance for organisations is worth checking against any field genuinely in doubt before it gets carried across into the new system by default.
The Three-Way Decision for Every Field
Every custom object and field needs one of three deliberate decisions, not a blanket “map everything” default. Transfer as-is applies to a field still genuinely needed that maps cleanly onto an equivalent HubSpot property. Restructure applies to a field that captures something real but whose structure was itself a workaround, commonly a picklist that grew informally over years and needs consolidating before it becomes a HubSpot property. Leave behind applies to a field nobody uses any more, often left over from a process the business no longer runs, and importing it by default just carries dead weight into the new system.
Making this decision explicitly, field by field, is slower up front than a default full-object sync, but it is the difference between a HubSpot instance that reflects how the business works and one that inherited years of Salesforce drift on day one.
Custom objects deserve a slightly different version of the same question, because a Salesforce custom object frequently exists to model a relationship HubSpot handles natively through associations, and copying the structure across verbatim produces a working but needlessly awkward result. A custom object built years ago to link a contact to multiple locations may map far more cleanly onto a HubSpot association label than onto a rebuilt replica of the original structure, so it is worth checking HubSpot’s native association and custom object capabilities before assuming a like-for-like rebuild is the only option.
Rebuilding Validation Rules
Salesforce validation rules and required-field logic do not translate automatically into HubSpot; they need to be rebuilt as HubSpot workflow and property logic, field by field, rather than assumed to carry across with the data. A validation rule that blocked a deal from closing without a signed contract field populated, for instance, has no direct HubSpot equivalent and needs an explicit property requirement or workflow check built to replicate the same business rule, not just the same field.
The practical risk of skipping this step is not that data fails to move, it is that data moves cleanly while the rule that used to protect it does not, so records start accumulating gaps Salesforce would have blocked. HubSpot’s own Salesforce import documentation covers the transfer mechanics; the validation-rule rebuild is a separate step no import tool does automatically.
The Salesforce to HubSpot Migration Checklist
| # | Check |
|---|---|
| 1 | Pull a live field-usage report rather than relying on Salesforce’s own setup documentation |
| 2 | List every custom object and mark it transfer, restructure or leave behind |
| 3 | List every custom field on standard objects and apply the same three-way decision |
| 4 | Identify every validation rule and required-field rule that needs rebuilding as HubSpot logic |
| 5 | Check for picklist values that have drifted (label versus underlying value mismatches accumulated over years) |
| 6 | Map Salesforce record types onto HubSpot pipelines and lifecycle stages, not a default one-to-one guess |
| 7 | Decide how far back historical closed-lost data actually needs to migrate, rather than importing all of it by default |
| 8 | Check for duplicate contacts and companies in the source org before they migrate and compound in the new one |
| 9 | Confirm which integrations currently write to Salesforce and need re-pointing at HubSpot before cutover |
| 10 | Decide how much activity and engagement history (emails, calls, meetings, notes, tasks) actually needs to migrate |
| 11 | Store the original Salesforce record ID as a HubSpot property on every migrated record |
| 12 | Plan a parallel-run or staged cutover window rather than a single hard switch with no rollback |
Row 5, picklist drift, is worth unpacking rather than leaving as a one-line warning. A Salesforce data export, as opposed to a report export, carries the picklist’s underlying API value rather than the label a user sees on screen, and the two frequently diverge after years of relabelling without anyone touching the API name underneath. Import that file into a property built around the current labels and HubSpot does not reject the mismatch, it adds each unrecognised API value as a new option on the property, so the field ends up carrying both the label-based options that were designed in and the API-value options the file brought with it. Nothing errors, but every workflow, list and report keyed to the original labels quietly misses whichever records landed under the new ones.
Check 8, duplicate contacts and companies in the source org, needs its own dedupe pass because Salesforce and HubSpot use different default matching logic, so a duplicate that Salesforce’s own dedupe rules were quietly catching may not be caught the same way once the data lands in HubSpot. HubSpot Contact Deduplication With n8n covers the fuzzy-match approach worth running against the migrated data as a first pass, immediately after cutover rather than waiting for duplicates to be noticed downstream.
Rows 10 and 11 both get skipped more often than they should. Activity and engagement history behaves differently from record data: high in volume, low in per-item value, and better deliberately scoped than fully migrated, since a defined window usually serves reps better than years of call notes cluttering a fresh timeline. Storing the original Salesforce record ID as a HubSpot property, on any migration not run through the native integration, costs one field and one mapping step, but without it there is no reliable way to trace a HubSpot record back to its source once the parallel-run window closes.
Check 9, integrations that currently write to Salesforce, sits outside the CRM itself and outside whoever is running the migration project, which is exactly why it gets missed. A billing system or internal script still writing to Salesforce after cutover, unnoticed, keeps updating a system nobody is watching, so records quietly diverge from HubSpot until someone goes looking and finds them stale. A full inventory of what writes to Salesforce, not just what reads from it, needs building before cutover, since an integration that only reads from Salesforce breaks visibly the day it is switched off, while one that writes to it carries on working, into the wrong system.
Common Migration Mistakes
The single most common mistake is treating the migration as primarily a technical data-transfer exercise rather than a business-process one. The data moves; the question the checklist above is built around is whether the business logic that made the old data trustworthy moves with it, and that logic lives in validation rules, automation, and the judgement calls a long-tenured admin makes without writing them down anywhere. A migration that ports the fields but not the logic behind them produces a HubSpot instance that looks complete on day one and starts accumulating the same kind of silent gaps the old Salesforce validation rules used to prevent.
A second recurring mistake is importing the full historical record set by default, rather than making a deliberate decision on how much history genuinely needs to be operationally accessible versus simply retained for reporting. Years of closed-lost deals, stale contacts, and abandoned custom object records add weight and noise to the new instance without adding value a sales team actually uses day to day, and they make every subsequent data-quality pass across the org slower simply because there is more of it to check.
A third mistake is running the migration without a rollback plan, on the assumption that a successful test import means the live cutover will go the same way. A test import against a sandbox rarely carries the exact volume, timing, and concurrent-user load of a live cutover, so keeping the Salesforce org fully intact and accessible for a defined window after cutover, rather than decommissioning it immediately, is what actually makes a rollback possible if something in the live cutover behaves differently from the test.
Cutover: Parallel Run or Hard Switch
Exporting the source data itself before cutover, independent of whatever import tool is used, is worth doing regardless of which cutover approach is chosen: Salesforce’s own data export documentation covers the scheduled export tool that produces a full backup outside the org itself, which is the rollback of last resort if a live cutover goes wrong in a way that catches both systems.
A hard switch, where the whole team moves to HubSpot on a fixed date with Salesforce turned off the same day, is faster to execute but leaves no real window to catch a mapping error or a missed validation rule before it affects live deal activity. A parallel run, where both systems stay live and in sync for a defined period, typically a few weeks scaled to the length of the sales cycle, costs more in setup and requires a temporary two-way sync layer between the systems (HubSpot Salesforce MQL Sync With n8n covers that pattern). What it buys is a genuine comparison window. If a number in HubSpot does not match the same number in Salesforce during the parallel period, that is a mapping or logic gap surfacing while it is still cheap to fix, rather than after the team has already committed to the new system as the sole source of truth.
Choosing between the two is mostly a question of what the audit turned up. An org with few custom objects, few validation rules, and a clean field-usage report can usually support a hard switch with acceptable risk. An org with extensive custom automation, the kind that took years to accumulate and real effort to rebuild faithfully, is where a parallel run earns its extra cost, because that accumulated logic is exactly what is hardest to verify has transferred correctly without a live side-by-side comparison.
Related Reading
For the full implementation side of a migration, see HubSpot Consultancy. For the strategy layer above the platform itself, see RevOps Consultancy.
Go deeper: RevOps Automation Maturity Model · HubSpot Lead Routing Automation · n8n vs Zapier for RevOps Automation
Frequently Asked Questions
Can HubSpot’s native Salesforce integration handle a full migration?
It handles the mechanical transfer of standard objects and, on the higher HubSpot tiers, custom object sync, but it does not make the transfer-restructure-leave-behind decision on your behalf. That decision, and the validation-rule rebuild that follows it, need deliberate planning before the native tooling runs.
How long does a Salesforce to HubSpot migration typically take?
The audit and field-decision work usually takes longer than the technical transfer itself, often several weeks for an org that has been live for years, since every custom object and field needs an individual decision rather than a bulk default. A smaller, cleaner org with fewer custom objects can move considerably faster.
What happens to Salesforce validation rules during migration?
Nothing happens to them automatically; they simply do not carry across, since HubSpot has no direct equivalent of a Salesforce validation rule. Each one that still matters needs to be rebuilt explicitly as a HubSpot required-property setting or workflow check, and this step is easy to miss because the data transfer itself completes successfully either way.
Should historical closed-lost deals be migrated at all?
Not automatically. Historical closed-lost data has reporting value for win-rate analysis but rarely needs to be actionable in the new system, so a common approach is migrating a defined recent window in full and archiving older records separately rather than importing years of dead pipeline into a fresh HubSpot instance on day one.