In brief: Pipedrive ran the sales side of the business, with close to sixty custom fields tracking lead tiers, qualification, and account routing. HubSpot's native Data Sync connector matched every record correctly, but only mapped a handful of default fields automatically. Everything else had to be mapped by hand before the migration was actually complete.
5 of 35+ Contact fields
mapped automatically by HubSpot's native Pipedrive connector. The rest had to be mapped by hand, one field at a time.
This post is a Loncom Consulting case study - what actually breaks when you migrate Pipedrive to HubSpot using the native connector, what the field mapping screen doesn't warn you about, and how we closed the gap before it cost the client data.
The sync dashboard showed green. Record ID was matching Deals one-to-one between Pipedrive and HubSpot, Organizations were matching on company name, and every Contact had come across without a single failed sync. On paper, the migration was done.
Then the sales team opened a Contact record and started asking questions. Where was the lead tier. Where was the qualification tag. Where was the field that told them which reps were meant to be working this account. None of it had made the trip, because none of it had ever been part of the sync. The connector had matched every record correctly and mapped almost none of what the business actually used those records for.
What Was Actually in Pipedrive
The full object scope of HubSpot's Data Sync app for Pipedrive. This case study focuses on People, Deals, and Organizations, where the custom field gap actually showed up.
This was not a simple five-field CRM. Pipedrive's People object alone was carrying close to forty custom properties: qualification tiers, lead source and communication channel tags, account classification, contact role, gender, and a handful of internal labels the sales team used to route accounts to the right rep. Deals had close to twenty custom properties layered on top of the standard pipeline fields, tracking lost reason detail, weighted value, archive status, and internal timestamps for every stage a deal passed through. Organizations carried its own overlapping set: classification, relationship tags, ideal customer profile tier, and a first-contact date used for reporting.
None of that shows up in a demo of the connector. It only shows up once you try to move it, and by then the sync has usually already run.
What Breaks When You Migrate Pipedrive to HubSpot?
HubSpot's Data Sync app for Pipedrive matches records first and maps fields second, and it treats every object differently. Here is what the tool mapped automatically against what actually had to be built by hand, object by object.
Scroll sideways on mobile to see the full table.
A sample of the actual mapping decisions from this migration, reconstructed from the Data Sync configuration screens. Risk reflects likelihood of silent data loss or duplication if the connector's defaults are left unchanged.
The actual Contacts mapping screen: five fields mapped by default against more than thirty custom ones, mapped one at a time.
Two details in that setup screen are easy to miss. First, the conflict resolution rule is global, not per field. Setting it to use Pipedrive data means Pipedrive wins any time both systems have touched a record, which is fine mid-migration and becomes a problem the moment someone starts editing records in HubSpot before Pipedrive is switched off. Second, the interface flags full custom field mapping as temporary on lower plan tiers, until you upgrade. Build out a complete field-by-field mapping and it can quietly stop working once that allowance runs out - worth checking before a team spends hours mapping fields that won't persist.
If any of this sounds familiar from the other side of the platform, it should. We ran into a similar gap between "the dashboard says it's syncing" and "the data is actually correct" when we audited a HubSpot-Shopify integration that looked healthy on paper. Native connectors are built to move data, not to know which of your custom fields actually matter to the business using it.
Migrating a heavily customized CRM?
See Our Integrations Work"A green sync status means the connector is doing its job, not that the migration is finished. Those are two different definitions of done, and the gap between them is exactly the custom fields nobody thinks to check until someone goes looking for them." - Antonio Karneluti, CTO at Loncom Consulting
How We Closed the Gap
Before touching the sync toggle, we audited every custom field on Pipedrive's People, Deal, and Organization objects and mapped each one to an existing or newly created HubSpot property, rather than accepting the default mapping and back-filling later. Matching keys were chosen per object based on data quality, not on whatever the connector suggested first: Record ID for Deals, where uniqueness was guaranteed, email for Contacts, once a duplicate check confirmed it was safe, and company name or domain for Organizations, which the native matching already handled well.
We ran the full mapping in a sandbox first, checked association integrity across Person, Deal, Organization, and Owner records, and only then executed the live sync. Once validation was complete, we turned off the two-way sync and disabled Pipedrive's write access, so the conflict resolution rule that had been useful during migration could not silently overwrite anything a rep entered in HubSpot afterward. It's the same discipline we applied mapping patient and treatment data across a Dentally-HubSpot integration and quote-to-invoice data on a PrintIQ-HubSpot integration: match on the field that's actually unique, map before you sync, and validate before you cut over.
Duplicate records that slipped through before the matching key was corrected were resolved separately as a data quality pass. That's a distinct problem from migration mapping, and one worth budgeting for on its own - see our approach to CRM data cleaning if that's the state a migration has left you in.
By the time the sync went live, more than thirty Contact fields and seventeen Deal fields had been mapped and validated by hand, association integrity confirmed across every Person, Deal, Company, and Owner record, and Pipedrive's write access switched off for good.
Once the data's migrated and clean, the next question is what it's telling you
Explore HubSpot CRM DashboardsWhat Should You Check Before a Pipedrive to HubSpot Migration?
If you're planning a Pipedrive to HubSpot migration with the native connector, these are the checks that would have caught every issue in this case study before go-live.
| 1Audit every custom field on each Pipedrive object before configuring the sync, not after |
| 2Choose a matching key per object based on data quality, not the connector's default |
| 3Check whether HubSpot already has Notes on any records before syncing Notes |
| 4Confirm your plan tier supports permanent custom field mapping, not a temporary allowance |
| 5Turn off two-way sync and conflict resolution once the migration is validated, so old Pipedrive data can't overwrite new HubSpot activity |
Not sure what your Pipedrive to HubSpot migration is missing?
Book a Free ConsultationFrequently Asked Questions
Does HubSpot's native Pipedrive connector migrate custom fields automatically?
No. The Data Sync app maps a small set of default fields per object automatically, for example Title, Value, and Currency on Deals. Every custom field has to be mapped manually, one at a time, before it syncs.
What's the difference between syncing Pipedrive to HubSpot and migrating it?
Syncing keeps both systems live and continuously updates each other. Migrating is a one-way move where Pipedrive is retired once the data is confirmed accurate in HubSpot. The native connector is built for the first case, which is why teams treating it as the second one run into gaps.
Why do duplicate records show up after a Pipedrive to HubSpot migration?
Usually because the matching key was set to no matching, or Notes were synced without checking whether HubSpot already had notes on the same records. Both create duplicates on the very first sync.
What happens to Notes specifically when migrating from Pipedrive to HubSpot?
Notes have no field-level matching option at all, only "do no matching." Every Note is treated as new on sync, so if HubSpot already has notes on any of the same records, expect duplicates unless they're cleaned up afterward.
Should data conflict resolution stay switched on after the migration is finished?
Not usually. It is designed to resolve ambiguity during an active migration. Leaving it on afterward risks HubSpot edits being silently overwritten by older Pipedrive data.
If custom field mapping and object matching are the part of this that sound familiar, they show up in most CRM migrations we run, not just Pipedrive ones. The Dentally-HubSpot integration and the PrintIQ-HubSpot integration both hit the same wall: a native or default sync gets the obvious fields across and leaves the business-specific ones for someone to notice missing.
Last updated: September 3, 2026
Leave a comment