Migrating to HubSpot: A Data Migration Guide

Migrating to HubSpot goes more smoothly when lifecycle stages, deal pipelines and required properties are planned before data moves — HubSpot’s data model has some genuinely different concepts (lifecycle stage in particular) from most other CRMs, and mapping those correctly up front avoids months of confusing reports afterward. If you’re still deciding whether HubSpot is the right destination at all, the HubSpot vs Salesforce comparison and the platform-agnostic CRM migration guide are worth reading first — this guide assumes HubSpot is the confirmed destination and focuses on what’s specific to it.

Map lifecycle stages before you map anything else

HubSpot’s lifecycle stage (subscriber → lead → MQL → SQL → opportunity → customer) is central to how HubSpot’s reporting and automation work, and most other platforms don’t have a direct equivalent. Before migrating, decide explicitly how your source data’s stages or statuses translate into HubSpot’s lifecycle stages — get marketing and sales to agree on the mapping together, since lifecycle stage usually drives both teams’ reporting and a mismatch here creates disagreement about what a “lead” actually means for months after go-live.

Write the mapping down as an explicit table — source status on one side, target lifecycle stage on the other — and walk through edge cases before import: a contact with no deal and no marketing engagement, a contact who was a customer in the old system but has since churned, a contact imported from a list with no status at all. Deciding these defaults in a meeting takes twenty minutes; discovering them as bugs in a dashboard three weeks post-migration takes considerably longer to trace back to the root cause.

Coming from a platform with a flatter data model — Pipedrive’s single deal-stage pipeline, or a spreadsheet with no status column at all — the lifecycle-stage mapping exercise is where most of the real thinking happens, since there’s no existing field to map from directly. In that case, build the mapping from actual sales behavior instead: pull a sample of contacts that closed as customers in the last two quarters and work backward through what qualified them at each point, then use that pattern to set defaults for the rest of the database. Coming from Salesforce, the opposite problem shows up — Salesforce’s Lead/Contact split and multiple record types often map to more granularity than HubSpot’s lifecycle stage captures, so part of the mapping work is deciding which distinctions to collapse rather than which to invent.

What migrating to HubSpot typically costs, by company size

HubSpot’s per-seat license price is easy to find; the number that actually determines your first-year budget is implementation cost, and it scales with Hub mix and integration count more than headcount. The chart below shows the cited industry cost range by company size:

Two things worth noting against the Salesforce cost range: HubSpot’s small-business floor ($2k) sits below Salesforce’s ($5k), and its enterprise ceiling ($30k+) is a fraction of Salesforce’s ($150k+). That gap is mostly Hub count and customization depth, not a difference in migration rigor — a single-Hub HubSpot migration with clean data genuinely costs less to execute than a multi-cloud Salesforce build, but a multi-Hub HubSpot Enterprise rollout with a Salesforce migration behind it and several integrations can land closer to the middle of that enterprise range than the buyer expects going in. Where your specific migration falls depends on Hub mix, integration count and data volume — exactly what a scoping call is for, not something a generic per-seat price answers.

Where the migration budget actually goes

The phase breakdown at the top of this guide is worth looking at more closely, since it explains why “just import the contacts” plans routinely run over budget. Data migration/dedup and properties/workflow build are tied as the two largest line items, each consuming roughly 22% of a typical project — together, that’s nearly half the migration budget going to work that happens before a single contact record is validated in production.

Validation and cutover together are only 20% of the total — a reminder that most of the risk in a HubSpot migration is retired before cutover day, provided the mapping, property and dedup work earlier in the list actually got the attention its budget share implies. A project that compresses lifecycle mapping and properties work to “save time” isn’t actually saving effort, it’s just moving the same work later, where it’s more expensive to fix because live records and live workflows are already built on top of it.

Rebuild your deal pipeline, don’t just import stage names

Deal pipelines and stages need to be built in HubSpot to match your real sales process, not just imported as a flat list of stage names from your old system. This is the moment to fix a pipeline that’s drifted from reality — if your old CRM’s stages didn’t reflect how deals actually moved, recreating them as-is in HubSpot just carries the same problem forward.

A practical check: pull a sample of 20-30 closed-won deals from the old system and trace which stages they actually passed through versus which stages exist on paper but rarely get used. Stages nobody’s deals ever occupy are candidates to cut; stages where deals visibly skip from one to another (bypassing a “Proposal Sent” stage entirely, say) suggest the real process has already diverged from the documented one, and HubSpot’s rebuild is the natural point to reconcile the two rather than encode the fiction.

If you’re running more than one genuinely different sales motion — new business versus renewals, or different products with different cycles — HubSpot supports multiple pipelines per deal object, and it’s worth using that deliberately rather than cramming every motion into one pipeline with stages that mean different things depending on which team is looking at them. The same logic that applies to Salesforce record types applies here: if two teams would name the stages of their process differently, that’s the signal for separate pipelines, not a shared one with extra optional fields.

Set required properties before data lands, not after

HubSpot’s data quality tools (required properties, property validation) are only useful if configured before migration — importing data first and adding required-field rules afterward means you’re retroactively fixing a database that’s already inconsistent. Decide which properties are genuinely required at each lifecycle stage before the first record is imported.

Required properties work best when they’re tied to a specific lifecycle-stage transition rather than applied blanket-wide — requiring a “deal source” on creation makes sense, but requiring it on every contact regardless of stage just trains reps to fill in a placeholder value to get past validation. Property validation rules (format, allowed ranges) are worth setting on fields that feed reporting or automation logic in particular, since a malformed value there breaks a workflow or dashboard rather than just looking untidy on a record.

Rebuild workflows in HubSpot’s automation model

Workflows, lead routing and notification automation from another platform (or from Salesforce Flow/Apex) need to be rebuilt using HubSpot’s own workflow tools — the logic can usually be replicated, but the mechanics are different enough that a direct copy rarely works. Treat automation rebuild as its own line item in migration planning, not an afterthought once data is loaded.

Start by listing every automated action the old system performs — not the tool that runs it, the action itself: “notify the rep when a demo is booked,” “move a contact to MQL after three email opens.” Rebuilding from the action list, rather than trying to translate the old tool’s specific trigger syntax line by line, usually produces a cleaner HubSpot workflow than a literal port would, and it’s the natural point to retire automations that accumulated as one-off exceptions nobody remembers the reason for.

For teams coming specifically from Salesforce, this is usually the single biggest scope surprise: Apex triggers and Flow logic built around governor limits and record-level sharing rules have no HubSpot equivalent to translate to line-by-line, because HubSpot’s workflow model doesn’t work that way. The fix isn’t a literal port — it’s re-deriving the underlying business rule (“route to the rep who owns the territory,” say) and rebuilding it natively in HubSpot’s workflow branching and if/then logic, which usually takes less configuration than the original Apex did but requires someone who understands why the original automation existed, not just what it did.

De-duplicate before import — HubSpot’s dedup tools work best on your active-going-forward data

HubSpot has built-in duplicate management, but like most CRMs it’s best used to prevent new duplicates once you’re live, not to clean up a large existing mess after import. Run de-duplication on your source data before migrating (see the general CRM migration guide for the full de-dup process), particularly for company/contact matching if you’re consolidating from multiple source systems.

Consolidating from more than one source is where this gets genuinely tricky: the same company might exist in a marketing tool’s list, a spreadsheet the sales team keeps, and an old CRM, each with slightly different name spellings and no shared unique identifier. Match on email domain and normalized company name before import rather than relying on HubSpot’s post-import dedup tools to untangle three overlapping datasets — those tools are built to catch a new duplicate created by a rep, not to reconcile a multi-source consolidation.

Work through matches in the same confidence tiers that apply to any CRM migration: exact email matches can be merged with minimal review, while a company-name match with different phone numbers or slightly different spellings needs a human to confirm before merging — an overly aggressive automated pass is just as likely to combine two real companies that share a common word in their name as it is to catch a genuine duplicate.

Worth knowing before you rely on any dedup tool, HubSpot’s included or otherwise: a widely-cited Bloor Research analysis of data migration projects found that poor source-data quality drives roughly 53% of migration cost and schedule overruns, and separate industry tracking puts the share of migration projects that end up over budget or over schedule at more than 80%. HubSpot has leaned into AI-assisted data tooling recently — the platform expanded from four Breeze AI agents to more than 20 between January 2025 and February 2026 — but that expansion is aimed mostly at ongoing enrichment and workflow assistance once you’re live, not at reconstructing a messy source database during import. The dedup work described above still has to happen before data lands in HubSpot, not after.

Decide what happens to marketing data separately from sales data

Marketing data needs its own migration plan, separate from the sales pipeline, whenever the source system doesn’t already track it the way HubSpot does. This applies most directly if you’re migrating from a sales-only CRM into HubSpot’s combined Marketing/Sales/Service Hubs: email subscription status, marketing consent records and campaign history usually need their own mapping and import process distinct from the deal/contact migration, and consent/compliance data in particular needs to carry over accurately, not be reconstructed from scratch.

Subscription-type mapping deserves its own checklist item: HubSpot’s subscription types (marketing emails, one-to-one emails, and any custom types you configure) need mapping from whatever unsubscribe or consent flags the old system tracked, and any contact whose consent status is ambiguous should default to unsubscribed rather than subscribed — reconstructing consent optimistically is a compliance risk, not a data-quality shortcut worth taking to preserve a bigger marketable-contact count.

Sequence the two migrations rather than running them together: validate the sales pipeline first, since a broken deal or a missing contact is immediately visible to a rep working it that day, then layer marketing data in as a second phase once sales is stable. HubSpot’s marketing-contact tier pricing is also worth checking before this second phase runs — a consolidation from three source systems can genuinely change how many contacts land in a marketable state, and that number affects the license bill in a way a sales-only migration never touches.

Test in a sandbox before the real cutover, not against production

For any migration beyond a simple single-Hub move with a small, clean record count, testing against a HubSpot sandbox before the real cutover catches problems while they’re still cheap to fix. HubSpot’s sandbox environments, available on Professional and Enterprise tiers, let a team validate lifecycle-stage automation, workflow logic, and a sample data import against something close to real volume, without any risk to production data if the mapping turns out to be wrong.

The value of sandbox testing specifically for a HubSpot migration is catching the failure mode described earlier in this guide — a workflow that looks correct on paper but silently stops advancing contacts through the funnel once real, messy data starts moving through it. Running a genuinely representative sample (not just a handful of clean, hand-picked test records) through the sandbox surfaces edge cases a small manual spot-check would miss: a contact with no email address, a company name containing a character the field mapping doesn’t handle cleanly, a lifecycle-stage transition that fires twice under specific timing conditions. Finding these in a sandbox costs an afternoon of rework. Finding them three weeks after go-live, once live reports and live automation are already built on top of the same bug, costs considerably more.

Teams on Starter or lower tiers without sandbox access can approximate the same safety net with a smaller test portal or by staging the import in batches, starting with a deliberately small, representative sample before running the full migration — slower than a proper sandbox, but still far better than validating the mapping logic for the first time against the complete live dataset.

Custom objects need their own migration plan

Custom objects — anything beyond HubSpot’s standard contact, company, deal, and ticket objects — don’t migrate automatically from a source system, even when the source platform has its own equivalent concept. A Salesforce custom object, a Zoho module, or a spreadsheet-based tracking system for something like “Projects” or “Renewals” needs to be recreated in HubSpot as its own custom object (available on Professional and Enterprise tiers), with property definitions and, critically, associations to contacts, companies, and deals rebuilt deliberately rather than assumed to carry over.

This is one of the most commonly underestimated pieces of a HubSpot migration specifically, because it looks like a data problem (“we just need to move the records”) when it’s actually a data-model design problem: HubSpot’s association framework works differently from how most source systems relate custom records to core objects, and getting the association structure right the first time avoids a costly redesign once records and workflows are already built against it. Scope custom-object migration as its own line item with its own timeline, separate from the standard contact/company/deal migration described earlier in this guide, and involve whoever actually uses those custom records day to day in confirming the rebuilt structure still supports their workflow before data gets loaded into it.

Set up teams and permissions before the first record lands

HubSpot’s teams and permission-set structure determines who can see, edit, and export which records, and building it after data has already migrated means retrofitting visibility rules onto a database everyone’s already gotten used to seeing in full. Decide before migration: which teams exist (by department, by territory, by product line), whether reps should see only their own contacts and deals or the full database, and which permission sets (view-only, edit, owner-only delete) apply to which roles. This is a business decision dressed up as a settings panel, the same way access provisioning is for any CRM, and it’s considerably easier to define before hundreds of records exist for people to already be used to seeing.

A specific trap worth naming: HubSpot’s default account settings tend toward permissive, “everyone sees everything” access when nothing’s been explicitly configured, since that’s the simplest default for a small team standing up their first portal. That default quietly stops being appropriate the moment a sales team scales past a handful of reps, or the moment a second department (support, marketing) gets added to the same portal and shouldn’t see every deal’s commission-relevant fields. Configuring teams and permissions as part of the migration project, rather than as a reactive fix once someone notices a visibility problem, avoids a permission retrofit that’s disruptive precisely because it’s rolling back access people have already had for months.

The same planning should cover data export permissions specifically, since HubSpot’s export function is a common overlooked gap — a rep with standard edit access can often export the full contact database unless export permissions are explicitly restricted, which matters more for a company handling sensitive customer data or operating under a compliance framework that limits how customer data can leave the system. Reviewing export permissions alongside the broader teams and permission-set decision, rather than as an afterthought, closes a gap that’s easy to miss because it doesn’t show up as a functional problem, only as a risk that’s invisible until it’s exercised.

Validate before you turn the old system off

After cutover, run a structured validation pass rather than assuming the migration worked because the import completed without errors: spot-check a sample of migrated deals and contacts against the old system, confirm lifecycle-stage automation is moving new activity through the funnel correctly, and check that sales reps’ pipelines and reports look right to them — not just to the person who built the migration. Keep the old system in a read-only state for a defined period (often 30-90 days) rather than deleting it immediately, since it’s the only place to check a migrated record against if a discrepancy surfaces later.

A validation pass that’s specific to HubSpot: check that lifecycle-stage transitions are actually firing on new activity, not just that historical records show the right stage. A migrated database can look correct on day one and still have a broken workflow that silently stops advancing contacts through the funnel — that’s a problem that only surfaces a few weeks later, once someone notices MQL counts have flatlined, so it’s worth deliberately testing a few live transitions (a form fill, an email open threshold) against real workflow behavior before calling the migration complete.

Where to go for the full cost breakdown and platform comparisons

See the HubSpot implementation cost guide for cited industry cost ranges and the specific hidden costs — including contact-tier pricing jumps and Operations Hub costs some migrations don’t anticipate — that a simple per-seat price comparison misses. If you’re comparing HubSpot against where you are now, the HubSpot vs Salesforce, HubSpot vs Pipedrive and HubSpot vs Zoho CRM comparisons cover what switching actually involves from each platform, and the platform-agnostic CRM migration guide covers the steps — data audit, field mapping, sandbox testing, cutover planning — that apply regardless of destination. If Salesforce is the platform you’re actually coming from, the migrating to Salesforce guide covers that direction in the same depth this one covers HubSpot.

Get your migration scoped

A free 30-minute call reviews your current setup and gives you a written read on what migrating to HubSpot specifically involves for your data and process — not a generic estimate.