Monday morning, in the new system
A rep opens the account she has been working for eight months. The company is there. The deal is there and the amount is right. What is missing is the reason it is still open: the note from March explaining that the budget moves to the new financial year, the call that went badly, the name of the person who actually decides. She has a record and no memory, and the customer is expecting her to have both.
Meanwhile the administrator has a report showing the import succeeded. Organisations in, persons in, deals in, counts reconciling against the export. Nothing errored. Both people are looking at the same migration, and both are right.
That is the shape of almost every migration that goes wrong. Rows survive. Relationships do not. And nobody notices until somebody needs the relationship, which is always in front of a customer and never during the project.
History is links, not rows
It helps to be precise about what you are trying to keep, because the word history hides four different things.
Attachment. A note belongs to a company or to a deal. In a pile it is text. On the record it is context, available to whoever picks the account up next.
Sequence. Activities carry their original dates, so you can see that a deal sat untouched for two months. Import them all with today's date and the account is technically complete and analytically worthless.
Ownership. Every record has somebody answerable for it. When owners are not mapped, deals land on whoever ran the import, and an account nobody recognises as theirs is an account nobody works.
Outcome. Won and lost, with the reason and the date. This is the part teams discover last, usually the first time somebody asks why last year cannot be compared with this one. What lives where, and why the shape of the target account decides how much of this survives, is on the data model page.
What you can do yourself
More than vendors like to admit. If you have one pipeline, a modest number of custom fields and nothing automated waiting on the other side, an export and an import is a reasonable plan, and we have told people so.
Do it in dependency order. Organisations first, then persons attached to them, then deals attached to both, then activities and notes attached to the deals. Keep the identifier from the old system in a field of its own on every object, because that column is the only thing that lets you reattach anything afterwards, and it is the first thing a spreadsheet round trip destroys. Move a small sample before the full set, and open the records rather than the row counts. The step by step version, including the reconciliation, is on the migration manual, and the spreadsheet case has its own page at migrating from spreadsheets.
Where it stops being an export problem
Four things turn a manageable job into an expensive one, and they compound.
Fields that do not correspond. A picklist value that does not exist in the target, a date format that reads differently, a currency field carrying amounts in three currencies. Each needs a decision, and there are usually more of them than the first look suggested. The system specific patterns are on the HubSpot and Salesforce pages.
People who left. Old systems are full of owners who are not employees any more. Every one of them needs a rule, and the rule is a business decision rather than a technical one, because it determines who gets called about those accounts.
Records that already existed twice. A migration is a merge as often as it is a move, and the duplicates you carry across multiply against whatever is already in the target. Deal with the ones you know about before you move, not after, which is the argument on the duplicates page. Finding them and joining them are separate steps, and the joining is reviewed by a person first, because it cannot be undone.
No rehearsal. The others are survivable on their own. What makes them expensive is finding out about them while the team is already working in the new system, because from that moment every correction has to preserve work done since the import.
What we built for this
At Sales Surge we implement Pipedrive and build our own software around it, because implementation work kept running into the same walls. Migration is the wall that arrives before anything else can start, and the one where a bad week costs the most, because the team is trying to sell out of a system it does not yet trust.
Surge Shift is our own product. Scope and mapping first, so it is written down which objects and which fields travel and what they are called on arrival. Then a dry run in a staging environment with the full set, which produces a report of what did not fit: the values with no home, the owners who no longer exist, the records that matched nothing. You make those decisions while they are still cheap. Then the live move at an agreed moment, with checks afterwards and a way back. It is described on the Surge Shift product page, with everything else we make at the Sales Surge product overview.
The reason we insist on the rehearsal is not caution for its own sake. It moves every awkward decision to a point where changing your mind is free. We would rather hand you a list of things that did not fit before you go live than explain them afterwards. We are a Pipedrive Platinum Partner and have been in the global top 8 since July 2026, and this is the part of the work where that experience shows up as a list of questions rather than as speed.
When you do not need this
If the old system holds a few hundred records, one pipeline and no history worth the name, do it yourself with the manual and spend the money on the setup instead. The target account is what you will live in. A careful migration into a careless setup is effort spent in the wrong place.
There is a harder case, and it is worth saying out loud. Sometimes the right answer is not to bring it. If the old data was never maintained, migrating it imports a problem and gives it a fresh start date. Bring the open deals and the accounts you actually trade with, archive the export somewhere you can read it, and begin clean. The overview of routes into Pipedrive is on the migrations hub.
And if you are joining two Pipedrive accounts rather than coming from another system, that is a different job with different risks, covered on the consolidation page. The full list of what we build, including the parts we tell people to skip, is on the product page.
Questions
The record counts match after the import. Did it work?
It tells you the rows arrived. It says nothing about whether they are still attached to each other, which is the part people actually mean by history. Counts are the easiest check to pass and the least informative one.
What exactly is history, in migration terms?
Links and dates, more than rows. A note is worthless in a pile and useful on a company. An activity matters because it sat between two stages. An owner matters because somebody has to answer for the account. All of that lives in the relationships, and relationships are what a spreadsheet round trip drops first.
Can we do the export and import ourselves?
For a small account with one pipeline, few custom fields and no automation waiting on the other side, yes, and we would say so. It gets hard when field values have to be translated, when owners have left, and when activities and notes have to land on the right parent.
What is a dry run for?
It moves the whole set into a staging environment first and reports what did not fit, so the decisions about mismatched fields, missing owners and unmatched records get made before anybody works in the new account rather than after.
What if some of it genuinely cannot come across?
Then you decide what to do about it while it is still cheap, which is the point of rehearsing. Some things are better left behind, and a migration that quietly drops them is different from one where you chose.