Pipedrive-to-GoHighLevel is a deal-to-contact schema translation. CSV breaks relationships — use API-led ETL or a managed service for anything beyond flat contact lists.
There is no native migration path from Pipedrive to GoHighLevel; the core challenge is a fundamental data-model translation between Pipedrive's deal-centric architecture (Deals linked to Persons and Organizations) and GoHighLevel's contact-centric model (Contacts, Companies, and Opportunities within Pipelines). A simple CSV export flattens multi-object relationships, silently duplicates organization data, and transfers zero automation logic. Preserving deal-contact-company hierarchies, activity history, and custom field mappings requires custom API-based ETL work or a managed migration service, with careful schema planning to accommodate GHL's 10 Custom Object limit and strict API rate limits on both sides.
Read this first
Pair-specific gotchas that catch teams out. Each one has cost somebody a weekend.
Pipedrive allows a Deal to be linked to both a Person and an Organization simultaneously
In GHL, an Opportunity ties to a single Contact. If your Pipedrive data relies on Organization → Person → Deal hierarchies, decide before migration whether the Company or the Contact is the primary record owner in GHL. Build the hierarchy bottom-up: Company → Contact → Opportunity.
Your migration script's token budget is shared with all users and integrations on the
Your migration script's token budget is shared with all users and integrations on the Pipedrive account. If sales reps are working in Pipedrive while you're extracting data, their API-driven integrations compete for the same token pool. Schedule extraction during off-hours or use a dedicated API token.
Failure to respect GHL's 100 req/10s burst limit can result in IP blacklisting or silent
Failure to respect GHL's 100 req/10s burst limit can result in IP blacklisting or silent data dropping during high-volume loads. Always log your x-ratelimit-remaining headers and implement a token-bucket or leaky-bucket algorithm to throttle writes.
GHL automation workflows fire on contact creation by default
Loading 50,000 contacts via API will trigger enrollment in every active workflow that has a "Contact Created" trigger — unless you pause those workflows before the migration run. Failing to do this floods your GHL automation queue, sends live emails or SMS to imported contacts, and may corrupt workflow state for records you did not intend to enroll. Pause all enrollment-triggered workflows in the destination sub-account before starting any bulk import, and re-enable them only after validation is complete.
Every Pipedrive Deal that becomes a GHL Opportunity needs a valid Contact on the destination side
GHL's create-opportunity API requires contactId, pipelineId, locationId, name, and status. If you have org-led Deals with weak Person data, define a fallback strategy before load time. (marketplace.gohighlevel.com)
Pipedrive custom fields use random 40-character hex hashes as API keys, unique per account
You must dynamically discover field mappings using the field definition endpoints and cache the results before building your transformation layer.
The retry pattern above uses exponential backoff with jitter
A fixed time.sleep(10) on every 429 is not sufficient — at high volume, synchronized retries from a fixed delay will hammer the rate limit window repeatedly and extend total migration time significantly. Cap maximum backoff at 60 seconds and add randomized jitter to desynchronize retry waves.
Run a test migration with 100–200 records first
Validate the full pipeline — extraction, transformation, loading, and association rebuilding — before committing to the full dataset. A dry run catches 90% of mapping errors before they hit production.
The runbook
Work top to bottom. Tick steps as you go — your progress is saved in this browser.
01 Discovery Agree scope, pipeline design and success criteria before touching data.
Objective A scope covering every object in the revenue model, with sales leadership signed up to the pipeline design.
Keep these open
-
Inventory every object in Pipedrive
Count accounts, contacts, leads, deals or opportunities, activities, notes, emails, files, products and quotes. Activity and email history is usually the largest object by an order of magnitude and the one people forget to size.
Data Profiler Get real record counts instead of estimating from memory -
Map the current pipeline and agree the target model
Document every pipeline, stage, probability and required field, then agree the HighLevel model with sales leadership. Migrating a broken pipeline faithfully is a wasted opportunity; redesigning it mid-migration is a wasted migration.
Stage changes alter historical conversion rates. Agree how you will restate reporting before you change the model.
-
Catalogue integrations and automation
List every system touching Pipedrive: marketing automation, quoting, billing, ERP, data enrichment, dialler, BI. Each is a separate cutover task with its own owner, and each can silently write bad data into your new CRM.
-
Capture the reporting that must survive
Interview the people who actually live in the dashboards — forecast, pipeline coverage, rep activity, cohort conversion. Every one of these needs the underlying fields to migrate, which frequently expands the scope.
-
Build the business case and pick the go-live date
Model licence delta, implementation effort and productivity dip. Then choose the date deliberately: mid-quarter is disruptive, quarter-end is worse. Most teams land on the first week of a new quarter.
COI & ROI Calculator Build the 36-month business case you will need for sign-off
Pipedrive → HighLevel specifics
- Pause all GHL automation workflows
- in the destination sub-account before any bulk load. Re-enable only after validation is complete.
Don't move on until
- Object counts confirmed for accounts, contacts, deals and activities
- Target pipeline and stage model agreed with sales leadership
- Reporting requirements captured from the people who use the reports
02 Data Audit CRM data is usually dirtier than anyone expects. Find out how dirty.
Objective A profiled export with duplicates, ownership gaps and relationship integrity all quantified and triaged.
Keep these open
-
Export and profile every object
Profile null rates, distinct values and type consistency across all objects. Pay attention to fields sales reps were supposed to fill in: an 80% null rate on a field your forecast depends on is a business finding, not a data one.
Data Profiler Profile the Pipedrive export for nulls, outliers and type drift -
Quantify duplicates and agree the merge policy
Measure duplicate accounts (same company, different spellings and suffixes) and contacts (same email, or same person at a renamed company). Agree survivorship rules before merging: which record wins, which fields, and what happens to the activity history on the loser.
Merging before you have agreed survivorship rules destroys history irreversibly. Decide first, merge second.
Data Cleaner Strip empty rows, stray whitespace and dead columns -
Verify relationship integrity
Check every deal has a valid account, every contact a valid account, every activity a valid parent. Referential breaks are the defect that turns a clean-looking load into a CRM where the pipeline report does not tie to the account list.
-
Resolve ownership and the user map
Build the Pipedrive user → HighLevel user map, including leavers. Every record needs a valid owner: records assigned to deactivated users either fail to load or land unassigned, and unassigned pipeline is pipeline nobody works.
Records owned by deactivated users are a top cause of load failures. Decide the reassignment target before you start.
-
Scan for PII and regional compliance
CRMs hold marketing consent, lawful basis and unsubscribe state. Confirm these fields migrate intact and that consent provenance survives — losing consent records is a regulatory problem, not a data-quality one.
PII & Compliance Scanner Find regulated fields before they land in a new system -
Clean, normalise and archive the pre-state
Normalise country and state values, phone formats, currencies and casing, and standardise all timestamps to UTC. Keep an untouched copy of the raw export — it is your only reference if a mapping decision turns out wrong.
Don't move on until
- Duplicate rate quantified per object with a merge policy agreed
- Every record has a valid owner mapped to a target user
- Relationship integrity verified — no orphaned deals or contacts
03 Field Mapping Map objects, relationships and picklists — in that order.
Objective A signed mapping spec that covers objects, relationships, picklist values and currency handling.
Keep these open
-
Map objects and their relationships first
Establish how Pipedrive objects correspond to HighLevel objects before any field work. Leads-versus-contacts, accounts-versus-organisations and deal hierarchies differ structurally between CRMs, and a field map built on the wrong object model has to be redone.
Schema Mapper Opens pre-loaded with the Pipedrive → HighLevel field pair -
Generate and then hand-review the field map
Auto-match both schemas, then review every row. Look hardest at anything named "type", "source", "stage" or "status", where names match and meanings do not.
-
Map every picklist value, including retired ones
Enumerate all values on both sides — deal stages, lead sources, industries, statuses — and map each explicitly, including values no longer offered but still present on old records. Unmapped values either fail the row or land as blanks that quietly break segmentation.
Historical records often carry picklist values that were retired years ago and no longer appear in the UI.
-
Decide currency, amount and date handling
If you sell in multiple currencies, confirm how HighLevel stores amounts, exchange rates and dated conversion rates. Recalculating historical deal values at today's rate silently rewrites your revenue history.
Multi-currency deals re-converted at current rates will not tie to your historical reporting or your finance system.
-
Determine the load order
Sequence the load so parents exist before children: users, then accounts, then contacts, then deals, then activities and notes. Keep source IDs in custom fields so relationships can be rebuilt by lookup rather than guesswork.
-
Freeze the spec and sign off
Version-control the mapping, walk RevOps and sales leadership through the decisions that change reporting, and get written sign-off before the pilot.
Don't move on until
- Object and relationship model mapped and reviewed
- Every picklist value explicitly mapped, including dead values
- Load order determined so parents always exist before children
04 Test Migration Pilot with related records, not a flat sample.
Objective A pilot load whose relationships, ownership and roll-up reporting all verify against source.
Keep these open
-
Configure the HighLevel sandbox to match the agreed model
Build the pipelines, stages, custom fields, record types and user roles first. Load into a default configuration and you will only discover the configuration defects at full scale.
-
Select a connected pilot slice
Take complete account trees — 50-100 accounts with all their contacts, deals, activities and files — rather than a flat random sample. Relationship defects are the whole point of a CRM pilot and a flat sample cannot expose them.
-
Run the load in dependency order with full logging
Load users, accounts, contacts, deals, then activities, logging every request against its source ID. Note which failures are transient (rate limits, timeouts) and which are structural (validation, missing parent).
-
Verify relationships and roll-ups
Confirm every deal sits on the right account with the right owner and stage, and that pipeline totals per account and per rep match Pipedrive exactly. Roll-up mismatches almost always mean a relationship or currency defect upstream.
Migration Validation Tool Diff the pilot batch against source before scaling up -
Measure throughput and project the full load
Record actual records-per-hour under HighLevel's API limits and extrapolate, remembering activity history usually dominates volume. If the projection exceeds your window, split the load or trim activity scope now.
-
Let reps work the pilot data
Put two or three reps in the sandbox against their own accounts. They spot missing context, wrong owners and unusable notes far faster than any reconciliation script, and their buy-in is what makes adoption work.
Don't move on until
- Relationships intact across the whole pilot slice
- Pipeline roll-ups match source for the pilot accounts
- Reps have worked pilot records and confirmed they are usable
05 Cutover Switch the revenue system with the pipeline intact.
Objective All in-scope CRM data live in HighLevel, integrations repointed, and reps selling on day one.
Keep these open
-
Pre-load history ahead of the freeze
Load closed deals, historical activities and inactive accounts while Pipedrive stays live. Only open pipeline and the final delta need to move inside the window.
-
Publish the cutover runbook
A timed sequence with owners and abort criteria: freeze, final export, delta load, integration switch, smoke test, go/no-go, rep enablement. Pick a window that avoids quarter-end and month-end close.
-
Freeze Pipedrive and take the final delta
Set Pipedrive read-only and export everything changed since the pre-load. Reps updating deals during an unenforced freeze is the classic way to lose the most recent — and most valuable — pipeline changes.
A rep who updates a deal in the old CRM during the freeze will lose that update permanently.
-
Load the delta and reconcile the pipeline
Run the delta, then verify open pipeline value and count per rep against Pipedrive before anything else. If the pipeline number is wrong on day one, reps stop trusting the system and never fully come back.
Migration Validation Tool Confirm the final delta landed before you reopen -
Repoint every integration and verify with real records
Switch marketing automation, quoting, billing, enrichment, dialler and BI connections, then push a live record through each path. An unrepointed integration writing into the old CRM causes divergence that gets harder to reconcile every day.
Two-way integrations left pointing at the old CRM will keep writing there. Disable them before you switch, not after.
Cron Expression Builder Schedule the delta syncs that run through the freeze -
Go/no-go, then enable the reps
Call the decision explicitly against the exit criteria. Run enablement on real data with their own accounts on screen, and keep Pipedrive read-only rather than cancelled until validation closes.
Don't move on until
- Historical load complete and reconciled before the freeze
- All integrations repointed and verified end to end
- Reps logged in with pipeline visible and correct
06 Validation Prove the revenue numbers tie out, then close the project.
Objective Reconciled data, forecast parity with pre-migration reporting, and signed acceptance.
Keep these open
-
Reconcile every object
Compare counts and values across accounts, contacts, deals, activities and files, plus field-level spot checks on a random sample. Produce a single report suitable for audit and for finance.
Migration Validation Tool Reconcile Pipedrive and HighLevel record-for-record -
Tie the pipeline and forecast to baseline
Rebuild forecast, pipeline coverage and win-rate reporting and compare to pre-migration figures. Every variance needs an explanation — most trace back to stage or currency mapping decisions made in Field Mapping.
Stage-model changes will legitimately shift historical conversion rates. Restate the baseline rather than chasing the difference as a defect.
-
Verify ownership, visibility and permissions
Confirm every record has the right owner and that sharing rules, territories and role hierarchy give each rep exactly the visibility intended. Over-broad visibility in a CRM is a data-protection issue as much as a config one.
-
Re-profile for field completeness
Compare loaded null rates against the source profile per field. A field that arrived empty while counts matched is the failure counts alone cannot detect.
Data Profiler Prove field completeness held up through the load -
Test automation and integration write-back
Fire every workflow, assignment rule, sequence and notification, and confirm each integration writes correctly in both directions. Automation is rebuilt rather than migrated, so it is unproven until observed.
-
Sign off and schedule decommission
Get written acceptance against the Discovery criteria, keep Pipedrive read-only for 30-90 days with a final archive export taken, then diarise cancellation so the contract does not auto-renew.
Don't move on until
- Full reconciliation report complete across all objects
- Forecast and pipeline reports tie to pre-migration baselines
- Acceptance signed and Pipedrive decommission scheduled
Field mapping reference
The field-by-field mapping for each object. Use this as the starting point for your mapping spec.
Entity GoHighLevel Entity
| Pipedrive field | HighLevel field | Notes |
|---|---|---|
| Organization | Company (API: Business) | Create first. A Contact can belong to only one Company. |
| Person | Contact | 1:1 mapping. Split name, map email, phone, address. |
| Deal | Opportunity (in Pipeline) | Map pipeline and stage. Must link to a Contact. |
| Lead (Leads Inbox) | Contact + Tag or early Pipeline stage | GHL has no separate Leads Inbox. |
| Activity (Call, Meeting, Task) | Task or Note | Completed → Note (preserves history). Open/future → Task. |
| Note | Note (on Contact) | Straightforward text migration. Preserve author and timestamp in body. |
| Product | Custom Object or custom fields | GHL has no native Products entity on deals. |
| File/Attachment | Attachment or external URL reference | GHL does not support bulk file import via API. |
| Custom Fields (40-char hex hash) | Custom Fields (Contact/Opportunity/Company) | Discover dynamically via /personFields, /dealFields, /organizationFields. |
Pipedrive GoHighLevel
| Pipedrive field | HighLevel field | Notes |
|---|---|---|
| Person.name | Contact.firstName / lastName | Split by first space |
| Deal.value | Opportunity.monetaryValue | Ensure currency alignment |
| Deal.stage_id | Opportunity.pipelineStageId | Map old stage ID → new GHL stage UUID |
| Activity.due_date | Task.dueDate | Convert to ISO 8601 UTC (see timezone normalization above) |
| Organization.address | Company.address | Parse into street, city, state, zip |
| Person.label | Contact.tags | Convert Pipedrive label to GHL tag |
Risk matrix
Per-object risk for this pair. Plan extra validation around anything marked high.
| Object | Risk | Notes |
|---|---|---|
| Contacts (Persons) | low | Person records map relatively cleanly to GHL Contacts with standard fields, though deduplication is needed when CSV exports create duplicate rows from organization fan-out. |
| Organizations / Companies | medium | Pipedrive Organizations must be mapped to GHL Companies (API: Business), but GHL only allows one Company association per Contact, which can break multi-org relationships. |
| Deals / Opportunities | high | Pipedrive Deals linked to both a Person and Organization simultaneously cannot be directly represented in GHL's single-Contact Opportunity model, requiring hierarchy decisions and potential data restructuring. |
| Pipelines and Stages | medium | Pipeline structures must be manually recreated in GHL before migration, and stage mappings need exact specification since GHL Opportunities require both a Pipeline and Stage assignment. |
| Activities | high | Pipedrive activities (calls, meetings, tasks) tied to Deals and Persons have no direct bulk import path in GHL and require API-level migration with careful association to the correct Contact and Opportunity. |
| Notes | high | GHL's CSV import limits notes to one per contact at 5,000 characters, meaning multi-note histories across Deals and Persons will be truncated or lost without API-based migration. |
| Custom Fields | medium | Pipedrive's hex-hashed custom field keys require a complete mapping table to GHL equivalents, and fields simulating pseudo-objects may need consolidation into GHL's 10 Custom Objects. |
| File Attachments | high | File attachments on Deals, Persons, and Organizations in Pipedrive cannot be transferred via CSV and require individual API extraction and re-upload to GHL Contacts. |
| Leads | medium | Pipedrive Leads live in a separate Leads Inbox and cannot be exported or converted via API, requiring manual conversion to Deals before extraction or alternative handling. |
| Products | medium | Pipedrive Products linked to Deals have no direct equivalent object in GHL's standard CRM entities, requiring mapping to custom fields, Custom Objects, or external product catalogs. |
The hard parts
What makes this specific migration difficult, beyond the mechanics.
Deal-Centric to Contact-Centric Translation
Pipedrive's Deals link simultaneously to both a Person and an Organization, but GHL Opportunities tie to a single Contact, requiring a deliberate decision on primary record ownership and bottom-up hierarchy reconstruction.
Custom Field Key Mapping
Pipedrive assigns each custom field a random 40-character hex hash as its API key, requiring a complete field-mapping specification to translate these into GHL's custom field schema.
API Rate Limit Coordination
Pipedrive's token-based rate limiting shares a daily budget across all users and integrations, while GHL enforces a strict 100-request-per-10-second burst limit, making unthrottled bulk migration scripts prone to 429 errors and data corruption.
Activity and Note History Loss
GHL's CSV importer caps imported notes at one per contact with a 5,000-character limit and cannot import file attachments, meaning historical activity data requires API-level migration to preserve.
Custom Object Schema Constraints
GHL imposes a hard limit of 10 Custom Objects per sub-account with incomplete feature parity across email campaigns, funnels, calendars, and payments, requiring consolidation of Pipedrive's pseudo-object custom field groups.
Company/Business API Naming Mismatch
GHL's UI labels the entity 'Company' but the API uses 'Business' and 'businessId', creating a naming discrepancy that causes mapping errors if not documented from the start.
What breaks
Known failure modes. Have a recovery plan for each before you cut over.
Duplicate contacts
Pipedrive allows duplicate Persons with the same email. GHL deduplicates on email by default — your second import will silently update the first record instead of creating a new one. GHL's upsert follows the location's duplicate settings: if email and phone match different existing contacts, GHL updates the contact matching the first configured field. Freeze dedupe rules before test and production runs. (marketplace.gohighlevel.com)
GHL deduplication configuration
GHL's deduplication behavior is configured at the location level, not globally. The relevant settings control which fields are used for matching (email, phone, or both) and whether an incoming record upserts an existing match or creates a new record. The default behavior is to upsert on email match. If you change these settings mid-migration, your import outcomes will be inconsistent across runs. Lock the deduplication configuration before your dry run and do not change it until validation is complete. Document the exact settings used — if a duplicate issue surfaces weeks later, you need to know what rules were active during the load.
Multi-org contacts
A Pipedrive Person can be linked to an Organization, but in GHL a Contact can only belong to one Company. If a person has deals across multiple organizations, pick a primary or create separate contact records.
Multi-person deals
Pipedrive allows a Deal to be associated with multiple Persons. GHL Opportunities tie to a single primary Contact. Decide whether to duplicate the Opportunity for secondary contacts or strictly enforce a single primary.
Pipedrive Leads
The Leads Inbox is a separate entity type. Leads share DealFields and can only be converted to Deals in the Pipedrive web app — not via API. Do not design a source-side API conversion step that does not exist. GHL has no Leads Inbox, so convert these to Contacts with a distinguishing tag (e.g., pipedrive-lead) or place them in an early pipeline stage. (pipedrive.readme.io)
Activity types
Pipedrive supports custom activity types (Call, Meeting, Email) with dedicated fields. GHL simplifies this into Tasks, Appointments, and Notes. You'll lose granularity unless you encode the activity type into a tag, custom field, or the note body.
Email activity history and GHL Conversations
Pipedrive email activity history does not map cleanly to GHL Conversations. GHL Conversations is a separate object type — it represents messaging threads (email, SMS, chat) with their own UI and API surface. Pipedrive emails logged as Activities will not automatically appear in GHL Conversations after migration. The most reliable approach is to convert Pipedrive email Activities into timestamped Notes on the Contact, with the activity type, subject, and direction encoded in the note body. Accept that the Conversations UI will show a clean slate post-migration and document this gap explicitly for your sales team before cutover.
File attachments
GHL does not support bulk file import via API. Files attached to Pipedrive deals or contacts must be downloaded from Pipedrive, then uploaded to GHL's media library or stored externally with links added as notes. Pipedrive's global export does not include files stored in Google Drive.
Products on deals
Pipedrive's Products entity tracks line items on deals. GHL has no native product-on-deal concept. Use Custom Objects (if you have capacity within the 10-object limit) or encode product data into Opportunity custom fields.
Notes via CSV
GHL's CSV import supports only one note per contact record with a 5,000-character cap. If your Pipedrive contacts have dozens of notes each, CSV is not viable for history preservation. (help.gohighlevel.com)
Tools used in this playbook
All free, all run entirely in your browser — nothing is uploaded.
FAQ
Can I migrate Pipedrive data to GoHighLevel using CSV?
Yes, but CSV only transfers flat records. It destroys relationships between Persons, Organizations, and Deals, drops activity history, and limits imported notes to one per contact with a 5,000-character cap. CSV is viable only for small datasets under 1,000 records where relationship integrity is not needed.
What are the API rate limits for Pipedrive and GoHighLevel?
Pipedrive uses Token-Based Rate Limiting with a daily budget of 30,000 base tokens × plan multiplier × seats, plus burst limits on a rolling 2-second window. GoHighLevel API v2 enforces a burst limit of 100 requests per 10 seconds and a daily limit of 200,000 requests per Marketplace app per resource.
How do Pipedrive Deals map to GoHighLevel?
Pipedrive Deals map to GoHighLevel Opportunities, which live inside Pipelines. Each Opportunity must be linked to a Contact and placed in a specific Pipeline Stage. You need to recreate your Pipedrive pipeline stages in GHL before importing and use an ID crosswalk to preserve deal-to-contact associations.
Does GoHighLevel support custom objects for a Pipedrive migration?
Yes. GoHighLevel supports Custom Objects on all plans (Starter, Unlimited, Pro) with a hard limit of 10 Custom Objects per sub-account and up to 10 unique labels between objects. Some GHL surfaces (Email Campaigns, Bulk SMS, Funnels, etc.) do not yet fully support Custom Object data.
How long does a Pipedrive to GoHighLevel migration take?
A CSV-based migration for a small dataset takes hours. An API-based migration for 10K–50K records with relationship preservation typically takes 2–4 weeks of engineering effort if built in-house, or 3–7 days with a managed migration service that has pre-built tooling for both APIs.