A financial services firm can migrate from Salesforce to HubSpot without losing compliance history, activities, or client relationships, but only if the move is handled as a governed redesign rather than a bulk export/import. The safest approach is to separate what must be preserved for record retention, what should be rebuilt in HubSpot, what should be archived outside the active CRM, and what should stay hybrid for a period after go-live. For most 25–200 employee firms, the highest-risk failure points are relationship mapping, activity retention, workflow rebuilds, and cutover timing rather than the field import itself.
Key takeaways
- You should not migrate everything into live HubSpot just because it exists in Salesforce; regulated firms need a preserve, redesign, archive, or retire decision for each object and process.
- Compliance history and books-and-records obligations should be reviewed against requirements such as SEC Rule 17a-4 and FINRA Rule 4511 before cutover, not after.
- Advisor-client relationships, householding, borrower and co-borrower links, and ownership rules need explicit mapping and post-load validation or trust in the new system collapses fast.
- Salesforce workflow rules, Process Builder logic, Apex triggers, and custom objects rarely translate one-to-one into HubSpot and usually need redesign.
- A short parallel run is often the safest option when supervision, retention, or downstream reporting still depends on Salesforce during transition.
What does “not losing compliance history or client relationships” actually mean?
Compliance history is the record of communications, activities, approvals, ownership changes, and stored business records that a regulated firm may need to retain, supervise, or reproduce. Client relationships are the links between people, households, companies, advisors, borrowers, co-borrowers, policies, loans, opportunities, and service interactions that tell your team who is connected to whom and why.
In practice, “not losing data” is too vague to manage. A 45-person independent wealth management firm does not just need contact records. It needs household relationships, advisor ownership, notes, tasks, meeting history, email context, segmentation logic, and a defensible answer to where the official retained record lives after migration.
What should you preserve, redesign, archive, or retire before a Salesforce-to-HubSpot migration?
| CRM element | Typical Salesforce example | Recommended HubSpot treatment | Compliance risk if mishandled | Validation check before go-live |
|---|---|---|---|---|
| Leads and contacts | Salesforce Leads, Contacts, duplicate person records | Define whether Leads become contacts, deals, or both; deduplicate before import | Duplicate outreach, broken attribution, advisor confusion | Check duplicate rate, owner mapping, and lifecycle stage logic |
| Households and accounts | Financial Services Cloud households or custom account structures | Rebuild with HubSpot companies, associations, or custom objects if needed | Broken family or account relationships, incorrect service coverage | Verify one-to-many and many-to-many associations on sample records |
| Opportunities | Opportunities by product line, branch, or advisor | Map to HubSpot deals with a cleaned pipeline model | Reporting breaks and revenue history misreads | Compare stage counts, amounts, owners, and close dates pre/post migration |
| Activity history | Calls, tasks, meetings, logged activities | Import what users need operationally; archive what must be retained but not worked daily | Incomplete client file, lost service context | Confirm activity volumes and date ranges on sampled records |
| Notes | Advisor notes, servicing notes, underwriting notes | Preserve with source stamps and original dates where possible | Loss of business rationale and audit context | Review note counts, timestamps, and association accuracy |
| Email history | Salesforce activity capture, synced emails | Decide whether HubSpot needs historical visibility or only forward-sync behavior | Supervision gaps and missing communication context | Validate storage location, access rules, and retained sample threads |
| Custom fields | Risk score, product eligibility, branch code, NMLS fields | Keep only fields used for reporting, routing, compliance, or automation | Broken workflows and hidden reporting errors | Check field definitions, picklist values, and required-field behavior |
| Automations | Workflow Rules, Process Builder, Apex triggers | Redesign in HubSpot workflows; do not attempt blind parity | Missed handoffs, missed reviews, incorrect notifications | Test every trigger, delay, owner assignment, and exception path |
| Reports | Advisor production dashboards, branch scorecards | Rebuild only the reports used for management decisions | Leadership loses continuity and confidence | Reconcile KPI definitions before publishing dashboards |
| Integrations | DocuSign, Encompass, Formstack, Outlook, compliance archive | Inventory, rank by criticality, and sequence reconnects | Data drift and process failures after cutover | Run end-to-end tests for create, update, and sync behavior |
How should a financial services firm sequence the migration?
- Run a pre-migration audit. Inventory Salesforce Sales Cloud or Financial Services Cloud objects, fields, automations, reports, integrations, users, and data quality issues. This is where you identify which records are system-of-record, which are convenience history, and which should be retired.
- Define the target operating model. Decide how HubSpot Sales Hub, Service Hub, and Operations Hub will support marketing, sales, onboarding, servicing, and compliance review. If you skip this step, you recreate Salesforce clutter in a different interface.
- Map objects and relationships. Data mapping is the field-by-field and object-by-object plan for how source data lands in the target system. For a regional mortgage lender, that includes borrower and co-borrower relationships, loan-stage logic, branch ownership, and marketing handoff rules.
- Review retention and supervision requirements. SEC Rule 17a-4 governs preservation of certain electronic records for broker-dealers, and FINRA Rule 4511 covers general books-and-records obligations. Your migration plan needs a written answer to which system holds the retained record, how long it is retained, and how it can be reproduced.
- Clean before you load. Fix duplicates, inactive owners, dead picklist values, obsolete fields, and broken workflows in advance. Migration is the cheapest point to reduce duplicate contact rates, dead automation branches, and unused reports.
- Run a pilot migration. Use a representative data slice: one branch, one advisor team, or one product line. A good pilot proves associations, activity visibility, workflow behavior, permissions, and reporting logic before you touch the full population.
- Use a parallel run where risk justifies it. A parallel run is a period where Salesforce and HubSpot operate together while outputs are compared. For compliance-sensitive firms, this is often the difference between a calm cutover and a scramble.
- Validate before go-live. Count records, compare key fields, test relationships, and spot-check real client files. Do not accept “import completed” as evidence that the migration worked.
- Cut over in a controlled window. Freeze risky admin changes, communicate ownership changes, monitor sync behavior, and assign named owners for issue triage during the first week.
How do Salesforce objects usually map into HubSpot for financial services firms?
Salesforce Leads, Accounts, Contacts, and Opportunities do not always map neatly into HubSpot contacts, companies, and deals because financial services teams often use custom relationship models. Salesforce Financial Services Cloud adds another layer with householding and relationship constructs that may require custom objects or carefully designed associations in HubSpot.
In most migrations we see at Illumination Labs, the highest-friction decision is not field mapping. It is deciding whether the Salesforce Lead should remain a distinct pre-client object, collapse into a HubSpot contact, or become a combination of contact plus lifecycle stage plus deal. If that choice is wrong, routing, reporting, and ownership logic all break downstream.
A 70-person mortgage lender, for example, may need one person record linked to multiple opportunities across refinance, purchase, and servicing workflows. A 35-person insurance brokerage may need a contact linked to a household, an employer, several policies, and a producer-owner relationship. Those links need to be designed first and migrated second.
Can you preserve activities, notes, emails, and call history when moving from Salesforce to HubSpot?
Yes, but you should separate operational history from retention history. Operational history is what advisors and service teams need inside HubSpot to do their jobs. Retention history is what compliance may need preserved and reproducible even if it does not need to clutter the day-to-day CRM view.
This is where many migrations go wrong. Teams try to force every historical email, task, and call into the active CRM and then discover the result is noisy, slow to validate, and hard to trust. A better design is to preserve required retained records in the appropriate archive or supervised system, import the activity history that supports active servicing and sales context, and document the boundary between them.
What usually breaks when firms try to copy Salesforce logic exactly into HubSpot?
Workflow rules, Process Builder flows, Apex triggers, custom validations, and report formulas usually break because HubSpot is not a one-for-one clone of Salesforce. HubSpot can handle a large amount of SMB and mid-market workflow logic, but the architecture is different and should be simplified during migration.
Use the People, Process, Tech, and Data lens here. People: advisor ownership and exception handling need to stay clear. Process: supervision, approvals, and handoffs need documented states. Tech: integrations and automation logic need rebuilding, not copying. Data: field definitions, deduplication rules, and relationship models need cleanup before import.
If you skip that redesign, you get a cleaner interface with the same broken operating model underneath. That is how firms move from L2 The Vision to L3 The Plateau without ever reaching a governable engine.
When should a firm run Salesforce and HubSpot in parallel before cutover?
You should plan a parallel run when one or more of the following is true: compliance review still depends on Salesforce outputs, downstream integrations cannot be swapped in one window, leadership reporting needs reconciliation, or advisor teams need confidence that relationship visibility is intact.
For regulated firms, a short parallel state is usually safer than a hard switch with no fallback. The goal is not to live in two CRMs forever. The goal is to compare record counts, owner assignments, pipeline movement, workflow outcomes, and retained-history access while real work is still happening. If those comparisons fail, you fix the model before full cutover.
When should a financial services firm not migrate yet?
You should not migrate yet if you cannot answer four questions clearly: what records are subject to retention, where the post-migration system of record will be, how advisor-client and household relationships will map, and which automations actually drive revenue or compliance outcomes. If those answers are fuzzy, the migration becomes a platform swap without operational control.
We see this most often in firms sitting between L1 The Fog and L2 The Vision. They know Salesforce is messy, but they have not documented the workflows and data rules that matter. In that case, the right move is a pre-migration operating model and data governance project first, then migration.
Frequently asked questions
What data usually gets lost in a Salesforce-to-HubSpot migration?
The most common losses are not core fields like name, email, or deal amount. They are relationship links, inactive custom fields that still power reports, workflow logic hidden in Process Builder or Apex, and historical activities that were assumed to be available but were never mapped or imported.
Can you preserve activities, notes, emails, and call history when moving from Salesforce to HubSpot?
Yes, but you need a written rule for what belongs in live HubSpot versus what stays in a retention archive or supervised record system. Preserve what users need for active servicing and selling, and separately preserve what compliance needs to retain and reproduce.
How should Salesforce Leads map into HubSpot?
There is no universal answer. For many SMB financial services firms, Salesforce Leads become HubSpot contacts governed by lifecycle stages and deal creation rules, but some firms still need a more distinct pre-client qualification process. The right answer depends on routing, reporting, and compliance review requirements.
What happens to custom objects and custom fields during a Salesforce-to-HubSpot migration?
Some map cleanly into HubSpot custom objects or custom properties, and some should be retired. Keep custom structures only when they support a real process, relationship model, report, or compliance obligation. Migration is the best time to eliminate fields no one uses.
How do financial services firms handle compliance and record retention during CRM migration?
They start with the retention requirement, not the import tool. Rules such as SEC Rule 17a-4 and FINRA Rule 4511 shape what must be preserved, how records are stored, and how they can be reproduced. That review should happen before any cutover date is approved.
Should you run Salesforce and HubSpot in parallel before cutover?
Usually yes when regulated workflows, reporting continuity, or key integrations create operational risk. A short parallel run lets you compare outputs, validate relationships, and confirm that compliance-sensitive processes still work before Salesforce is fully retired.
How long does a Salesforce-to-HubSpot migration take for a 25–200 employee firm?
A straightforward migration with limited custom objects and a small integration footprint can take roughly 8–12 weeks. A more complex financial services migration with relationship redesign, compliance review, workflow rebuilds, and phased cutover often takes 12–20 weeks because validation and parallel-state work add time.
How do you validate record relationships after migration?
Use record counts, field-level reconciliation, and sampled client-file reviews. For financial services firms, validate households, advisor ownership, borrower and co-borrower links, company associations, and open opportunity relationships on a representative sample before go-live. If the relationship model fails on sample records, do not proceed to full cutover.