Preconditions
Do not start the procedure until all six are true. Each one that is false will surface later as rework, and it will surface after the data has moved.
- A full export of the source system exists, per object, in a format you can reopen. Not a report, not a filtered view. Everything.
- The target account has its pipelines, stages and custom fields already built. Migration into an unconfigured account creates fields on the fly and you inherit the mess. See custom fields for how to decide that up front.
- A written field map exists: source field, target field, transformation, owner of the decision. Anything unmapped is explicitly marked as dropped, with a name against it.
- Every source record has a stable identifier that will be written into a dedicated field in Pipedrive. This is what makes reconciliation and a second pass possible.
- Users exist in the target account with the same names, so ownership maps cleanly. An unmapped owner defaults to whoever runs the import, and that ruins every report by rep.
- A freeze window is agreed with the business, in writing, with a date. Not a preference. A date.
The procedure
Step 1. Profile the source
Count everything before you touch anything. Records per object, records per owner, records per status, empty rates per field. Write the counts down.
Verify: you have a single table of source counts, dated, that every later step is compared against. If you skip this, you have no definition of success.
Step 2. Resolve the data model
Map source objects onto the Pipedrive model of leads, people, organisations, deals and activities. Custom objects and record types in the source have no direct equivalent, so each one becomes a field, a pipeline or a dropped concept. Decide which, per object. The data model entry sets out the target shape.
Verify: no source object is unassigned, and every drop is recorded with a reason.
Step 3. Clean at source, not in flight
Deduplicate, normalise phone numbers and close dead records before the export, in the system that still owns them. Cleaning during the import means your reconciliation counts will never match and you will not know whether a gap is a bug or a cleanup.
Verify: re-run the step 1 profile. The delta between the two counts is explainable line by line.
Step 4. Dry run into a sandbox
Import a representative slice into a separate account or a test pipeline. Take the awkward cases deliberately: the customer with eight contacts, the deal with forty activities, the record with accented characters and a comma in the company name.
Verify: open ten records by hand and compare them field by field against the source. Not a sample of one.
Step 5. Import in dependency order
Organisations first, then people, then deals, then activities, then notes and files. Each object carries the source identifier. Each object references its parent by that identifier rather than by name.
Verify: after every object, count. Records created plus records skipped must equal records submitted. A missing row that nothing reports is the failure mode this step exists to catch.
Step 6. Reconcile relations
Counts matching does not mean relations survived. Query for the orphans directly: deals without an organisation, people without an organisation, activities without a deal, organisations with zero people.
Verify: each orphan filter returns zero, or returns a number you can explain from the source. Explainable is acceptable. Unexplained is not.
Step 7. Reconcile value
Sum open pipeline value per stage, and won value per quarter, in both systems. This is the check that catches currency mistakes, decimal separators read as thousands, and deals landing in the wrong pipeline.
Verify: totals match to the cent, or the difference is traced to named records. A rounding excuse is not a trace.
Step 8. Cut over
Freeze the source, run the final delta import for everything created during the dry run period, then switch the team. Set the source to read only the same day, and keep it that way for a quarter.
Verify: five reps each open their own top three deals on day one and confirm what they see. Their confirmation is the acceptance test, not yours.
Reconciliation table
| Step | Measure | Pass condition |
|---|---|---|
| 1 | Source counts per object | Written down and dated |
| 3 | Counts after cleanup | Delta explained line by line |
| 5 | Created plus skipped | Equals submitted, per object |
| 6 | Orphan filters | Zero, or explained from source |
| 7 | Open and won value | Matches to the cent |
| 8 | Rep confirmation | Five reps, three deals each |
When this manual is more than you need
One spreadsheet of a few hundred rows does not need eight steps. Clean the columns, split the file per object, use the standard importer and check twenty records by hand. That route is written up in the spreadsheet guide, and it is a morning of work, not a project.
The full procedure earns its cost when the source is a real CRM with relations, history and attachments, which is the case in a HubSpot move or a Salesforce move. It also earns it when more than one source is merging into one target, because then reconciliation is the only thing standing between you and a duplicate problem on day one.
Last note, and it is the one people ignore. Budget more time for mapping than for importing. The import is a machine operation. The mapping is a set of business decisions about what your company will remember, and those decisions cannot be made in the freeze window.