Migration
Pipedrive to HubSpot migration service
Pipedrive holds five kinds of record and refuses to hold a sixth: an organisation, a person, a deal, a lead and a product. Everything else your business tracks has been squeezed into one of those, usually as deal fields or a second pipeline. That is the mapping problem this migration service exists to solve — not the export, which is a morning's work, but working out what the fields were standing in for. The work of a Pipedrive migration agency is deciding where each of those lands in HubSpot before a single record moves.
The mechanics
A small object model is what makes this crossing awkward
The order of operations is the same in every CRM move — freeze, export, map, load, reconcile, cut over — and it is set out generically on the CRM migration services page. What is specific here is the shape of the source. Pipedrive is deliberately small: no custom objects, one label field, a fixed set of activity types, and a deal record that has absorbed whatever else needed a home. HubSpot is roomier in some places and stricter in others, and the mismatch runs in both directions.
There is no custom object to inherit, so something has been improvised. A team leaving an enterprise CRM arrives with a drawer full of custom entities to re-home. A team leaving Pipedrive arrives with the opposite problem: the entity was never allowed to exist, so the property, the vehicle, the matter or the installation is living as a block of deal fields, as an organisation record that is not really an organisation, or as a second pipeline whose stages are not sales stages at all. The migration is the one moment when that can be straightened out — as a HubSpot custom object where the subscription includes them, as a separate pipeline, or as a documented property set if the improvisation was working fine. Left undecided, the improvisation is copied across and hardens for another three years.
Two Pipedrive field types have no HubSpot equivalent, and both fail silently. A monetary field stores an amount and its currency together. An address field stores street, locality, region, postal code, country and a pair of coordinates as one compound value. HubSpot properties hold a single scalar each, so a monetary field becomes an amount property plus a currency property, and an address field becomes as many properties as you actually use. The failure mode is not an error message — it is an import that completes cleanly with the compound column quietly dropped, which nobody notices until a quarter later when somebody tries to filter by state.
Activity types are a one-way collapse. Pipedrive lets an administrator define activity types beyond the defaults, and ships two — Deadline and Lunch — that HubSpot does not model at all. HubSpot engagements are a closed set: call, meeting, task, email, note. So the long tail of custom types has to be assigned a destination engagement and have its original name written into a property on the way through. Do it during the mapping and you keep the reporting. Do it during the load and the distinction is gone, because there is nothing left in the target to reconstruct it from.
Matching, and the ID that turns reconciliation into arithmetic. HubSpot deduplicates contacts on email address and companies on domain. Pipedrive enforces neither, and cheerfully holds a person with several labelled email addresses or none at all. That is exactly where an import merges two people you meant to keep apart. The defence is cheap: carry the Pipedrive record ID into a dedicated HubSpot property on every record before anything loads through HubSpot's CRM imports API (opens in new window). Counts then reconcile by joining on a key rather than by eye, and any integration you keep has something stable to point at afterwards.
| Pipedrive artefact | How Pipedrive models it | Where it lands in HubSpot | The decision it forces |
|---|---|---|---|
| Organizations | A record with a free-text name, no enforced uniqueness and an optional compound address | Companies, deduplicated on domain | What happens to organisations with no domain, and which near-duplicate names are genuinely the same business |
| Persons | Several labelled emails and phone numbers held inside one field each | One primary email plus additional emails, and separate phone and mobile properties | Which labelled value is primary, and whether the rest are kept, folded into a note, or dropped |
| Persons with no email address | Perfectly valid — Pipedrive requires nothing | A contact HubSpot cannot deduplicate on its usual key | What the matching key is instead, before the import creates a second copy of everyone |
| Pipelines and stages | Multiple pipelines, each stage carrying its own deal probability | Deal pipelines and stages, with probability set per stage | Which pipelines are really sales pipelines, and which were a workaround for the missing object |
| Deal rotting | A per-pipeline idle-days setting that flags a stalled deal automatically | No equivalent — rebuilt as a workflow reading last activity date | Whether the flag is worth rebuilding, or was noise everybody had learned to ignore |
| Lost reasons | A reason recorded when a deal is marked lost, often free text | A closed-lost-reason property on the deal | Whether years of free-text reasons become a fixed option set, and who maps the tail |
| Activities | Call, meeting, task, email, deadline, lunch, plus any type an admin added | Calls, meetings, tasks, emails and notes — a closed set | Which HubSpot engagement each non-standard type collapses onto, and where the original name is preserved |
| Leads Inbox | A separate entity that is neither a person nor a deal until it is converted | A contact carrying a lifecycle stage | Which lead states become which lifecycle stage, and how converted leads stay out of the import |
| Monetary and address custom fields | Compound values: amount plus currency, or a full postal address in one field | Two or more separate properties each | Exactly which sub-values you use, since the unmapped ones are discarded without an error |
| Labels | A colour-coded label on a person, organisation or deal | A property or a list — HubSpot has no label primitive | Which labels were real segmentation and which were one rep's private shorthand |
| Workflow automations | Event-triggered rules that fire every time the event happens | Workflows that enrol a record once unless re-enrolment is configured | Which rules must fire repeatedly, and which existed only to patch field hygiene |
| Filters and Insights dashboards | Saved filters per user, feeding shared reports | Lists and dashboards, rebuilt against the new property names | Which reports anyone actually opens, and which measure change over time rather than current state |
| Products and recurring revenue | Products attached to a deal, with subscription schedules on top | Products and line items, with recurring terms modelled on the line item | Whether billing stays with the finance system, and which side then owns the renewal number |
| Marketing status on a person | Subscribed, unsubscribed, archived or no consent, held for Pipedrive Campaigns | Subscription types plus the marketable-contact designation | Which imported contacts are marketable at all — a decision with a billing consequence in HubSpot |
Consent is not one more column in the contact import. Pipedrive's marketing status and HubSpot's subscription model describe the same obligation with different vocabulary, and the archived state in particular has no clean counterpart. Export it, map each state explicitly, load the result as HubSpot subscription state, and reconcile the counts against the obligations set out in the FTC's CAN-SPAM compliance guide (opens in new window) before any sending is enabled. Nothing goes out until those numbers agree.
Sequence
What changes in the plan when the source is Pipedrive
Inventory field types, not field names
Export the field definitions first and sort them by type. The monetary, address, date-range and time-range fields are the ones that need more than one destination each, and they are invisible in a list of field names.
Name what each pipeline is really for
With no custom object available, extra pipelines are how Pipedrive teams model onboarding, renewals, support or delivery. Each one gets a decision before export: a HubSpot pipeline, a custom object, or a process that leaves the CRM entirely.
Sample load, then reconcile on the Pipedrive ID
A few hundred records first, joined back on the stored Pipedrive ID. Contacts without an email address and organisations without a domain are where unintended merges appear, and this is while they are still cheap to undo.
Stage design is the part worth redoing rather than copying
A Pipedrive pipeline is cheap to create, which is why most orgs have more of them than they need and why the stages drift into internal admin steps — "sent to legal", "waiting on Dave". Those stages carry a probability that then feeds a forecast nobody trusts. Copying them into HubSpot copies the forecast problem with them. The alternative is to re-derive stages from buyer commitment, write an exit criterion for each, and map the old stage onto the new one in the import file so the history still lands somewhere sensible. Pipedrive's required-fields-per-stage setting maps neatly onto HubSpot stage requirements, so that piece does transfer — but only for the stages that survive the redesign.
Email history, and what belongs to the mailbox rather than the CRM
Pipedrive's mail sync pulls threads from the connected mailbox and shows them against a deal. Those messages are not really CRM data — the mailbox holds them and the CRM holds a reference — so they are not exported and re-imported. HubSpot re-establishes its own connection and starts logging from that point, with historical threads staying where they have always been. Teams expect this to be a loss and it usually is not, but it needs saying before cutover rather than discovering it in the first week.
Cutover, reconciliation and disposing of the export
Cutover runs one pipeline at a time. Record counts are compared in both directions on the stored Pipedrive ID, consent counts are compared separately, and a delta load picks up whatever was created during the freeze window. The Pipedrive account stays live and read-only for a lookback period, because the deal change log does not migrate and is still worth being able to open. One step is easy to skip: the export is a complete copy of your customer database sitting in a folder, on a laptop, and probably in a shared drive as well. Destroying those working files at the end of the project — deliberately, everywhere they were copied, along the lines of NIST's media sanitization guidelines (opens in new window) — is part of the work, not an afterthought.
Where this sits next to the rest of the work
If the source is Salesforce, the destination is the same but the problem inverts: record types, formula fields, validation rules and a lead object that converts one way, all of which our Salesforce to HubSpot migration page covers on its own terms. From Zoho it inverts again — custom modules, subforms and Deluge scripts to re-home rather than improvised deal fields to untangle — and that is the Zoho CRM to HubSpot migration page. From Insightly the source is light in the same way Pipedrive is, right up until the delivery work: projects and milestones are real records there with no HubSpot object waiting for them, which the Insightly to HubSpot migration page takes as its starting decision. Going the other way, from HubSpot into Pipedrive, the question flips to what has no slot at all — sequences, landing pages, tickets, custom objects — and our HubSpot to Pipedrive migration page leads with that list. If you are still choosing between them, our Pipedrive vs HubSpot for small business comparison sets out when each fits. If the honest answer on the call is that Pipedrive still fits your team and the real problem is how it has been configured, our Pipedrive automation consulting page describes that work instead. And once you have landed, running the portal properly — workflows, lifecycle stages, property hygiene — is the subject of our HubSpot automation consulting page, while how engagements work explains how a scope gets agreed before any of it starts.
The honest part
What does not survive the crossing
Less than most teams fear, because Pipedrive's object model is close to HubSpot's for the records that matter and the volumes are usually modest. Some of it genuinely does not move, and a firm that says otherwise has not opened your account. Knowing which is which before you commit turns the lookback period into a decision rather than a discovery.
| What | Treatment | Why |
|---|---|---|
| Organization, person and deal field values | Moves | They load cleanly once every destination property and every option value exists on the HubSpot side first |
| Open deals and stage position | Moves | Stage, value, expected close date and owner land on a deal once the pipelines and users have been created |
| Activities, notes and files | Moves deliberately | They load as engagements on the matching record, which is worth doing for open business and rarely worth doing for all history |
| Products and deal line items | Moves | The product library rebuilds first, then line items attach to deals — in that order, or the lines have nothing to reference |
| Monetary and address field values | Rebuilt as several properties | HubSpot has no compound property, so each source field is split during mapping rather than at import time |
| Custom activity types | Collapsed and recorded | HubSpot's engagement set is closed, so the type is preserved in a property and the engagement takes the nearest standard shape |
| Workflow automations | Rebuilt | A different execution model: enrolment with memory instead of an event firing every time, so each rule is re-expressed and re-tested |
| Deal rotting and required-field settings | Rebuilt where they earn it | Required fields map onto stage requirements; rotting has no counterpart and becomes a workflow, or is retired on purpose |
| Insights dashboards and saved filters | Rebuilt | Reports are rebuilt against new property names, and anything measuring duration or change rather than current state is exported and archived first |
| Deal change log and record history | Stays behind | The audit trail belongs to the account that recorded it, which is the argument for keeping Pipedrive readable rather than importing everything |
| Synced email threads | Re-established, not migrated | The mailbox owns the messages; both CRMs only hold a reference, so HubSpot connects and starts logging from cutover |
| Web forms, chatbot and Scheduler links | Replaced | Anything still writing into the old account keeps creating records there after cutover, and nobody notices for weeks |
You own the result outright: records in your own portal, workflows documented against the trigger that starts them, a field map showing where every Pipedrive field went, a written note of what each extra pipeline became, and an equally written note of what was left behind on purpose. If your own team would rather run the load, we will build the field map and the scaffold and stay on as backup — and if the honest answer on the call is that Pipedrive still suits you better than HubSpot would, that is what you will hear.
Questions
What Pipedrive teams ask before committing
What happens to our Pipedrive custom fields in HubSpot?
Most become properties one for one. Two field types do not. A monetary field carries its own currency alongside the number, and an address field carries street, locality, region, postal code and country as a single compound value. HubSpot has neither shape, so each one splits into two or more properties, and that split has to exist before the import runs or the value is discarded without an error.
Do Pipedrive activity types survive the move?
Only the ones HubSpot also has. HubSpot records calls, meetings, tasks, emails and notes, and nothing beyond that. Pipedrive ships Deadline and Lunch as well and lets an administrator invent more, so every non-standard type collapses onto the nearest HubSpot engagement while the original type is preserved in a property. Decide the collapse before the export, because the distinction cannot be recovered afterwards.
What happens to records sitting in the Pipedrive Leads Inbox?
A Pipedrive lead is its own entity, neither a person nor a deal, and HubSpot has no separate lead table on most subscriptions. So each lead lands as a contact carrying a lifecycle stage, with the qualifying notes folded into a property or a note on the record. Leads already converted into deals have to be excluded from that import, or the same opportunity arrives twice.
Do Pipedrive automations convert into HubSpot workflows?
Not automatically, and the difference is enrolment. A Pipedrive automation fires on an event every time that event occurs. A HubSpot workflow enrols a record once and remembers it, so a rule that should run on every stage change needs re-enrolment turned on deliberately. Each automation is read, rebuilt and tested, and the ones that only ever patched a field-hygiene gap are retired instead.
How does marketing consent carry across from Pipedrive?
As its own reconciliation, finished before any sending is switched on. Pipedrive keeps a marketing status on the person record, with subscribed, unsubscribed, archived and no-consent as separate states. HubSpot splits the same idea between subscription types and the marketable-contact designation, which also has a billing consequence. The two are mapped explicitly and the counts are compared before the first send.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.