Migration
Salesforce to Pipedrive migration service
Most teams making this move are not chasing features. They are leaving a per-seat licence, a sandbox and a standing admin bill behind, and the price of that is deciding where every custom object, record type, validation rule and Apex trigger goes when the destination has no slot for any of them.
The mechanics
What in a Salesforce org has no equivalent on the other side?
Custom objects, record types, formula and roll-up fields, validation rules, Apex, approval processes, joined reports and the sharing model. Accounts, contacts, opportunities, products and activities all have a destination. Everything in the first list is business logic that has to be re-expressed, re-homed, or deliberately retired before an export runs.
Start with why the move is happening, because it sets the budget for everything else. The saving on this crossing is not only the difference between two subscriptions. It is the sandbox, the integration user licences, the managed packages nobody has audited in two years, and the part of somebody's week that goes on keeping the org coherent. That last one is the real number, and it is also the reason the destination has to stay simple: a Pipedrive account rebuilt to feel like the org you left reproduces the cost you were trying to escape. Every artefact below is therefore a decision about whether it earns its place, not a mapping exercise.
Custom objects are the first thing to stop pretending about. Salesforce lets you invent a record type for anything — properties, matters, installations, contracts, shipments — and relate it to the standard objects. Pipedrive has a fixed set of records: leads, people, organisations, deals, products and activities, plus projects on the relevant plan. You cannot add another. So each custom object lands as a block of custom fields on the record it hung off, as its own pipeline if the records genuinely progress through stages, or in a system outside the CRM joined back by a stored identifier. Making that call artefact by artefact, in writing, before the export, is the single highest-value hour in the project.
Record types and page layouts collapse into one shape. In Salesforce a record type changes which picklist values and which layout a user sees on the same object, so New Business and Renewal opportunities can behave nothing alike while sharing a table. Pipedrive shows one field set per record type, with visibility controlled at the field level rather than by layout. In practice a record type becomes a separate pipeline, a label, or a single custom field that other logic reads — and if it was only ever there to hide fields from a team, it becomes nothing at all.
Derived and defended values stop being either. Formula fields and roll-up summaries compute on read; Pipedrive stores what you put in it. Each one is either frozen as a static value at cutover, recomputed by an automation when its inputs change, or calculated outside the CRM and written back. Validation rules go the same way. Pipedrive can require specific fields before a deal enters or leaves a stage, which covers the common "do not advance without a close date" rule well. It cannot evaluate an arbitrary expression against a related record on save, so those rules move to whatever creates the record, or they stop existing — which, for a good number of them, is the honest outcome.
Matching is riskier here than on a move into a suite. Salesforce does not enforce unique emails, and Pipedrive does not deduplicate people on email or organisations on domain either. Two systems with no uniqueness constraint means a load run twice, or a delta load that overlaps the first, silently creates a second copy of everyone. The defence is a custom field on every Pipedrive record holding the Salesforce record ID — the 18-character case-safe form, not the 15-character one — populated straight from the extract. Reconciling then becomes a join rather than a spot check, and any integration you keep has something stable to point at. Extraction itself is ordinary work through Salesforce's Bulk API (opens in new window), and it is the only part of this page nobody argues about.
| Salesforce artefact | How Salesforce models it | Where it lands in Pipedrive | The decision it forces |
|---|---|---|---|
| Lead | Its own object, converted once into account, contact and opportunity | A lead in the Leads Inbox, which converts into a person, organisation and deal | Which lead statuses arrive as inbox leads, which arrive as people with a label, and which are archived rather than imported |
| Account | A record with hierarchy, sharing rules and its own field set | An organisation, with a parent-child relationship available but no sharing model behind it | Whether account hierarchies are worth reproducing, and how near-duplicate names are stopped from doubling |
| Contact | Belongs to an account, and can relate to several through account contact relationships | A person linked to one organisation | Which organisation is primary for each contact, and where the other relationships are recorded |
| Opportunity, price book and line items | Stages with probability, products drawn from a price book, optional quoting on top | Deals in pipelines with a probability per stage, and products attached from a catalogue | Whether the product catalogue is rebuilt first so line items survive, or deals collapse to a single value |
| Custom objects | Purpose-built records with their own fields, relationships, layouts and tabs | No equivalent — the set of record types is fixed | Custom fields on an existing record, a pipeline of their own, or a system outside the CRM keyed by identifier |
| Record types and page layouts | Different layouts and picklist values on the same object, assigned by profile | No equivalent — one field set per record type | Whether each record type becomes a pipeline, a label, a field, or nothing |
| Formula and roll-up summary fields | Values computed on read, including across related records | Plain custom fields holding whatever was last written to them | Which derived values must stay live — and therefore need an automation or an outside job — and which freeze at cutover |
| Validation rules | Arbitrary expressions evaluated on save, blocking the record | Required fields enforced per deal stage | Which rules re-express as stage requirements, which move upstream to the form or integration, and which are retired |
| Flow, Process Builder and workflow rules | A declarative engine with branching, scheduled paths and record-triggered starts | Automations: an event trigger, conditions, and a short list of actions | Which rules rebuild as-is, which simplify, and which were only compensating for a field that should not exist |
| Apex triggers, classes and scheduled jobs | Custom code running inside the platform, with tests and governor limits | No equivalent at any level | What that code was actually holding together, and which automation platform now owns it |
| Approval processes | A record lock plus routing through named approvers, with recall and escalation | No record-locking mechanism; approval is expressed as a stage, a field and an activity | Whether an approval genuinely needs to block progress, or only needs to be recorded and chased |
| Reports, custom report types and dashboards | A report builder over any object graph, including joined and matrix reports | Insights: filters, reports and dashboards over the records Pipedrive actually has | Which named reports must exist on day one, and which measured something that will no longer be stored |
| Profiles, roles, permission sets and sharing rules | Record-level visibility derived from a role hierarchy and sharing settings | User permission sets and visibility groups, with a much flatter model | Which restrictions are genuinely required, and which were an artefact of the hierarchy itself |
| Campaigns and email opt-out | Campaign membership per contact, plus an opt-out flag on the record | One marketing status per person, and a label or field for campaign provenance | How several Salesforce states collapse into one status without anyone opted out becoming contactable |
| Chatter, field history and time in stage | A per-field change trail and a record-level conversation feed | No destination — Pipedrive records its own history from cutover onward | How long the old org stays readable, and which historical numbers are exported before it closes |
The org is a contract before it is a database. The technical cutover date and the subscription end date are different dates, and the second one is the unforgiving one: once a Salesforce subscription lapses, the org is no longer somewhere you can log in and run the export you forgot. Read the renewal and termination terms at the start of the project, not the end, and treat "everything we will ever want out of here" as a deliverable with its own sign-off while the org is still open.
Sequence
How does an enterprise org become a working sales pipeline?
Decide what stops being tracked
Every custom object, record type and validation rule gets a named destination or an explicit retirement. The list is the first deliverable, and it is signed off before a single row is extracted.
Build the pipeline before the load
Pipelines, stages, probabilities, required fields, custom fields and every option value created first. Import into a field that does not exist yet and the value is dropped without an error.
Sample load, reconcile on the Salesforce ID
A few hundred records, joined back on the stored 18-character ID. Neither system enforces uniqueness, so this is where doubles surface while they are still cheap to remove.
Remodelling stages: rot, probability and fewer pipelines than you have now
This is the part worth doing properly rather than copying. Salesforce sales processes plus record types often leave an org with more distinct paths than the business actually sells through, because each one was cheap to add. Pipedrive rewards the opposite instinct: a small number of pipelines, stages defined by an exit criterion a rep can answer yes or no to, a probability set per stage, and — with no Salesforce equivalent at all — a rotting threshold per stage that flags a deal after a set number of idle days. That last setting quietly replaces a family of Salesforce reports and reminder rules, and it only works if the stages are few enough to mean something. Old stage names are mapped onto new ones in the import file so historical deals still land somewhere sensible.
What Apex was holding together, and where it goes now
Salesforce splits its logic across a declarative layer and a code layer, and the second one is where the surprises live. Read the triggers before promising anything: some are enforcing a data rule that becomes a stage requirement, some are computing a roll-up, and some are quietly integrating with billing, provisioning or an ERP on a nightly schedule. Pipedrive Automations handle the first category comfortably — an event fires, a condition is checked, a few actions run. They are not built for the third. Logic that has to retry, reconcile two systems that both claim to own a field, call an API with credentials, or read unstructured text and decide something belongs outside the CRM in a platform you own and can see the logs of, which is the subject of our workflow automation work. Naming that destination during the mapping phase is what stops the migration turning into an unplanned search for a second tool halfway through.
Report parity, stated as a list rather than a promise
"The reports will still work" is the commitment most likely to be broken on this crossing, because Salesforce reporting spans objects that are about to stop existing. The workable version is a named list: the reports leadership actually opens, agreed up front, each one traced to the fields that feed it. Most pipeline, activity and forecast views rebuild in Insights and are easier to read afterwards. Joined reports, custom report types over a custom object, and anything measuring duration or change rather than current state do not survive — and those numbers are exported and archived while the org is open, because they cannot be reconstructed later.
Consent, campaign history and the first send from the new account
Opt-out is the one mapping with a legal edge on it. A Salesforce record can carry an opt-out flag alongside campaign membership and, often, a second unsubscribe state held by whatever tool did the sending. Pipedrive expresses the obligation as a single marketing status per person. Collapsing several states into one is exactly where a suppression gets lost, so each source state is exported, the mapping is written down, and the loaded result is reconciled as its own count against the baseline in the FTC's CAN-SPAM compliance guide (opens in new window). Nothing sends until those numbers agree.
Cutover, the read-only lookback, and disposing of the extract
Cutover runs one pipeline at a time, not all at once. Counts are compared in both directions on the stored Salesforce ID, consent counts are compared separately, and a delta load picks up whatever was created during the freeze. At the same moment the outside world has to be repointed: web-to-lead forms, mailbox and calendar connectors, the quoting or billing integration, and any middleware still writing to the org. Miss one and the migration never finishes, because records keep appearing in the system nobody is watching. One step gets skipped almost every time: the extract is a complete copy of your customer database, and it is now on a laptop, in a shared drive, and probably in an email attachment. Destroying those working files at the end of the project, everywhere they were copied, along the lines of NIST's media sanitization guidelines (opens in new window), is part of the work.
Where this sits next to the rest of the work
If you are leaving Salesforce but want a marketing suite rather than a pure pipeline, the destination is probably not Pipedrive, and our Salesforce to HubSpot migration page covers that crossing instead — same source org, a destination with custom objects of its own, and therefore a completely different set of decisions. If you are already on HubSpot and shrinking to a pipeline, the mapping problem is the collapse of many-to-many associations rather than the loss of custom objects, and our HubSpot to Pipedrive migration page covers that direction. Going the other way — outgrowing Pipedrive and moving up into HubSpot — is the mirror image again, handled on our Pipedrive to HubSpot migration page. Once you have landed and the question becomes how the account should be built — stage design, Automations, field hygiene, API work — that is our Pipedrive automation consulting page. The generic order of operations that every CRM move follows is set out on the CRM migration services page, and how engagements work explains how a scope gets agreed before any of it starts.
The honest part
Is a plain sales pipeline actually enough after an enterprise org?
For a team that sells rather than administers, usually yes — and the relief is real, because most of what was being maintained was never being used. For a business whose operations genuinely run on custom objects and code, no, and you should hear that on the first call rather than three weeks into a mapping exercise.
| What | Treatment | Why |
|---|---|---|
| Account, contact and opportunity field values | Moves | They load cleanly once every destination field and option value exists on the Pipedrive side first |
| Open pipeline and stage position | Moves | Stage, value, expected close date and owner land on a deal once pipelines and users have been created |
| Tasks, events, calls and logged emails | Moves deliberately | They attach as activities and notes on the matching record, which is worth doing for open business and rarely for all history |
| Products, price book entries and line items | Moves in order | The catalogue is rebuilt first, then products attach to deals — the other way round and the lines have nothing to reference |
| Custom objects | Re-homed | Pipedrive's record types are fixed, so each becomes fields, a pipeline, or a record in a system built for it |
| Record types, page layouts and sharing rules | Redesigned | A flatter model with one field set and visibility groups; most of the complexity turns out to have been organisational, not functional |
| Validation rules and approval processes | Re-expressed or retired | Stage requirements cover the common cases; record locking and arbitrary save-time expressions have no counterpart |
| Flow, Process Builder and workflow rules | Rebuilt | A different execution model — an event with conditions and a few actions, rather than a branching declarative canvas |
| Apex, scheduled jobs and managed packages | Re-homed or retired | None of it runs in Pipedrive, so the logic worth keeping moves to an automation platform and the rest is switched off on purpose |
| Formula and roll-up summary values | Frozen or recomputed | Pipedrive stores values rather than deriving them, so each field is either static at cutover or maintained by something |
| Reports and dashboards | Rebuilt selectively | Pipeline and activity reporting rebuilds in Insights; anything spanning a retired object or measuring change does not |
| Field history, time in stage and Chatter | Stays behind | The change trail belongs to the org that recorded it, and Pipedrive starts its own history at cutover |
| Web-to-lead forms, connectors and integrations | Replaced | Anything still calling the old org keeps creating records there after cutover, and nobody notices for weeks |
You own the result outright: records in your own Pipedrive account, Automations documented against the event that starts them, a field map showing where every Salesforce field went, and a written note of what was deliberately left behind and why. If your own team would rather run the load, we will build the map and the scaffold and stay on as backup. And if the honest answer on the call is that the org is fine and the real problem is how it has been configured, that is what you will hear.
Questions
What teams ask before shutting an org down
Where do Salesforce custom objects go in Pipedrive?
Nowhere directly — Pipedrive has a fixed set of record types and you cannot add another one. Each custom object gets one of three destinations, chosen deliberately: a group of custom fields on the deal, person or organisation it hung off; its own pipeline if the records genuinely move through stages; or a system outside the CRM, joined back by a stored identifier. Anything with more than a handful of fields is usually the third.
Do validation rules and required fields survive the move?
Partly. Pipedrive can mark custom fields required for a deal to enter or leave a given stage, which covers the most common shape of validation rule — do not let this advance without that. What has no counterpart is the arbitrary formula evaluated on save, especially one that reads a related record. Those rules are either re-expressed as stage requirements, moved into whatever creates the record, or consciously dropped.
What happens to Apex triggers, Flows and Process Builder?
Each one is read and given a destination by hand; there is no converter and there could not be. Simple record-triggered logic becomes a Pipedrive Automation, which fires on an event, checks a condition and runs a short list of actions. Apex, scheduled jobs and anything needing real retries or a call to another system have no home inside Pipedrive and move to an automation platform you also own.
Can we keep our Salesforce reports and dashboards?
The pipeline and activity reporting rebuilds in Pipedrive Insights and is usually quicker to read afterwards. Joined reports, custom report types and anything spanning a custom object do not, because the underlying objects will not exist. Report parity is agreed as a list of named reports before the project starts, and whatever will not survive is exported and archived while the org is still open.
Do we have to cancel Salesforce on cutover day?
No, and you should not. The org stays live and read-only for a lookback period, because field history, Chatter and report snapshots do not migrate and are still worth opening. Cancelling is a separate, contractual decision with its own date — check the renewal terms early, because once the subscription lapses you cannot log back in to run the export you forgot.
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.
Weighing a different destination? See the CRM migration services overview.