HubSpot CRM Migration: The Zero-Data-Loss Playbook
Read Time 16 mins | Written by: Vinayak Bhagat
A HubSpot CRM migration rarely loses data in a dramatic way. Nobody deletes the database. It happens quietly: contacts arrive without their company, deal history lands with the wrong owner, call notes stay behind, and months later the pipeline report and the finance numbers disagree. By then the old CRM is switched off and nobody can say what went missing.
This playbook is for the people who own that risk: the RevOps lead, the sales operations manager, the CRM owner and the CTO who signs off the move. It assumes the platform decision is made. If it is not, start with our comparison of HubSpot and Salesforce for mid-market companies, then come back.
The principle is simple. A migration is not finished when the import completes. It is finished when you can prove that every record, every relationship and every piece of history that was meant to move has moved, and that what was left behind was left on purpose. Getting there takes five gates, and the work passes each one only with evidence. We call them the Five Cutover Gates. They apply whether you are leaving Salesforce, Microsoft Dynamics, Pipedrive, Zoho or a set of spreadsheets.
How do you migrate to HubSpot without losing data?
Map every object, field, relationship and activity before anything moves, and decide in writing what stays behind. Clean duplicates in the source system. Run a full rehearsal into a test portal and reconcile it by record count, by association and by spot-checking real records. Freeze changes for the cutover, load the final data and switch owners and integrations. Then run the same reconciliation on the live portal, get sign-off from the people who use it, and keep the old system read-only until that sign-off is done.
The Five Cutover Gates
Each gate has an exit condition. If you cannot produce the evidence, the migration has not passed the gate, however close the go-live date is.
| Gate | What it protects | Exit evidence |
|---|---|---|
| 1. Map | Nothing is forgotten | A signed mapping document, including a list of what will not move |
| 2. Clean | Nothing is merged or duplicated by accident | Duplicates resolved in the source, every record carrying a unique key |
| 3. Rehearse | Surprises happen in a test portal, not in production | A dry run whose counts, associations and spot-checks reconcile |
| 4. Cut over | Nothing changes in the old system mid-move | A freeze notice, a final load log, and a rollback rule written in advance |
| 5. Reconcile and retire | The proof survives the old system | Production reconciliation, user sign-off, an archive, then decommission |
Gate 1: Map — every object, field and relationship
Start with an inventory of the source system, not the HubSpot setup screens. List every object in use (accounts, contacts, leads, opportunities, products, tickets, custom objects), the fields on each, the relationships between them, the record owners, and the activity history: emails, calls, meetings, notes, tasks and files. Count the records in each object now. Those counts are the baseline for every later reconciliation.
Then map each one to its HubSpot destination, field by field, including the picklist values. This is where the real design decisions sit: which stages your deal pipeline has, what a lifecycle stage means, which fields are retired rather than carried over. Our HubSpot implementation guide makes the point that the data model is the implementation, and a migration is where that model is either built deliberately or inherited by accident.
Finish with a list of what will not move: fields nobody reads, records nobody needs, test data. Leaving data behind on purpose is not data loss; leaving it behind without a decision is. Keep the source record ID for everything that moves, in its own HubSpot field, so any record can be traced back. Red flag: the mapping lives in one person's head or in the migration tool's settings, with no document anyone has signed.
Gate 2: Clean — fix the source before the move
Duplicates are the most common way records quietly disappear. HubSpot automatically deduplicates contacts by email address and companies by domain name, and if an import carries no unique identifier, each row is created as a new record. Both will surprise you if unplanned: two contacts sharing an email become one, and a file without identifiers can double your database on a second run.
So resolve duplicates in the source, where the people who know the accounts can decide which record wins and what happens to the history on the loser. Give every record a stable key. HubSpot's own import file guidance lists the options: Record ID, email for contacts, company domain name for companies, or a custom property that requires unique values. The legacy ID from Gate 1 is a natural fit for that last one.
Cleaning is also the moment to check the source for drift: reports that disagree with the numbers people use, fields that have multiplied, stages nobody can define. The five signals of CRM drift apply to any CRM, not only to HubSpot, and whatever drift you carry across becomes the new system's problem on day one. Red flag: a plan to "clean it up in HubSpot after go-live".
Gate 3: Rehearse — a full dry run, reconciled
Run the whole migration into a test portal or sandbox before you touch production, with the real data, the real mapping and the tools you will use on the day. A sample proves the format works. Only a full run proves the data does.
Then reconcile at three levels. First, counts: records per object in the source against records per object in the test portal, with every difference explained. Second, associations: contacts linked to their companies, deals linked to their contacts and companies, activities linked to the right records. A count can match while the relationships are broken, so check them separately. Third, spot-checks: pick real records that people know well, including the messy ones, and have their owners compare them field by field against the old system.
Rehearsal matters most for history. HubSpot notes that existing emails, meetings, notes and tasks cannot be updated via import, so activity history that lands wrong in production is hard to fix in place. Get it right in the rehearsal. Our implementation timeline sets the same exit condition for its migration stage: a rehearsal whose counts reconcile, not one that merely completed. Red flag: "the import finished with no errors" offered as proof.
Gate 4: Cut over — freeze, load, switch
Data entered into the old system during the move is the data most likely to be lost, because it was not in any extract. Announce a change freeze with a clear start and end, tell every team what to do with a new lead or a closed deal during that window, and agree who can approve an exception. Then take the final extract, load it using the steps you rehearsed, and record what was loaded.
Switch the connections in the same window. Owners map to real HubSpot users, and HubSpot's import guidance notes that users assigned as owners via import are not notified, so tell them yourself. Integrations, forms and inbound sources move to HubSpot. Workflows that send email or change records stay off until the data under them is checked.
Write the rollback rule before the window opens: which finding stops the cutover, who makes the call, and what the teams use if it stops. A rule decided at midnight under pressure is not a rule. Red flag: no freeze, because "people can keep working in both".
Gate 5: Reconcile and retire — prove it, then switch off
Repeat the Gate 3 reconciliation on the live portal: counts, associations and spot-checks, against the final extract. Then ask the people who use the system every day to sign off on their own records and their own reports. A sales leader who confirms that last quarter's pipeline report matches is better evidence than any log file.
Keep the old system read-only until that sign-off is complete, with a firm end date, so nobody starts working in it again. Take a full archive export and store it where it can be found by someone other than the person who made it. Only then cancel the old license and remove access. Our HubSpot onboarding checklist covers the configuration that should be in place around this launch, and why running both systems in parallel without an end date undoes the work. Red flag: the old license is cancelled before anyone has signed off.
The CRM Migration Cutover Checklist
This article explains the five gates. The checklist is the worksheet you run the migration from: a page per gate with boxes for the evidence and a sign-off line for whoever approves it, a reconciliation sheet with source count, HubSpot count, difference and explanation for every object, a freeze-window and rollback page to fill in before cutover day, and a final sign-off before the old system is switched off.
What Changes by Source System
The gates do not change with the source; where the hardest mapping decisions sit does. Check your own instance, because two companies rarely use the same CRM the same way.
| Moving from | The decision to settle at Gate 1 |
|---|---|
| Salesforce | Leads and contacts are separate records. Decide how unconverted leads arrive in HubSpot, what lifecycle stage they carry, and how custom objects and record types map. |
| Microsoft Dynamics | Leads, contacts and accounts are separate too, and the CRM is often tied into other business systems. List every connection that reads or writes CRM data before you plan the switch. |
| Pipedrive | The model centers on deals, people and organizations. Decide how pipeline stages translate, and which activity history matters enough to bring across. |
| Zoho CRM | Leads, contacts, accounts and deals are separate modules, and custom modules are common. Map each custom module deliberately rather than flattening it into notes. |
| Spreadsheets | There are usually no record IDs and no relationships. Gate 2 is most of the work: build the unique keys and the company-to-contact links before anything is imported. |
Three Mistakes That Lose Data in a Migration
Treating the import log as the proof
An import with no errors tells you the file was accepted. It does not tell you that every record was in the file, that associations were made, or that two records were not merged into one. Only a reconciliation against the source does that.
Migrating records but not relationships
A contact without its company, or a deal without its contacts, is still in the CRM and still useless. Plan the order of loads and the keys that join them, and reconcile associations as their own check.
Switching off the old system too early
The old CRM is the only place a missing record can be found. Keep it read-only until the people who use the new one have signed off, and keep an archive export after that.
When a Migration Is the Wrong Move
For transparency: Ontrac is a HubSpot Diamond Partner, so we have an interest in companies moving to HubSpot. That is exactly why this section matters. A migration is the wrong move when the current CRM fits the business and the pain is really in how it is run. Our HubSpot vs. Salesforce comparison sets out the cases where Salesforce is the better platform, and they are real.
It is also the wrong move when nobody owns the data after go-live, because a clean migration into an unowned system drifts back within a year. It is the wrong move in the middle of a period when the business cannot freeze changes, such as a quarter-end close or a deal process that cannot pause. And if you are already on HubSpot and unhappy with it, an audit of the existing portal usually costs less than moving anything.
For private-equity-backed companies, timing often matters most: a migration just before a sale or refinancing puts at risk the reporting a buyer or lender will read. Run it when there is room to rehearse and reconcile.
Plan the five gates before the first export.
Our HubSpot services team helps mid-market and private-equity-backed companies move into HubSpot from Salesforce, Dynamics, Pipedrive, Zoho and spreadsheets. Bring your source system and your go-live date, and we will walk through the mapping, the rehearsal and the reconciliation with you.
Book a call with usFrequently Asked Questions
What is a HubSpot CRM migration?
It is the move of your customer data into HubSpot from another CRM or from spreadsheets: the records, the relationships between them, their owners and their activity history. A migration done well also moves the integrations and inbound sources, and ends with the old system archived and switched off.
How do you check that no data was lost in a Salesforce to HubSpot migration?
Reconcile at three levels against the source: record counts per object with every difference explained, associations between contacts, companies, deals and activities, and field-by-field spot-checks of real records by the people who own them. Do it once on a test portal and again on production.
Can you bring email, call and meeting history into HubSpot?
Activity history can be brought across, but HubSpot notes that existing emails, meetings, notes and tasks cannot be updated through an import afterward. That makes the rehearsal especially important for history: confirm it lands on the right records, with the right dates and owners, before the production load.
Should we run the old CRM and HubSpot in parallel?
Only with the old system read-only and a firm end date. If people can keep working in both, records change in two places and no reconciliation can keep up. Keep the old system available for lookup until the users sign off, then archive it and switch it off.
Keep Reading
→ The Complete Guide to HubSpot Implementation & Consulting for Mid-Market Companies — the method the migration sits inside.
→ The Realistic HubSpot Implementation Timeline — where migration fits in the schedule.
→ HubSpot Onboarding Checklist: 10 Things to Configure Before You Go Live — the configuration around the launch.
This article is general information about planning a CRM data migration and is not legal or data-protection advice. HubSpot behavior described here reflects its Knowledge Base at the time of writing and can change; check the current documentation and your own obligations before moving personal data.
