How to Migrate CRM Data Without Losing Pipeline History

Here is a scenario that plays out constantly at small B2B sales teams: the company outgrows its spreadsheet, or outgrows HubSpot Free, or a new VP of Sales insists on Salesforce because that is what they know. The migration gets scheduled for a weekend. Someone exports a CSV, someone else imports it, and by Monday the team is back to selling.

Two weeks later, the pipeline report looks wrong. Deals that should show a March close date show blank fields. "Acme Corp" and "Acme Corporation" are two separate accounts, each with half the deal history. A rep asks why their biggest account from last quarter has no email activity logged, when they know for a fact they exchanged forty emails with that buyer. The new CRM did not lose the data by accident. It lost the data because a CRM migration is a data project with real failure modes, and most teams run it like a file copy.

This guide covers how to move your pipeline data into a new CRM without the mess: the sequence that avoids orphaned records, the deduplication work that has to happen before the import (not after), and the platform-specific tools for HubSpot, Salesforce, and Pipedrive.

Why CRM Migrations Break Pipeline Data

A CRM is not a flat spreadsheet. It is a set of linked objects: contacts belong to organizations, deals belong to contacts and organizations, activities attach to all three. When you export from one system and import into another, none of those relationships travel automatically. You are responsible for rebuilding them, and each place that rebuild can fail becomes a place your pipeline data breaks.

Import order creates orphans. If deals import before the organizations and contacts they belong to exist in the target system, the import tool either drops the association, creates a placeholder record, or fails the row outright depending on the platform. The deal exists, but it is disconnected from the account and contact that give it context.

Field mapping assumes matching data models. Every CRM structures its objects differently. Salesforce's core objects are Leads, Contacts, Accounts, and Opportunities. Pipedrive centers on People, Organizations, and Deals. HubSpot uses Contacts, Companies, Deals, and Tickets. Deal or pipeline stage names rarely line up one to one between systems either: a five-stage Pipedrive pipeline does not map cleanly onto an eight-stage Salesforce opportunity process without someone deciding how each stage translates.

Duplicate detection is not automatic across systems. The target CRM has no way to know that "jsmith@acme.com" and "john.smith@acmecorp.com" are the same buyer unless you tell it. Every earlier system that wrote to your old CRM, form submissions, list imports, and other integrations, may have already created near-duplicate records, and a naive import carries all of them into the new system rather than cleaning them up.

Historical activity often does not transfer at all. Email sync history, call logs, and meeting records are frequently tied to the sending platform's own activity timeline rather than a portable field. A straight contact-and-deal export can leave behind the entire interaction history that explains why a deal is at the stage it is in.

None of these are exotic edge cases. They are the default behavior of an export-and-import process that treats a CRM migration as a data dump instead of a data project.

What Good Preparation Looks Like

The highest-leverage work in a CRM migration happens before a single record moves. Cleaning duplicates and inconsistencies in the source system, before extraction, is significantly cheaper than cleaning the same problems after they have replicated into the target system's deal associations, activity records, and consent fields. Treat this as a distinct phase, not a step you'll get to if there's time.

Audit the source data first. Before exporting anything, review your existing CRM for accuracy: inconsistent company name spellings, malformed emails, and contacts that clearly duplicate each other. If you already run a regular CRM data hygiene practice, this audit is much shorter, because the decay has already been kept in check.

Deduplicate the export file before uploading it. Remove rows where the same email appears more than once within the file itself. Then check the remaining rows against anything already in the target system if you are merging into an existing instance rather than starting fresh. This single step prevents the most common source of post-migration duplicate cleanup. For a full breakdown of where duplicates come from and how to merge them safely once they exist, see the guide on CRM duplicate records.

Decide what data actually needs to move. Not every historical record earns a spot in the new system. A reasonable priority order: active pipeline first, then current customers and open opportunities, then recent activity (the last few months), then older archived history only if a specific reporting or compliance need requires it. Migrating five years of dead leads along with your live pipeline adds risk and time without adding value.

Set up the target system before you import. Create the users, custom fields, and pipeline stages you will need in the destination CRM first. If users are not set up ahead of time, most import tools default ownership to whoever runs the migration, which means every deal shows the wrong owner until someone manually reassigns them.

The Import Sequence That Avoids Orphaned Records

Once the data is clean, the order you import objects in matters as much as the data itself.

1. Organizations or companies first. These are the anchor records that contacts and deals will attach to. If they do not exist yet, later imports either fail or create duplicate shell organizations.
2. Contacts second. Contacts link to the organizations you just created. Match on email as the primary key, and pair it with company domain where you can, since email alone will still let the same person in through two different addresses.
3. Deals last. Deals link to both a contact and an organization, so they need to land after both already exist. This is also the point where deal stage mapping matters most: write out a crosswalk from every stage in your old pipeline to the closest equivalent in the new one before you map the field, rather than deciding stage by stage during the import.
4. Activity and historical data, if it is coming over at all. This is usually the most manual step, since native activity histories rarely export cleanly. Decide up front what level of history is worth the manual effort versus what starts fresh in the new system.

Platform-Specific Tools You Will Actually Use

HubSpot. The native import tool maps CSV columns to HubSpot properties and lets you assign pipeline stage during the mapping step. HubSpot uses email as the primary match key for contacts. When an import row's email matches an existing contact, HubSpot updates that record instead of creating a new one, which is exactly the upsert behavior you want, provided your source file's emails are clean. Run large imports in batches rather than one massive file, and spot-check a sample of records after each batch before moving to the next.

Salesforce. The Data Import Wizard is the simpler tool, but it does not support the Opportunity object at all (except on Salesforce Essentials Edition), so any migration involving deal data requires Data Loader instead. Data Loader supports every standard and custom object, handles far larger volumes, and gives more control over field mapping, but it has a steeper learning curve and no built-in duplicate prevention beyond whatever matching and duplicate rules you have configured on the org. Set those matching rules up before you run the load, not after.

Pipedrive. Import Organizations, then Contacts, then Deals, in that order, matching Pipedrive's own guidance. During the deal import, you can either map a stage column directly to Pipedrive's stage field or assign records to a pipeline and stage manually during the import preview. Pipedrive also documents a dedicated migration path for moving from HubSpot, which handles some of the object mapping automatically. For migrations from platforms without a dedicated connector, third-party tools such as Import2 and Trujay build pre-mapped connectors between common CRM pairs and include their own duplicate detection during the transfer.

Whichever platform you land on, validate more than the row count after the import finishes. A row count that matches between source and target tells you almost nothing on its own. Check the associations that actually run your business: are deals still linked to the right account and contact, does ownership reflect the correct rep, and do pipeline stage values match what you mapped. Those are the fields a stale or broken migration will get wrong first.

After the Migration: The First 72 Hours Matter Most

The work is not done when the last batch finishes importing.

Run the native duplicate tool immediately. HubSpot's Manage Duplicates, Salesforce's duplicate jobs, or Pipedrive's merge tool should run within 48 to 72 hours of the import. Fresh imports are one of the highest-risk events for introducing duplicates, and the longer you wait, the more other records (deals, activities, follow-up emails) attach themselves to the duplicate before you catch it.

Reassign ownership where the default was wrong. If users were not fully configured before the import, this is where you fix records that defaulted to the migration operator instead of the correct rep.

Turn on automatic activity capture before reps start working the new system. If email and calendar sync were part of what did not survive the migration, enabling them now (HubSpot's Gmail or Outlook extension, Pipedrive's Email Sync, or Salesforce's Einstein Activity Capture) means the activity gap starts closing immediately instead of compounding while reps get used to the new system.

Have reps spot-check their own book of business. Nobody will find a wrong close date or a missing contact faster than the rep who owns that account. Ask each rep to review their top ten open deals in the new system within the first week and flag anything that looks off.

A migration that gets the sequence, the deduplication, and the first-week cleanup right produces a CRM your team trusts from day one. A migration that skips straight to "export, import, go live" produces a system that looks populated but cannot be trusted for a forecast until someone spends weeks untangling it, which is exactly the kind of stale, duplicate-riddled pipeline data that erodes confidence in the CRM generally. Once the new system is live and clean, check your pipeline coverage against quota to confirm the migration did not quietly shrink your visible pipeline along the way.

If your CRM choice itself is still in question, the comparison of HubSpot, Salesforce, and Pipedrive for small B2B teams is worth reading before you commit to a migration you may want to avoid repeating in a year.

Frequently Asked Questions

What is the safest order to import records during a CRM migration?

Import organizations first, then contacts, then deals. Contacts link to organizations and deals link to both, so importing deals before the records they depend on exist creates orphaned records with broken associations.

How do I avoid creating duplicate records when migrating CRM data?

Deduplicate the source file before you import it, not after. Remove rows where the same email appears twice, then check the remaining contacts against records already in the target CRM. Most rework comes from cleaning duplicates after they have already replicated into deal associations and activity histories, which is far harder to untangle than catching them in the source file.

Can I import Salesforce Opportunities with the Data Import Wizard?

No, except on Salesforce Essentials Edition. On every other edition, the Data Import Wizard does not support the Opportunity object at all. You need Data Loader, which also handles larger volumes and more complex field mapping.

Should I migrate all historical CRM data or just active records?

Prioritize active pipeline first, then current customers and open opportunities, then recent activity, then archived history if it earns its place. Trying to migrate everything at once, including years of stale records, is where most migration timelines blow up.

How soon after a CRM import should I check for duplicates?

Immediately. Run your platform's built-in duplicate tool within 48 to 72 hours of any significant import. Imports are one of the highest-risk events for duplicate creation, and the sooner you catch them, the fewer other records have already linked to the duplicate.