.webp?width=130&height=24&name=SuprConfig%20(2).webp){kind=small}
Book a migration call
Salted Stone Unified Salesforce and HubSpot in Under 19 Hours
View case study
At a glance
"An acquisition created two source CRMs, overlapping customer identities and one narrow freeze window. Switch turned the consolidation into a governed sequence of updates, deterministic merges, relationship-aware loads, validation checks and a final delta run. "
Industry
Customer Relationship Management (CRM) / Enterprise Software
Location
San Francisco, California, USA
The acquisition did not create a simple export-and-import exercise. It created two versions of the customer record. The Salesforce environment carried the acquirer's sales structure and activity volume. The acquired business brought a 21-year-old HubSpot portal containing companies, contacts, deals, tickets and years of engagement history.
The new HubSpot instance had to become the single operating platform without erasing the context that made either source useful. Records already introduced through selective CSV imports needed to be enriched, not recreated. Existing reference IDs had to remain stable. Calls, emails, meetings, tasks and notes had to land against the correct records with their ownership and timestamps intact.
That made the central question larger than whether 2.5 million-plus records could move. The real question was whether the destination would remain governed and usable when they arrived.
Identity before volume
Identity rules decide what Switch creates, updates, merges or skips
The destination already contained selectively imported records, so unrestricted create logic could have duplicated Companies and weakened the reference-ID policy. Switch treated the reference ID as the governing identity rather than relying on company names.
Legacy Companies were evaluated using company reference ID and potential company reference_ID. Confirmed matches were merged using an explicit precedence rule: values already present in the new portal remained authoritative, while legacy data filled blank fields. Records with a primary-key clash and a conflicting populated value were skipped for review instead of being forced into the destination.
Contact identities were resolved across primary and secondary email addresses. The controls stopped 132 potential false merges, and a side-by-side simulator exposed a possible 600-record chain merge before production approval.
Outcome: 1,282 deterministic Contact merges and zero uncontrolled Company creations.
Rebuilding connected history
Relationships determine migration order
Switch processed the migration as connected CRM data rather than independent CSV files. The Salesforce phase covered 521,978 records, including Companies, Contacts, Opportunities, activities, notes and files. The legacy HubSpot phase contributed 2,047,222 records across Companies, Contacts, Deals, Calls, Emails, Meetings, Notes, Tasks and Tickets.
Companies and Contacts were established before dependent sales and engagement records. Required Company lookups acted as a guardrail: when the relationship could not be established safely, the record did not move. Inactive owners were mapped so historical records retained their original context.
The final migration preserved approximately two million engagements with their correct links. A delta run then captured activities created after the initial Salesforce extraction so the destination did not become stale before cut-over.
A correct record count is not enough. The migrated CRM must still explain who did what, when it happened and which customer record it belongs to.
A controlled cut-over
Parallel execution shortens the freeze without hiding risk
Switch distributed the workload across parallel Node.js runners and processed atomic batches of 5,000 records. Dynamic throttling held utilisation at approximately 90% of HubSpot rate limits, while exponential back-off protected the migration when capacity tightened.
The Switch dashboard and a shared Slack channel surfaced progress in real time. Validation and difference reports were archived as CSV files, avoiding the need to introduce a separate BI or warehousing layer during migration.
Production began after automations were paused. Automated difference checks, HubSpot sign-off and smoke testing followed the load before the freeze was lifted. The production cut-over completed in 18 hours 47 minutes, and the wider freeze remained within the agreed one-week limit.
Speed came from controlled parallelism - not from removing validation steps.
Proof after launch
Validation continues after the load finishes
Fifty-five automated assertions checked non-null requirements, enumerations and dates. Fewer than 0.2% of records initially violated those rules, and every violation was corrected before launch.
The merge simulator identified risky identity combinations before production. After migration, a random 2% sample was reviewed manually and achieved 100% field parity across the inspected records.
Six tickets were raised during the first seven days after go-live. All were configuration-related rather than migration data defects. The documented field-level error rate was 0%.
A migration product should protect the operating model around the data
Acquisition-driven consolidation exposes the limits of row-based migration. The same company can exist in multiple systems. Historic interactions can outnumber core CRM records. A fast load can still leave the destination fragmented if identity, ownership and associations are treated as cleanup tasks.
Switch made those concerns part of the migration workflow. Identity rules controlled record behaviour. Dependency-aware phases rebuilt connected history. Parallel runners compressed cut-over while rate-aware controls protected execution. Validation proved the result before and after launch.
The result was not simply a populated HubSpot portal. It was one governed CRM that the business could use on its first day after cut-over.