Start with an honest inventory
Before you export a single row, list what your Salesforce org actually contains. Standard objects. Custom objects. Record types. Validation rules. Reports that someone reads. Apps installed from the marketplace.
Then mark each item with one word. Keep, replace, or drop. In most orgs we review, half of the configuration is dropped without anyone missing it. It was built for a process that ended years ago.
This inventory is the project. The import itself is a day of work at the end.
Object mapping
| Salesforce | Pipedrive | Notes |
|---|---|---|
| Account | Organization | Account hierarchies flatten. Use a field for parent. |
| Contact | Person | Linked to one organisation. |
| Lead | Lead in the Leads Inbox | Conversion becomes deal creation. |
| Opportunity | Deal | Stages map manually. Products map to products. |
| Task and Event | Activity | Types are configurable in Pipedrive. |
| Custom object | Fields, second pipeline or projects | Requires a decision per object. |
The four hard parts
Custom objects
There is no like for like replacement. In practice, custom objects become one of four things. Extra fields on the deal, when the data is one to one. A second pipeline, when the object has its own stages. A project, when it describes delivery after the sale. Or it stays in the system it belongs to, such as an ERP.
Record types and page layouts
Pipedrive has no record types. Different fields per deal type is handled with visible conditions on fields, or by accepting a slightly larger field set. This usually simplifies rather than limits, but it needs a conscious decision per type.
Permissions
Salesforce permission models are deep. Pipedrive offers visibility groups and permission sets that cover most needs, but not every rule you can express in Salesforce.
Write your five real permission requirements as sentences. Almost always they are simpler than what the old system enforces.
Reports
Export a list of Salesforce reports with their last run date. The ones nobody opened in six months do not need to exist again. Rebuild the rest in Pipedrive insights, and design the fields to support them before import.
Export and import order
Use the Salesforce data export or a report export per object. Keep the record IDs in a column. You will need them to rebuild relations, and later to trace a record back.
Import in this order. Users first, so ownership resolves. Then organisations. Then people. Then open deals. Then closed deals within your cut off. Then activities and notes.
Set a cut off before you start. Open opportunities, closed won from two years, and the accounts and contacts attached to them. History beyond that is better kept as an archive export.
Testing before go live
Test with a slice of the business, not a random sample. Take one team, all of their open deals, and run a full week of real work in the new system while Salesforce stays read only for them.
A week of real use finds more problems than a month of review meetings. Fix what appears, then move everyone in one cut over.
Cost and timing
A Salesforce migration for a team of twenty to fifty usually runs eight to fourteen weeks and costs between 12,000 and 25,000 euro, with integrations on top. The variable is never the import. It is the number of decisions and the number of people who must make them.
See the cost page for the full breakdown, and how to choose a partner if you are comparing suppliers for this work.
Questions
Is Pipedrive powerful enough after Salesforce?
For most sales teams under a hundred people, yes. You lose custom objects, deep permission layers and heavy automation. You gain speed and adoption. Judge it against the features you actually use.
What happens to Salesforce custom objects?
There is no direct equivalent. Each custom object becomes either fields on a deal, a second pipeline, a project, or data that stays in another system. Decide this before exporting anything.