# You Moved to Pipedrive. Now Check What Actually Arrived

https://salesbond.app/blog/migrate-to-pipedrive-data-audit/
Published: 2026-10-06 · Updated: 2026-10-26

After a migration, check four things before anyone works a deal in the new account: the number of records by type, the sum of open deal value, who owns what, and the dates. Only when those match the old system do you move on to the cleanup list: duplicates, fields in the wrong place, deals in the wrong stage. The order matters, because a broken owner mapping or a shifted date makes every later check lie to you.

This post is about the hour after the import finishes. Preparation and the move itself are covered by Pipedrive’s [five-stage migration framework](https://www.pipedrive.com/en/crm/resources/crm-data-migration) and the [Import2 help article](https://support.pipedrive.com/en/article/migrating-your-data-from-spreadsheets-and-other-crms). If yours is a HubSpot to Pipedrive migration, Pipedrive has a [separate step-by-step guide](https://support.pipedrive.com/en/article/hubspot-to-pipedrive-migration) for the spreadsheet route. We won’t repeat any of them.

## “Import complete” is a statement about rows, not about your data

Picture a nine-person team that moved from another CRM over a weekend. Tamsin runs sales. Yusuf, who doubles as the admin, started the import on Friday evening, because only a global admin can run it and the help article suggests allowing 24 hours. On Monday the import says it is done, and Tamsin’s first instinct is to tell the team to go.

That instinct costs two weeks. Pipedrive puts it plainly in the framework above: “Successful migration is not complete when the data appears in the CRM. It is complete when the team trusts the data and uses the system confidently every day.” The importer confirms that rows were written. It cannot know that the rep who left in March was mapped to nobody.

The scene is made up. The failure modes are not.

## Four counts that have to match after the import

The export someone took from the old CRM before the move is your control sample. Keep it open in one window, Pipedrive in the other, and fill this in before the team touches anything:

| What you count | Old CRM export | Pipedrive after import | Match? |
| --- | --- | --- | --- |
| People (contacts) | | | |
| Organizations (companies) | | | |
| Open deals | | | |
| Won and lost deals | | | |
| Sum of open deal value | | | |

If you imported from a spreadsheet, the import history tab already splits the result into added, updated, merged and skipped ( [Pipedrive: importing with spreadsheets](https://support.pipedrive.com/en/article/importing-data-into-pipedrive-with-spreadsheets)). “Merged” and “skipped” are where missing rows went. The same help article says rows with dates in an unsupported format can be skipped, so a short count on deals often traces back to a date column, not a lost record.

The sum of open deal value is the most useful line in the table. Counts can match while values don’t, when a value or currency column was mapped to the wrong place. If the sum is off by more than rounding go back to the mapping before anything else: the Settings tab if you came over with Import2, the column-matching step if you came in by spreadsheet.

A count that matches is not proof the data is right. A count that doesn’t match is proof it isn’t. That asymmetry is why these come first.

## Owners and dates: where the import quietly rewrites history

Almost none of what goes wrong here shows up in a count.

Start with owners. The Import2 help article says users and pipelines must be set up before the import; otherwise the person who ran it becomes the owner of the data. In our scene that is Yusuf, who now owns every deal whose old owner wasn’t matched to a Pipedrive user. Filter the deals list by owner and look at his number. If it is close to the total, the user mapping didn’t happen. If it is a suspicious middle number, say a third of the pipeline, the likely culprits are the reps who left: their names existed in the old CRM but nobody created them in Pipedrive, so their deals fell through to the importer. Decide who inherits those and reassign them before anyone’s reminders start pointing at the wrong desk. Then do the same for people and organizations; a deal can carry the right rep while the organization behind it still belongs to the admin.

Links break for a related reason. Pipedrive’s HubSpot guide imports in a fixed order (organizations, persons, deals, leads, activities, notes), because each layer points at the one before it. Run a layer out of turn, or redo one without the others, and a deal can arrive with no organization to attach to.

Dates are subtler. Every CRM has its own idea of what “created”, “last contacted” and “expected close” mean, and a migration pushes all of them through one mapping. The loud version of the failure is the skipped rows above. The quiet version is a date that arrived in the wrong field, so a deal’s expected close date now holds the date it was created. On Monday morning half the pipeline looks months overdue, and the team’s reaction is to stop trusting the close date field altogether. That is the moment trust in the the whole system goes, and it is hard to buy back.

So take a sample, not a report: ten open deals across reps and stages, compared against the old record field by field. Created date, expected close date, last activity, value, owner, stage, primary contact. If all ten match, the mapping held. If one field is wrong on all ten, it is a single mapping fix. If dates are wrong on a few, go back to the skipped rows.

Primary contact is on that list because bulk-importing participants can overwrite the primary linked person on a deal ( [Pipedrive: participants](https://support.pipedrive.com/article/participants)). The deal still shows a person. It is just not the one your rep has been talking to.

## Duplicates after the move to Pipedrive

Merging on import catches the obvious pairs. It does not catch the contact whose email changed domains after the last export, or the organization spelled two ways in two systems. Count them in the first week, while they are still the migration’s fault and not somebody’s habit; the filters are in our piece on [duplicate records in Pipedrive](https://salesbond.app/blog/duplicate-records-in-pipedrive/).

If a redo looks cheaper than a cleanup, the two import routes differ. A spreadsheet import can be [reverted within 48 hours](https://salesbond.app/blog/pipedrive-import-revert-48-hours-merge/), which is one more reason to run the counts on Monday rather than Thursday. A migration through Import2 can be undone and redone as needed, according to its help article, with no window stated. A redo is cheaper still when the junk never gets imported, and we listed [what not to move to a new CRM](https://salesbond.app/blog/crm-data-migration-what-not-to-move-sales-team/) in the first place.

## Fields in the wrong place, deals in the wrong stage

Pipedrive’s HubSpot guide gives advice that holds for any source CRM: “Use filters to confirm that labels, custom fields and links were mapped correctly.” Custom fields deserve the most suspicion, because a single export row carries data from several objects at once.

Here is how that can go wrong. A field that lived on the company record in the old CRM, say “industry”, is easy to map onto the deal during import, because the exported row has both. Then every deal carries an industry and no organization does, and the first report by industry is built on the wrong object. Pick the five custom fields your team actually filters by and confirm each sits on the entity you expected. The rest can wait for a [custom fields cleanup](https://salesbond.app/blog/pipedrive-custom-fields-cleanup-data-fields/) later.

Stages are the other mapping that looks right until a report runs. Old pipelines rarely match new ones one to one, and leftover deals land wherever the mapping defaulted. Open each stage and ask whether the deals in it belong there. A stage holding a round number of deals it shouldn’t have is a tell.

We build SalesBond, a sales management layer on top of the CRM a team already uses; we started with Pipedrive. After an import, Deal Health makes a useful second pass. It checks every deal in the connected CRM against the rules you turn on (more than 20 of them, in categories such as Data and Ownership), shows the specific violations and explains what to do about each. It won’t compare the old system to the new one; that is what the table is for. [Check your CRM with SalesBond](https://salesbond.app/) once the four counts match.

## The one-hour order, and who signs

![Timeline of the six post-import checks in order, ending with a sign-off by a person rather than the importer](https://salesbond.app/wp-content/uploads/2026/10/migrate-to-pipedrive-data-audit-2.png)

In the order the checks depend on each other:

1. Fill the count table, including the sum of open deal value. If you came in by spreadsheet, read the import history for skipped and merged rows.
2. Filter deals by owner. Reassign anything that fell to the admin.
3. Compare ten open deals against the old export field by field, primary contact included.
4. Count duplicates and decide: clean up, or start over (a spreadsheet import within its 48 hours, an Import2 migration by undoing it).
5. Check the five custom fields you filter by, then walk each stage.
6. Someone writes “checked, go” with their name and the date.

Step six is the one teams skip. The wizard already said “complete”, so why sign? Because the importer counted rows and a person judged data, and only one of those is accountable when a rep asks in week three where their deal went. Tamsin signs, not Yusuf: the admin ran the import, but the sales lead has to live with the numbers. Keep the signed table; its the first entry in a [regular Pipedrive audit](https://salesbond.app/blog/pipedrive-audit/) and the baseline for the [data quality metrics](https://salesbond.app/blog/crm-data-quality-metrics/) you track from here on.

Then tell the team to go. The audit closes week two of a four-week [CRM implementation plan](https://salesbond.app/blog/crm-implementation-plan-small-sales-team-four-weeks/) for a small sales team.