CRM Data Migration: Scope, Mapping, Testing and Go-Live

A CRM migration is an operational project. Moving records changes the information sales, marketing and service teams depend on. Define ownership, data scope, mapping rules and acceptance criteria before planning the import.

Here's the process I use. It's not glamorous. It works.

Step 1: Audit what you actually have

Before you move anything, you need to understand what you're working with. This means pulling a full inventory of your current CRM: objects, properties, record counts, and — critically — data quality.

Run these checks on your source system:

Record counts by object. Inventory contacts, companies, deals, tickets and their associations. Measure activity and completeness, then agree what must remain available for operations, reporting and retention. Inactivity alone does not establish that a record can be removed.

Property usage. Export your property list and check which ones actually contain data. Most CRMs accumulate dozens of custom properties that were created for a one-time campaign and never used again. If fewer than 10% of records have a value in a property, question whether it needs to migrate.

Data quality baseline. Check for duplicates, incomplete records, and inconsistent formatting. If your phone numbers are stored in five different formats, fix that before migration — not after. For a complete approach to cleaning up before a move, see my guide on why data quality is the foundation of every CRM strategy.

Step 2: Define what migrates and what doesn't

This is where most teams skip ahead too fast. You need a migration scope document that explicitly lists what's coming over and what's being left behind. Get sign-off from sales, marketing, and service leads — not just IT.

The decisions you need to make include: Are you migrating historical deals or only open pipeline? Are email logs coming over, or just contact records? What about attachments, notes, and task history? Each of these adds complexity and time.

Choose the migration scope with the teams who use the history. Record which activities, attachments and closed deals must move, what will be archived and how archived data will be retrieved. Test access and agree retention requirements before retiring the source system.

Step 3: Map your data model

Property mapping is where migrations get detailed. You need a spreadsheet — yes, a spreadsheet — that maps every source field to its destination field in the target CRM. Include the data type, any transformation rules, and whether the property already exists or needs to be created.

Watch out for these common traps:

Picklist mismatches. Your source system has "Lead Status" with values like "New, Working, Qualified, Closed." Your target system has different values. You need a mapping for every single option, and you need to decide what happens to values that don't match.

Multi-select vs. single-select. If a source field allows multiple selections but the target only allows one, you'll lose data unless you plan for it.

Association logic. How contacts relate to companies and deals varies between platforms. Salesforce uses account-contact relationships differently than HubSpot. Map these associations explicitly, or you'll end up with orphaned records.

Step 4: Clean before you move

Never migrate dirty data. I'll say it again: never migrate dirty data. It's tempting to think you'll clean it up in the new system, but you won't. You'll be too busy training teams, building workflows, and putting out fires.

At minimum, deduplicate your contacts and companies. Standardize formats for phone numbers, addresses, and country fields. Remove records that are clearly junk — test accounts, spam entries, competitors who signed up for a webinar.

If you have the time and budget, run enrichment on your contact database before migration. Starting fresh with enriched, verified data in your new CRM is one of the highest-ROI activities in the entire project.

Step 5: Test migration with a subset

Run your migration on 5-10% of your data first. Pick a representative sample — not just your cleanest records, but a mix that includes edge cases. Companies with multiple associated contacts. Deals with complex product line items. Contacts with special characters in their names.

After the test import, verify everything manually. Check that associations are correct. Confirm that property values mapped properly. Look for encoding issues, truncated fields, and missing data. Fix your mapping rules based on what you find, then run another test batch.

Repeat representative test batches until the agreed acceptance criteria pass. Reconcile counts, relationships and transformed values, record exceptions and test rollback. The number of iterations depends on the data and integration complexity.

Step 6: Execute the full migration

Schedule the full migration for a low-activity period — Friday evening or a weekend. Disable workflows and automations in the target system before importing. You don't want welcome emails firing for 50,000 contacts who've been in your CRM for three years.

Import in order: companies first, then contacts, then deals, then activities. This preserves associations. If you import contacts before companies, you'll need to associate them after the fact, which is error-prone at scale.

Keep a log of every import batch: file name, record count, success count, error count. You'll need this for validation.

Step 7: Validate and go live

After the full migration, run a validation checklist. Compare record counts between source and target. Spot-check 50-100 records across each object. Verify that key reports and dashboards produce reasonable numbers.

Re-enable your workflows one by one, testing each before moving to the next. If you need to rebuild your workflow architecture, follow a layered approach — I cover this in process design for CRM operations. Then — and only then — give teams access to the new system.

Plan for a two-week "hypercare" period after go-live where someone is available to fix data issues as teams discover them. Because they will discover them. The question isn't whether there are edge cases — it's how quickly you can resolve them.

The bottom line

A CRM migration done well is invisible. Teams log in on Monday and everything works. A migration done poorly haunts you for months — broken reports, missing data, eroded trust in the system.

The difference isn't talent or tools. It's preparation. Every hour you spend on audit, mapping, and testing saves significant cleanup time after go-live. For help with HubSpot's import API, the developer docs are a solid reference. And once your data is in, don't let quality degrade — build a data governance practice from day one. Treat the migration as the operational project it is, and you'll be fine.