Salesforce to HubSpot Migration: How To Get It Right First Time

You know the migration is overdue when adding a field to Salesforce needs a developer and a ticket, and your reps have started not logging deals because the system is too slow to bother with.

A Salesforce to HubSpot migration in the UK typically takes 6 to 10 weeks and costs £5,000 to £40,000+, depending on data volume, integrations, and how much has piled up in the org over the years.

The number is not what decides whether it works. The best migrations treat the move as a redesign that happens to end in a data transfer, not a data transfer with a redesign bolted on.

Done that way, this is the one moment you get to fix years of accumulated CRM drift, with sign-off, and land on a system the team actually wants to use.

This guide covers the cost, the timeline, the order records move in, and how to do all of it well.

How much does a Salesforce to HubSpot migration cost in the UK?

It is a one-off project cost, separate from your HubSpot licence, and the range is wide because no two migrations are the same job.

A clean CRM with a few thousand contacts and no custom objects is one afternoon's worry. A long-lived org with custom objects, Apex code, and six integrations is a different animal.

The bands below reflect typical UK market pricing for partner-led migrations.

These are project figures, not retainers. They do not include your HubSpot subscription, third-party tool costs, or your team's internal time. Those sit below.

What about the cheap end: DIY migration tools?

If your migration is genuinely simple, the tooling cost alone can be under £200. Third-party migration tools price by how much they do for you: self-service data movers start around £150, an assisted tier with a success manager runs to roughly £500 to £600, and a fully managed tool migration starts around £1,600 to £2,500.

HubSpot's own Smart Transfer is free. But all these tools do one thing. They move records. They do not redesign your pipeline, rebuild your automations, or reconnect your integrations, so they answer the cost question only for the simplest jobs.

Everything above "simple" in the table is a services cost, not a tooling cost.

What drives a migration cost up or down?

Five variables move the number more than anything else. Work out which ones apply to you and a vague quote turns into a real one.

• Data volume and quality. Raw record count matters less than how dirty the data is. A database full of duplicates, dead contacts, and inconsistent field values takes longer to migrate than a larger but cleaner one, because the cleanup is the work. With B2B contact data decaying at around 22% a year on the consensus benchmark, an org that has not had a serious clean in three or four years can be carrying 30 to 40% dead weight before anyone exports a record.
• Custom objects and code. Standard Salesforce objects (Contacts, Companies, Deals) map cleanly to HubSpot. Custom objects, Apex triggers, and Flow automations do not. Each one has to be redesigned in HubSpot's model, not copied.
• Integrations. Every connected system (ERP, marketing tools, billing, data enrichment) is a separate reconnection job. This is the line teams underestimate most, and the integration work is often as involved as the core data move.
• Pipeline and process redesign. Migrate your existing pipeline stages and field structure unchanged and the project is cheaper, and you have wasted it. More on this below.
• Historical activity. Bringing across years of emails, calls, and notes tied to records is possible, and it adds scope. Deciding how much history you actually need is a cost lever most teams do not realise they hold.

Before you migrate: the decision that determines success

The most important migration decision is what NOT to bring. A migration is the one moment you get to fix a CRM that has drifted for years, with sign-off, in daylight. Treat it as a lift-and-shift, move everything exactly as it sits, and you rebuild the old mess in a new platform at full price.

Here is why that one decision carries the project. Salesforce orgs accumulate. Custom fields nobody fills in. Pipeline stages that mean one thing to one rep and something else to the next. Automations built for a process that changed two reorganisations ago.

The teams who get this right use the migration to leave all of that behind. Copy the structure across unchanged and you keep it, in a more expensive platform, and the team that resented the old CRM resents the new one inside a month, for the same reasons.

You cannot automate what was never designed. Before any data moves, three things need deciding: what your pipeline stages actually mean and who agrees, which fields are real and which are noise, and what a qualified lead is in concrete terms. Migration is the forcing function that gets those decisions made. Skip it and you are paying migration prices for a copy-paste.

Agree your system of record before you touch a tool

One decision sits above all the technical ones: which system is the source of truth, and from when. We have watched migrations that started on a renewal deadline get rebuilt mid-flight, because nobody got sales, marketing, and leadership to agree that HubSpot was the system of record before the build began, and then someone senior objected in week seven.

If half the company still treats Salesforce as truth after go-live, adoption never happens and you are paying for two systems. Run one short alignment session with sales, marketing, ops, and finance, and decide the system of record for each object (contacts, deals, accounts) before anything is configured.

If you cannot reach agreement in that session, you are not ready to migrate. You are ready to align, and that is a cheaper problem to fix now than in week seven.

What actually moves: data and assets are two different jobs

A Salesforce to HubSpot migration is two projects, not one, and the teams that scope it well treat them as two from the start.

The first is the data: contacts, companies, and deals. The second is the assets: the users, properties, lists, automations, reports, campaigns, and email templates that make the CRM do anything.

The data can be moved in days. The assets have to be rebuilt, because they do not export, and that rebuild is most of the project.

It helps to know what each Salesforce object becomes in HubSpot before you start, because the names change and the data model is simpler.

The one that catches teams out is the collapse of Salesforce's separate Lead and Contact objects into HubSpot's single Contact object. That is the duplicate-records risk covered below.

There are two ways to move each thing: migrate it or translate it. Migrating copies it across as it sits. Translating reshapes it to fit HubSpot's model on the way in.

The lift-and-shift trap is just migrating everything when you should be translating it, and the whole case for designing before you configure is a case for translation over straight migration.

The pre-migration data audit: where good migrations start

Before any record moves, audit what you actually have. This is the step most timelines cut to save two or three weeks, and it is the step that pays those weeks back inside the first quarter on HubSpot.

Moving dirty data does not fix it. It relocates the problem to a system where it is harder to find and more expensive to untangle, and where it immediately degrades lead scoring, segmentation, and reporting.

A clean audit covers four things, each with a number you can act on.

• Duplicate rate. Pull a duplicate-contact report from Salesforce. A healthy B2B database keeps duplicates under about 5%. Long-lived Salesforce instances commonly run 10 to 30%. This is not cosmetic: one GTM benchmark found databases with duplicate rates above 15% overstate pipeline by around 30%, because each copy accumulates half the engagement history and every report double-counts. Migrate the duplicates and you import the inflated numbers along with them.
• Account-association completeness. Every Salesforce contact not linked to an account arrives in HubSpot as an unassociated contact, invisible to account-level reporting and deal attribution. If more than about 15% of contacts are unassociated, that is a remediation job to do in Salesforce before migration, not in HubSpot after.
• Field population. For every custom field you plan to bring, check how full it is. Fields populated on less than roughly 30% of records are usually not worth migrating as standalone properties. Map their content to a notes field or archive it, rather than recreating clutter. An audit like this usually strips out a large share of custom fields, often 40 to 60%, and the result is an instance people can actually navigate.
• Inactive records. Anything untouched for 18 to 24 months is a candidate to archive, not migrate. Dead records inflate your HubSpot contact tier (which is what you pay for in Marketing Hub) and pollute segmentation. Decide before you move, because it is far harder to unpick after.

The output of the audit is a documented field-mapping plan and a go or no-go on what moves. That document becomes the project's source of truth, and the thing that stops surprises in week seven.

The migration timeline, phase by phase

A standard Salesforce to HubSpot migration runs 6 to 10 weeks across five phases. The data move itself is the shortest phase. The design and validation either side of it are where the time goes, and where the project succeeds or fails.

You will see longer figures quoted elsewhere, often 3 to 6 months for a mid-sized business. Both are right; they are measuring different things. The 6 to 10 weeks is the core CRM migration: the data, the build, and go-live. The 3 to 6 months includes the full marketing-asset rebuild, integration work across the wider stack, and the adoption period where the team actually changes how it works. Scope the project on the longer number and resource it on the shorter one.

Phase 1: Audit and design (1–3 weeks)

Audit the data (above), map what is in Salesforce, and decide what HubSpot should look like. This covers the object model, the pipeline redesign, field rationalisation, lead-scoring design, and a list of every integration and automation to rebuild. Owner: the partner, with your RevOps or sales-ops lead. The temptation is to rush this to get to the build. The good migrations resist it, because every hour spent here saves several in rework later.

Phase 2: Build and configure (2–4 weeks)

Build the HubSpot instance to the design before any production data lands: properties, pipelines, lifecycle stages, lead-scoring model, automations, user permissions, and templates. Design the instance first, then migrate into it. The reverse order, migrating data and configuring around what arrived, is the least efficient way to do it, and it produces pipeline reports nobody recognises. Owner: the partner. The discipline that separates a strong build from a mediocre one is building to the agreed new design, not to mirror Salesforce.

Phase 3: Data migration in sequence (1–2 weeks)

The order records move in is not optional, because HubSpot's association model depends on it. Run a test load of roughly 10% of real production data first, validate it, then run the production load in this sequence:

1. Companies first. HubSpot needs the company record to exist before contacts can associate to it. Reverse this and you get orphaned contacts that need fixing by hand.
2. Contacts, with their company association intact. Validate that the contact-to-company association rate after import matches the rate you measured in Salesforce. Anything that arrives unassociated gets flagged before you go on.
3. Open deals, preserving contact and company associations. Every deal needs at least one associated contact and one company, or it cannot appear in pipeline attribution.
4. Closed-won history for the attribution window you set in the audit (typically the last 24 months).
5. Activity and campaign history as timeline events on the right records. This is the most technically involved step and the one that protects your attribution.

Deduplicate on the way in, using a defined rule (email match, or company-plus-name) agreed before you start, including what happens to the losing record's activity. Owner: the partner. The test load is what makes this phase boring, which is exactly what you want: field-mapping errors surface in the 10% sample, not in production.

Phase 4: Integrations and validation (1–3 weeks)

Reconnect integrations, rebuild reports and dashboards, and validate that records, associations, automations, and attribution all behave. Validation is concrete work, not a glance. Run sample contacts with different property combinations through every workflow to confirm they trigger and route correctly, push test records through the lead-scoring model to confirm qualified leads surface, and send a live test from each email and sequence to check delivery, formatting, and personalisation. Owner: shared. Plan for integrations to need a second pass, because they rarely reconnect cleanly first time, and the teams that budget for that are the ones that still go live on schedule.

Phase 5: Go-live and the first 30 days (1–2 weeks, then 30 days of hypercare)

Back up your Salesforce instance before you cut over, schedule the cutover for a slow period or weekend, and run a final sync immediately before so nothing created in the last days is lost. Then cut over, keep Salesforce read-only for a defined parallel period (15 to 30 days, no longer, or the two systems diverge), and treat the next 30 days as the actual project, not the victory lap.

Go-live is where most data issues surface, because validated static data now meets live activity, real data entry, and workflow logic. Build a 30-day ongoing quality check plan before you cut over: daily stand-ups for the first two weeks, a per-rep adoption dashboard (who is logging in, updating deals, logging activity), a named same-day contact for questions, and a firm Salesforce decommission date communicated to everyone. The decommission date is not a threat, it is the adoption incentive. Open-ended dual access kills HubSpot adoption every time..

The teams that succeed treat go-live as the start of the project, not the finish line, because a technically perfect migration the sales team will not use has still failed.

What breaks in a Salesforce to HubSpot migration?

Migrations break in predictable places, and knowing them is most of how you avoid them. Here is where experienced teams concentrate their attention, and how to keep each one from biting.

• Lost attribution history. This is the highest-consequence failure, and the one teams notice last. In Salesforce, campaign attribution lives in Campaign Member records, Activity records, and the contact-to-account relationships that tie a touchpoint to an opportunity. HubSpot's model is different: attribution flows through the contact-company-deal chain. Map contacts across without carrying the campaign and activity history as HubSpot timeline events, and every marketing-sourced pipeline number from before the migration date is gone. Not impaired. Gone. If your CMO has to defend marketing's contribution after go-live, identify every campaign that touched a closed-won deal in the last 24 months and map those records to contact timeline events. It adds time. It is non-negotiable.
• Broken automations. Salesforce automation does not convert to HubSpot workflows. It has to be rebuilt. This is bigger than it looks in 2026, because most orgs carry automation across three tools. Salesforce stopped letting anyone create new Workflow Rules in 2023 and new Process Builder processes shortly after, and both reached end of support on 31 December 2025, leaving Flow as the only current build tool. So a typical migrating org has legacy Workflow Rules, legacy Process Builder processes, and newer Flows, all of which have to be catalogued and rebuilt. Apex triggers have no HubSpot equivalent at all and need rebuilding as workflow actions, custom-coded steps, or API integrations. Any automation not catalogued in Phase 1 silently disappears.
• Field-mapping mismatches. Salesforce picklist values, record types, and custom fields do not always have a clean HubSpot equivalent. HubSpot has no record types; properties and pipeline stages replace them, which is a conceptual shift, not a missing feature. Unmapped fields lose data. This is why the audit and the test load matter.
• Duplicate records. HubSpot treats email address as the unique identifier for a contact, and Salesforce's separate Lead and Contact objects usually both map onto HubSpot's single Contact object. That combination is a frequent source of duplicates if it is not handled deliberately on import.
• Property sprawl. Treat every Salesforce custom field as something that needs a HubSpot equivalent and you get an instance with hundreds of properties nobody understands, which slows adoption as much as any technical fault. The audit's field-population test is what prevents this.
• Reporting gaps. Salesforce reports and dashboards do not migrate. Build every report leadership relies on during the configuration phase, before training, so the CMO and CRO do not open HubSpot on day one to a blank dashboard and lose confidence on the spot. Reconcile the numbers against Salesforce before go-live so trust holds.
• Integration downtime. Reconnected tools can double-create or drop records during cutover if sync direction and timing are not planned. Inventory every integration and classify it: keep and rewire, replace, or retire.

In the migrations we run, the step teams underestimate most is integration validation. Reconnecting a tool is quick. Proving it behaves correctly under real data, across every workflow and sync that depends on it, is not. Budget for it and you keep your go-live date.

Validate before you go live: three checks

Before cutover, run three checks against the migrated data. Each one catches a failure that is cheap to fix now and expensive to fix later.

1. Association rate. Compare the contact-to-company association rate in HubSpot against the pre-migration Salesforce baseline. If it dropped, contacts came across without their accounts. Find them and fix them before go-live.
2. Attribution coverage. Take five recently closed-won deals from before the migration. Check that their associated contacts show campaign and activity history on the HubSpot timeline. Missing timeline events mean the attribution migration did not complete.
3. Reporting baseline. Run the marketing-sourced pipeline report in HubSpot for the window you migrated and compare it to the same report in Salesforce. The numbers will not match exactly, because attribution models differ, but they should be the same order of magnitude. A big gap means a migration hole.

Does HubSpot help with the migration?

HubSpot provides onboarding and migration tooling, but it does not do the migration for you. HubSpot's own Smart Transfer tool moves data from other apps into HubSpot, auto-mapping objects and properties and running a data audit before the transfer, which handles straightforward loads well.

Onboarding is a separate purchase: HubSpot requires onboarding with a new Professional or Enterprise licence, and it waives its own onboarding fee, worth roughly £1,200 to £6,000+ per Hub, if you onboard through a HubSpot Solutions Partner instead. What neither HubSpot's tooling nor its onboarding covers is the design decisions, the custom object and automation rebuild, integration reconnection, or pipeline redesign. For a simple migration, HubSpot's own tools plus internal effort can be enough.

For standard and complex migrations, the gap between "data imported" and "system working" is the part a partner does.

Should you migrate yourself or use a partner?

Migrate yourself if you have under roughly 5,000 contacts, standard objects only, no custom code, at most one integration, and someone in-house who knows both platforms. Below that threshold the project is mostly a careful data import, and HubSpot's Smart Transfer plus internal time can cover it.

Use a partner when custom objects, Salesforce automations, attribution history that matters to the board, multiple integrations, or a pipeline redesign are involved, which is most B2B migrations beyond the smallest.

The cost of a partner is almost always less than the cost of a botched migration: lost attribution, a sales team that does not trust the new system, and a second project to fix the first.

A meaningful share of the migrations we are asked to run are rescue jobs that follow a failed first attempt, which is the most expensive way to learn this lesson. The honest threshold is complexity, not company size.

The bottom line

A Salesforce to HubSpot migration is not a data-transfer job with a redesign bolted on. It is a redesign job with a data transfer at the end, and the projects that succeed are the ones that treat it that way. Audit before you move. Agree your system of record before you build. Move records in the order the model requires. Protect your attribution history. Treat the first 30 days as the project rather than the finish line. Get those right and the cost, the timeline, and the team's trust in the new system all follow.

If a migration is on your roadmap, the cheapest insurance is getting the design right before anyone exports a single record. Our HubSpot migration and onboarding work starts with exactly that: auditing the data, mapping the pipeline and the integrations, and agreeing the system of record before the build, so you arrive at a system worth using.

Book a free assessment and we will scope the move honestly, including telling you where you can do it yourself.

Frequently asked questions

How long does a Salesforce to HubSpot migration take?

A standard migration takes 6 to 10 weeks. Simple migrations can be done in 4 to 6 weeks; complex ones with custom objects and multiple integrations run 10 to 16 weeks. The data transfer itself is fast. The audit, design, and validation around it take the time, and any estimate given before a data audit is a guess.

Can I migrate from Salesforce to HubSpot myself?

Yes, if you have under roughly 5,000 contacts, standard objects, no custom code, and minimal integrations. HubSpot's free Smart Transfer tool and onboarding cover straightforward loads. Beyond that, custom objects, automations, attribution history, and integrations make a DIY migration risky, and the most common result is lost data and broken reporting.

Should I clean my data in Salesforce before migrating, or in HubSpot after?

In Salesforce, before. Cleaning after migration means working in a live system where new records are being created at the same time, which makes the job harder and more error-prone. Audit first, clean in Salesforce where the data has context, then migrate the clean version.

In what order should records be migrated?

Companies first, then contacts with their company associations, then open deals, then closed-won history, then activity and campaign history. HubSpot's association model needs the company record to exist before contacts can attach to it, so reversing the order produces orphaned records that have to be fixed by hand.

Why do Salesforce to HubSpot migration quotes vary so much?

Because the word "migration" covers very different jobs. The same phrase describes a clean 3,000-contact load and a decade-old org thick with custom objects, undocumented Apex, and a dozen connected systems, and those are not remotely the same amount of work. The biggest swing factor is data quality: a dirty database costs more to migrate than a larger clean one, because the cleanup is the work. A quote without a discovery call behind it is a guess.

Will I lose data migrating from Salesforce to HubSpot?

You will lose data if you do not plan for it. The common losses are attribution history, activity history, custom field values with no HubSpot equivalent, and records dropped to duplicates. Attribution is the costliest, because it is invisible until someone asks for a pipeline report covering the period before the move. A test load and the three pre-go-live validation checks catch most of the rest.

What happens to my Salesforce automations in HubSpot?

They do not transfer. Salesforce automation has to be rebuilt as HubSpot workflows. In 2026 this is bigger than it sounds, because most orgs carry a mix of legacy Workflow Rules, legacy Process Builder processes, and newer Flows. Workflow Rules and Process Builder reached Salesforce end of support on 31 December 2025, so a migration is often the moment teams discover how much undocumented automation they were running. Apex code has no HubSpot equivalent and must be rebuilt as workflow actions or custom integrations.

What is the biggest mistake in a HubSpot migration?

Treating it as a lift-and-shift. Copy your Salesforce structure into HubSpot unchanged and you recreate years of accumulated mess in a new platform. The migration is the one moment to redesign the pipeline, rationalise fields, and agree what your process should be. Teams that skip that step pay migration prices for the same problem.