HubSpot CRM Migration Checklist (No Surprises): A Practical Step-by-Step Guide
If you’re moving to HubSpot from Salesforce, Zoho, Pipedrive, or a spreadsheet-built “CRM,” you’re probably hoping for one thing: a clean system that works on day one. That only happens when the migration is treated like a project—not a file import.
This post is a practical, example-driven checklist you can use to plan and execute a HubSpot migration without breaking reporting, automations, or your team’s trust in the data.
What a “good” HubSpot migration actually means
A successful migration isn’t just “all records made it into HubSpot.” It means:
- Contacts, companies, deals, and tickets are correctly associated (so timelines and reporting make sense).
- Lifecycle + lead status history is preserved (or intentionally rebuilt).
- Duplicates are controlled (before and after go-live).
- Sales stages and definitions are consistent (so forecasting isn’t fiction).
- Automations fire correctly (and don’t spam customers or create chaos).
Step 1: Inventory what you have (and what you should stop migrating)
Before you touch HubSpot, get brutally honest about your current system. Most CRMs contain a mix of useful data and “junk you’re afraid to delete.” Migrating everything is how you recreate the mess in a new tool.
Quick audit list
- How many contacts and companies are active vs. dead?
- How many deals are open, and how many are stale?
- Do you have multiple pipelines? Are they actually needed?
- What fields are used weekly vs. never?
- Where does “truth” live today: CRM fields, notes, emails, spreadsheets?
Example: what not to migrate
If you have 80,000 contacts but only 12,000 have engaged in the last 24 months, consider migrating:
- All contacts (if compliance/marketing requires it), but segment them clearly (e.g., “Legacy – No Engagement”).
- Only the last 24 months of deal activity into HubSpot, and archive older deals elsewhere.
The right answer depends on your sales cycle, compliance requirements, and reporting needs—but the point is: decide intentionally.
Step 2: Define your HubSpot data model (so imports don’t fight you later)
HubSpot is flexible, but it’s not magic. If you don’t define how you want to track your business, you’ll end up with duplicate properties, inconsistent stages, and reporting that no one trusts.
Decisions to make up front
- Objects: Are you using just Contacts/Companies/Deals, or do you need Tickets and Custom Objects?
- Lifecycle stages: What do your stages mean in plain English?
- Lead status: Who updates it, and when?
- Pipelines: One pipeline with clear stages vs. multiple pipelines by product/region/team.
- Ownership: How do you assign owners (round robin, territory, manual)?
Example: lifecycle stage definitions (keep it simple)
- Subscriber: opted in, not a lead yet
- Lead: known contact with potential fit
- MQL: marketing-qualified by behavior + fit
- SQL: sales accepted and actively worked
- Opportunity: active deal in pipeline
- Customer: closed-won + onboarded
If your team can’t explain the difference between MQL and SQL without a debate, pause and align before migrating.
Step 3: Map fields correctly (this is where migrations win or lose)
Field mapping is not busywork. It’s the difference between “HubSpot feels clean” and “HubSpot is confusing.”
Mapping checklist
- Export your current fields and mark each as: Keep, Rename, Merge, or Drop.
- Standardize formats (dates, phone numbers, country/state values).
- Convert free-text fields into dropdowns where it improves reporting (without overcomplicating).
- Identify fields that should be calculated in HubSpot (instead of imported).
Example: “Lead Source” done right
In many CRMs, Lead Source is a messy text field: “web,” “Website,” “site,” “google,” “Google Ads,” “adwords,” etc. In HubSpot, you want a controlled dropdown like:
- Organic Search
- Paid Search
- Referral
- Partner
- Outbound
- Event
Then you can report on it without cleaning it every month.
Step 4: Protect associations (contacts ↔ companies ↔ deals)
Most “we migrated but reporting is broken” problems come from missing associations.
What to validate
- Every deal is associated to the right company (and primary contact when applicable).
- Every contact is associated to the right company (especially in B2B).
- Tickets (if used) are associated to contacts/companies/deals as needed.
Example: the forecasting trap
If deals aren’t associated to companies, your pipeline by industry, region, or account owner becomes unreliable. The sales team stops trusting HubSpot, and adoption drops fast.
Step 5: Handle duplicates before they hit HubSpot
HubSpot has solid duplicate management, but it’s not a substitute for pre-migration cleanup. If you import duplicates, you’ll spend weeks merging records and fixing broken associations.
Practical duplicate approach
- Contacts: standardize and dedupe by email where possible.
- Companies: standardize and dedupe by domain (and normalize domains like “www.”).
- Edge cases: shared inbox emails (info@, sales@) need a decision: one contact vs. multiple contacts.
Tip: If your current system has poor email hygiene (missing emails, fake emails), you’ll need a plan—otherwise HubSpot can’t uniquely identify contacts.
Step 6: Rebuild automations intentionally (don’t import chaos)
Automations should be rebuilt based on how you want the business to run now—not copied blindly from the old system.
Automation migration checklist
- List every automation/workflow today and label it: Keep, Improve, or Retire.
- Define triggers in plain language (e.g., “When a deal moves to Proposal Sent…”).
- Confirm who owns each workflow and how it will be monitored.
- Build a test plan so you can validate outcomes before go-live.
Example: prevent accidental email blasts
If you’re using HubSpot Marketing Hub, be careful with workflows that enroll based on imported properties. A common mistake is importing “Lifecycle stage = Lead” and accidentally enrolling thousands of contacts into nurture emails immediately.
Fix: use a temporary property like Migration Batch and only enroll contacts intentionally after validation.
Step 7: Validate reporting (before your team sees the dashboard)
Reporting is where trust is earned or lost. Don’t wait until after go-live to find out your numbers don’t match reality.
Minimum reporting validation
- Pipeline totals match your source system (within expected differences).
- Closed-won revenue for the last 3–12 months matches finance/sales records.
- Lead source reporting works for new records (and legacy records are labeled clearly).
- Sales activity tracking is configured (calls, meetings, emails) based on your tools.
Reality check: If your old CRM reporting was unreliable, don’t expect a perfect match. The goal is accurate reporting going forward—plus a clean baseline for historical comparison.
Step 8: Run a controlled go-live (and keep a rollback plan)
Go-live should be a controlled switch, not a chaotic Monday morning surprise.
Go-live checklist
- Freeze changes in the old system (or define a strict cutover window).
- Import final delta changes (new leads, new deals, updated stages).
- Confirm user permissions, teams, and pipelines.
- Train the team on your process (not generic HubSpot features).
- Set a 2-week hypercare period: daily checks for duplicates, workflow errors, and reporting anomalies.
Common migration mistakes (so you can avoid them)
- Migrating bad data “because we might need it.” You won’t. You’ll just slow down adoption.
- Creating 50+ custom properties on day one. Start with what you need to operate and report.
- Not defining stage exit criteria. If stages are subjective, forecasting becomes noise.
- Ignoring associations. This breaks timelines, reporting, and automation logic.
- Letting everyone build their own fields. That’s how CRMs become unmanageable.
Want a clean HubSpot migration without the mess?
DnA Tech Solutions specializes in HubSpot implementations and migrations with a focus on clean data structure, reliable automations, and reporting you can actually trust.
Book a strategy call or reach out here and tell me what you’re migrating from and what “success” looks like.