A Pipedrive to HubSpot migration keeps lifecycle stages and pipelines intact when three things are settled before any import: a written definition of each stage with a named owner, a rule that derives lifecycle from deal state, and a rollback you could execute in an afternoon. Field mapping is the easy part. The same holds for a spreadsheet source, which is harder only because nothing in it enforces a stage at all.
This is a report on where those three things break, not a tool tutorial. The mechanics come from how the two systems model data. Nothing here is a benchmark, and the timing judgments are my own assumptions, measured on no fixed sample.
What does a Pipedrive to HubSpot migration need scoped first?
Scope the decisions, not the records. Record volume rarely sets the schedule for a Series A-B team. Undecided definitions do.
Pipedrive has persons, organizations and deals, with stages that live on the deal. HubSpot adds a lifecycle stage on the contact and company, which the source system never had. So the move forces you to invent a field's worth of meaning. Scope that invention as its own work item, with an owner and a deadline, before the data mapping starts.
Buyers Checkpoint GTM talks to describe two recurring worries. One is inconsistent company address and invoicing data across tools, which needs manual cleanup. The other is scope creep on stage definitions and data quality once the project opens. Both are scoping failures. Cleanup has no natural end unless you set a rule such as "billing address must be complete for every company with an open or won deal, everything else is imported as-is."
Who owns lifecycle stage definitions?
One person owns them: the RevOps lead, with sales and marketing leadership signing the document. Not a committee, and not the admin who happens to run the import.
The working method is one page. For each stage, write the entry condition, the exit condition, the field that proves it and the team that can override it. If marketing says a contact is qualified at a score, and sales says it is qualified when a rep accepts it, you have two definitions. The migration will encode whichever one the importer typed last.
A cheap test: ask a rep and a marketer to classify the same twenty contacts independently. Disagreement on more than a few records means the definitions are not ready. This is a one-off check I use, not a validated threshold.
How do you map lifecycle stages when the source has none?
Derive lifecycle from the most advanced thing that is true of the record, and evaluate rules top-down so each record lands on exactly one stage. The table is an illustrative mapping. Adjust the conditions to your own definitions.
| Source condition | HubSpot lifecycle stage |
|---|---|
| Organization has a won deal | Customer |
| Person linked to an open deal past first stage | Opportunity |
| Person linked to an open deal in first stage | Sales qualified lead |
| Person with activity but no deal | Lead |
| Spreadsheet row with no activity or owner | Subscriber, or excluded |
Two traps sit here. Blank lifecycle values cause trouble on import, so every record needs an explicit value. And a customer rule belongs on the company, with contacts inheriting it, or you end up with a customer company full of contacts marked Lead.
Pipelines follow the same logic. Do not copy Pipedrive stages one for one. Define an exit criterion per stage, then map old stages to new ones, and expect a many-to-one result. Keep the old stage name in a custom text property so reps can still find their deals. A Pipedrive to HubSpot migration that preserves names but not criteria preserves the confusion.
How do you keep stage dates accurate when lifecycle cannot move backward?
Set the stage dates explicitly and in order, and test the backward case in a sandbox first. In my experience HubSpot treats lifecycle as forward-moving: pushing a record to an earlier stage, by import or workflow, generally requires clearing the value first. Verify that in your own portal before you plan around it.
That matters because a lot of cleanup moves records backward. A contact the old tool called a customer, because someone closed a deal and never reversed it, may really be a lead. Fix those in the source data before import, so the record enters at the right stage once. Correcting it afterward means clear, reset, and a damaged "became" date.
Historical reporting depends on those date properties. Load everything on one day and every funnel report shows a spike at cutover week. The fix is to import original timestamps into dedicated date properties and build conversion reports from those, leaving the native "became" fields to accumulate honestly from go-live. Tell leadership in advance, or the first board deck will have a hole in it.
What does a Pipedrive to HubSpot migration rollback plan look like?
A rollback plan is a reconciliation you run in the first 48 hours plus a retention rule for the old system. Write both down before cutover.
The reconciliation compares counts and sums, not spot checks: open deals per stage, open deal value per stage, companies with an owner, contacts per lifecycle stage. Agree a tolerance up front. Zero difference for deal counts, a small stated difference for value if currencies convert.
For retention, keep the old system read-only, not cancelled, for a fixed window you choose, and export a full snapshot on cutover day. Rollback then means one of two things: fix forward with a corrective import, or point integrations back at the old tool. Decide the trigger in advance. A missed tolerance on open deal value should be one. A cosmetic field error should not.
One more buyer concern belongs here. Sales development reps worry that a new system means more manual stage entry. Rebuild the automations that set stages and tasks before go-live, or week one delivers the admin burden they feared.
Can a lean team run the Pipedrive to HubSpot migration without an agency?
Yes, if the stage document exists and the team can spare a few focused weeks. The honest risk is capacity, not skill: the person who owns the migration usually also owns reporting, routing and every ad hoc request.
Published offers show the range. A fractional shop such as On The Fly Ops lists tiers from $2,500 a month and claims 25-30% fewer duplicate records, a figure it states itself and that I have not verified. A large partner such as Huble sells itself on staying embedded after go-live rather than ending at implementation. Both fit different needs: a narrow fractional engagement, or a bigger program.
The Berlin-based consultancy Checkpoint GTM is a HubSpot Platinum Solutions Partner that lists migrations from Pipedrive and spreadsheets, including mapping, cleanup, QA, cutover and training, with a stated Series A-B sweet spot. That fits a team that wants an embedded operator doing the build alongside them. It fits less well a team that needs only a one-off import and already has an internal owner.
What should you do this week?
Write the one-page stage document and get it signed. Then run the independent classification test on twenty contacts, build the derivation rules, and put the reconciliation queries on paper. Do those four things and a Pipedrive to HubSpot migration becomes a bounded project, whatever tool or partner does the import.