Legacy data import
The hardest part of a CRM project is usually the first part.
“Our data has been a mess since the last system, and nobody wants to touch it.” That sentence is why most CRM projects stall before they start. The new pipeline, the new stages, the new automations: none of that matters if the old records do not make it across cleanly.
Why it goes wrong
Why imports go wrong
Pipedrive is unforgiving about exact matching. It links records by name, not by judgment. A value that looks identical to a person can be a mismatch to the system, and the failure is often silent: no error, just a duplicate record or a link that never forms.
| What is in the file | What is already in the account | What Pipedrive does |
|---|---|---|
| Rene Levesque | René Lévesque | Treated as a different name. Creates a duplicate record instead of matching. |
| O’Brien Group (curly apostrophe) | O'Brien Group (straight apostrophe) | Fails to match. A second, stub organisation gets created. |
| "Acme Inc. " (trailing space) | Acme Inc. | Reads as a distinct value. No link, no warning. |
| john smith | John Smith | Case difference on an owner name means the record can land unassigned or under the wrong user. |
Owner names, pipeline names, stage names, organisation names: every one of these has to match what already exists in the account, character for character, or the import quietly builds something wrong instead of stopping to ask.
Order of operations
Organisations, then people, then deals
Pipedrive links records to each other by exact name, which makes import order a real constraint, not a formality. Organisations go in first, then people are linked to those organisations, then deals are linked to both. Import a deal before its organisation exists and Pipedrive does not wait. It creates a stub organisation on the spot, and now there are two records where there should be one.
The same rule applies to file structure: Pipedrive's import ingests one entity type per file. A workbook with an Organisations tab, a People tab, and a Deals tab has to be split into three files before any of it goes in.
Method
How we work
Verify before loading
We list back every value that has to match an existing record (owners, pipelines, stages, organisation names, dropdown options) and have the client check each one against the live account. Catching a mismatch on a list is free. Catching it after import means cleaning up duplicates.
Dry run first
The data goes into a test account before it goes anywhere near production. The client sees what it will actually look like (which fields are empty, which names did not match) while it still costs nothing to fix.
Decide on the gaps deliberately
Old systems rarely capture what Pipedrive expects to show: deal value, expected close date, stage. Left blank, the CRM looks dead on day one and nobody trusts it. We flag these gaps and ask the client how to handle each one rather than leaving them blank by accident.
Clean before the move
A five-year-old database is commonly 20–30% duplicates. Cleaning it before the move is the difference between a CRM people use and one they abandon.
Honest limits
What we cannot fix
Data that was never captured cannot be recovered. If the old system never recorded a deal's origin, no import script will invent one. And when two records in the old data plainly describe the same person or company but disagree on the details, deciding which version is correct is a business decision, not a technical one. We can surface the conflict clearly, but the client has to make the call.
Part of the job is telling you when the answer is no.
Next step
Start with the data that is worrying you
Bring the export, the spreadsheet, or just a description of what the old system holds. I will tell you what will and will not move cleanly, before anything touches Pipedrive.