CRM Data Migration Checklist: Contacts, History, and the Fields Sales Actually Use

CRM migrations fail quietly. The new system opens. Logos look fine. A handful of accounts look perfect in a demo. Then sales cannot find last quarter’s notes, customer success loses case context, marketing automation breaks on mismatched IDs, and leadership decides “the CRM project disappointed”, even when the platform itself is sound.

A CRM data migration checklist is how mid-market teams stop treating go-live as a UI event and start treating it as a trust transfer. This checklist is platform-agnostic (Salesforce, Dynamics, HubSpot, and others). It follows the same evidence-led approach we use across data migration methodology: scope, map, migrate, reconcile, cut over.

Use it before you freeze scope, during test cycles, and as acceptance criteria for sign-off.

How to use this checklist

Work top to bottom. Each section has:

• Decide, choices that must be explicit
• Migrate, objects and fields typically in play
• Prove, reconciliation evidence that counts as done
• Owner, who should sign (not “the project”)

If an item is out of scope, write it down as an accepted exclusion. Unspoken exclusions become post-go-live incidents.

1) Programme foundations (before field mapping)

Decide

• Business outcomes for the CRM move (sales process, service, marketing, all three)
• Source system(s) and target system confirmed
• In-scope business units, brands, and teams
• Go-live pattern: big bang vs phased by team/region
• What “historical enough” means for activity and opportunities
• Dual-run rules and decommission criteria
• GDPR / retention posture for personal data and old history

Prove

• Written scope pack with measured volumes by object
• Named domain owners: accounts, contacts, pipeline, service, marketing ops
• Risk register entry for data quality and integration breakages
• Source health baseline started (observability before migration)

Owner

Sponsor + CRM business owner + IT/data lead.

2) Party master data: accounts, contacts, leads

This is the spine. Get it wrong and everything downstream wobbles.

Decide

• Account model: company-centric, household, person accounts, or mixed
• Hierarchy rules (parent/child, bill-to/ship-to if used)
• Contact-to-account relationship rules (primary, multi-account)
• Lead handling: migrate open leads, convert first, or archive
• Duplicate strategy: merge before migrate, merge in flight, or migrate and cleanse later
• Surviving record rules when duplicates collapse

Migrate (typical field groups)

• Core identity: names, legal names, status, type, industry/segment
• Communication: email, phone, preferred channel
• Address structures and country/state normalisation
• Ownership: user/team mapping to target roles
• Commercial attributes sales actually filter on (tier, region, partner flag, contract status)
• Consent / communication preferences where marketing is in scope
• External keys: legacy IDs, ERP customer numbers, website IDs

Prove (full-population reconciliation)

• Population counts by status, owner team, and business unit
• Business-key match rates; orphan and duplicate reports
• Hierarchy integrity checks
• Mandatory field completion rates after transform
• Deep-dives on top revenue accounts and known messy clusters

Owner

Sales ops / CRM owner signs population and hierarchy. Marketing ops signs consent fields if in scope.

3) The fields sales actually use (not the full schema dump)

A common failure mode is migrating hundreds of sparse legacy fields while missing the twenty fields that drive lists, forecasts, and handoffs.

Decide

• Field inventory ranked by actual usage (reports, list views, required page layouts, integrations)
• Which legacy fields are retired vs mapped vs archived off-platform
• Picklist / code-set rationalisation rules
• Calculated or formula fields: migrate values, rebuild logic, or both
• Rich text / long notes strategy (see history section)

Practical ranking method

1. Fields on primary page layouts for sales and service
2. Fields used in active reports and dashboards
3. Fields required by integrations (ERP, billing, marketing, support)
4. Fields used in assignment, SLA, or approval rules
5. Everything else is a candidate for archive, not automatic migration

Prove

• Traceability matrix: source field → target field → transform → owner
• Picklist decode success (no silent dumping into “Other” without report)
• Sample validation with power users on real accounts they care about

Owner

Sales ops leads ranking. Department heads confirm “must keep” list.

4) Ownership, teams, and territory

Wrong ownership destroys adoption faster than missing optional fields.

Decide

• User migration / activation plan (active users only vs full history of owners)
• Team and queue mapping
• Territory or book-of-business rules
• What happens to records owned by leavers
• Shared calendar / activity ownership rules

Migrate

• Owner IDs mapped to target users
• Team membership
• Partner or channel owner fields if used
• Historical owner retained as a field even if current owner reassigned

Prove

• Ownership distribution vs expected team books
• Zero (or explained) records assigned to inactive/invalid owners
• Spot checks with team leads on their top accounts

Owner

Sales leadership + CRM admin.

5) Pipeline and commercial objects

Decide

• Open opportunities only vs open + closed history depth
• Stage model mapping (old stages → new stages)
• Probability and forecast category rules
• Products/price books: migrate, rebuild, or hybrid
• Quotes, orders, contracts if CRM is system of record

Migrate

• Opportunities / deals with amounts, close dates, stages
• Contact roles / influencers
• Line items where product history matters
• Key custom commercial fields used in forecast meetings

Prove

• Open pipeline value source vs target
• Stage distribution sanity checks
• Key match on opportunity IDs / external references
• Deep-dive on largest open deals with account executives

Owner

Sales leadership signs open pipeline value. Sales ops signs stage mapping.

6) History: activities, notes, cases, and files

This is where “technically migrated” and “commercially usable” diverge. Sales does not only need the account name. They need context.

Decide

• Activity types in scope (calls, emails, meetings, tasks)
• Notes and comments: full text, truncated, or attachment-only
• Email bodies vs headers-only (storage, privacy, usefulness)
• Case / ticket history if service is in CRM
• Attachments and content size limits
• Time zones and completed-date integrity
• How far back history goes (90 days, 24 months, all)

Migrate

• Activities linked to the correct account/contact/opportunity
• Note bodies and authors where retained
• Case threads and statuses if in scope
• File metadata + files (or link to archive store)
• Legacy activity IDs if integrations depend on them

Prove

• Activity volume by type and time band source vs target
• Orphan activities (no valid parent) below threshold
• Random and stratified deep-dives: strategic accounts, recent activity, long threads
• User acceptance: “Can I see what happened on this account last month?”

Owner

Sales and service leaders jointly. Legal/privacy if email bodies are included.

7) Integrations and downstream identity

CRM rarely stands alone. Migration success includes the wires.

Decide

• Systems reading/writing CRM data (ERP, billing, marketing automation, support, data warehouse)
• Which system owns customer master after go-live
• ID strategy: preserve legacy keys, new keys + crosswalk, or both
• Interface freeze and replay plan around cutover
• Analytics / reporting rebuild needs

Migrate / configure

• Crosswalk tables for legacy IDs
• Integration user access and authentication
• Reference data shared with ERP (customer numbers, product codes)
• Webhook/event endpoints updated

Prove

• End-to-end tests for priority journeys (lead to account, quote to order handoff, case to customer match)
• Marketing suppression/consent lists still align
• Warehouse or Power BI customer counts reconcile to CRM anchors where used

Owner

IT integration lead + each downstream system owner.

8) Data quality gates (before you scale loads)

Decide thresholds in advance

• Maximum duplicate rate entering target
• Maximum invalid email rate for marketed populations
• Required fields for “sales usable” account/contact
• Handling of test/junk records (exclude list)

Run before final dress rehearsal

• Duplicate report and merge plan executed or deferred with sign-off
• Junk/test record purge rules applied in source or filter
• Critical completeness issues fixed or accepted
• Observability checks quiet on critical CRM feeds

Do not use migration as the only cleanse programme without time and owners. Late cleanse is how test cycles multiply.

9) Reconciliation and acceptance pack (CRM-specific)

Before go-live approval, require a pack that includes:

Also include:

• Exception register (blocking vs accepted) with names
• Integration journey test results
• Hypercare roster and severity model
• Rollback / source retention plan

If the pack is only “row counts look close,” you are not ready. That is how programmes fail after go-live with a green cutover story.

10) Cutover weekend CRM checklist

• Freeze rules communicated (who can create/edit what, where)
• Final extract timing aligned to integration blackout
• User access validated for day-one teams
• Critical list views, reports, and dashboards rebuilt and tested
• Assignment rules / flows activated in controlled order
• Smoke tests: create account, log activity, move opportunity stage, search recent history
• Marketing sends paused or carefully controlled until identity confirmed
• War-room decision rights documented
• Post-load reconcile pack run immediately, not “Monday if we have time”

11) First two weeks hypercare checks

• Daily ownership and create-volume anomaly review
• Pipeline value drift checks vs freeze baseline
• Integration error queues reviewed daily
• Top-account history complaints triaged within SLA
• Duplicate creation rate watched (users recreating because search fails)
• Training gaps vs data gaps separated in triage

Platform note (without turning this into a vendor manual)

Whether you are moving into or out of Salesforce, Dynamics 365, HubSpot, or a niche CRM, the checklist objects stay stable. What changes is API shape, storage limits for history, and how custom fields and automation are represented. Do not let platform enthusiasm skip population definitions and reconciliation. Tools move data. Checklists and proof decide whether sales will use the system on Tuesday.

Bring sales context with the records

A CRM migration is successful when a salesperson can open a customer and trust the story, who they are, who owns them, where the deal stands, and what happened last. That requires more than contact rows. It requires ranked fields, history decisions, identity for integrations, and reconciliation that a business owner can sign.

If you are early in planning, pair this checklist with a Data Migration Readiness Assessment. If you are mid-build, use it as the acceptance spine for the next test cycle.

Next step: Talk to us about CRM migration delivery or baseline source health before you map.