Salesforce to HubSpot migration.
Leave the org without losing the history. Salesforce migrations fail on the things that have no HubSpot equivalent, not on the contacts. We map record types, formula fields, validation rules and opportunity products before anyone runs an export, and we reconcile every object against source counts before you cut over.
Twelve years of admins, and none of them left a map.
A mature org carries record types nobody can justify, formula fields feeding reports nobody owns, and Apex written by a consultant who left in 2019. The export is the easy half. Deciding what deserves to survive is the work, and it is the half that gets skipped.
The report is fine. The field behind it is a formula.
Salesforce — the carried debtThe seven things nobody warns you about.
Formula fields do not carry
They are computed at read time in Salesforce and have no direct equivalent. Each one becomes a stored property written by workflow, a calculated property, or a deliberate decision to drop it — and reports built on them break silently until it is made.
Record types have no HubSpot concept
Three record types on Opportunity usually means three pipelines, sometimes a custom object, occasionally a property. Choosing wrong is the single most expensive mistake in a Salesforce migration because everything downstream inherits it.
Opportunity products and CPQ
Line items map to HubSpot line items, but bundles, option constraints, price rules and approval steps from CPQ do not. Quoting usually has to be rebuilt rather than moved, and that has to be in the plan from week one.
Campaign influence disappears
Campaign member history and influence models are the attribution story marketing has been telling for years. HubSpot models this differently, so it is either rebuilt against the new attribution reports or preserved as historical records nobody can query.
Apex, triggers and flows
Anything enforced in code is invisible in an export. We read the org metadata to find what validation, assignment and rollup logic actually exists, because half of it is business rules nobody documented.
Person accounts
If the org runs person accounts, the contact and company model has to be rethought entirely rather than mapped. B2C orgs discover this late, usually after the first dry run.
The integrations pointed at the org
Marketing automation, billing, the data warehouse and whatever ops built in Zapier are all writing to Salesforce object IDs that are about to stop existing. Every one gets an inventory and a cutover slot.
The sequence, start to cutover.
Discovery
Object counts, custom fields, automation and the integrations that will break on the way out, read from the source system rather than from a questionnaire.
Mapping
Field by field, including what will not carry across, agreed and signed before anyone exports anything.
Dry run
A complete rehearsal into a sandbox portal, reconciled against source counts so the gaps surface a month early rather than on cutover night.
Automation rebuild
Workflows, sequences and routing rebuilt to the new model rather than transliterated from the old one, which is how a migration inherits a decade of workarounds nobody remembers writing.
Cutover
A dated switch with the legacy system read-only for a defined window, and a rollback that was tested rather than assumed.
Post-migration support
A named engineer through the first full reporting cycle, which is when the questions actually arrive.
The dry run is the migration.
Teams treat the rehearsal as a formality and the cutover as the event. It is the other way round. A complete dry run into a sandbox, reconciled object by object against source counts, is where you find the eight thousand contacts with no owner and the deal stage that maps to two different things. Cutover should be boring.
What people ask before they commit.
How long does a Salesforce to HubSpot migration take?
Typically six to twelve weeks for a mature org, driven almost entirely by how much custom logic exists rather than by how many records there are. A clean org with standard objects can move faster. We scope it in discovery and give you a date rather than a range.
Will we lose our activity history?
No. Tasks, events, emails and call logs migrate onto the matching contact, company and deal records. What needs a decision is how far back to carry them — most teams take everything, some cut at three years to keep the portal fast and the marketing contact count honest.
Can we run both systems in parallel?
For a defined window, yes, and we recommend it. Salesforce stays read-only for thirty to sixty days after cutover so anyone can go back and check a record. Two-way sync during the overlap is possible but rarely worth the complexity it adds.
What happens to our Salesforce reports and dashboards?
They get rebuilt, not moved. We inventory which reports leadership actually opens, which is always a much shorter list than the one in the org, and rebuild those against the new model before cutover so nobody loses their Monday number.
Do we need to buy HubSpot onboarding as well?
HubSpot requires onboarding at most tiers, and a partner can deliver it instead. Running the migration and the onboarding through one team means the portal is configured for your data rather than to a curriculum, and you are not explaining your business twice.
What if we want to keep Salesforce for part of the business?
Common, and fine. Some teams keep Salesforce for a regulated division or an acquired entity. That becomes an integration project rather than a migration, with the boundary drawn explicitly so the two systems never both think they own a record.
Where people go from here.
Leave the org without losing the history.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.