CRM Migration Checklist: Plan, Cut Over, and Reconcile

A CRM migration is complete only when the target system contains the accepted records and relationships, users can perform critical work, integrations and reports produce known results, exceptions have owners, and the old system can be recovered or retired according to plan. A successful import is one event inside that process—not the finish line.

This vendor-neutral checklist can be used for Salesforce, HubSpot, Dynamics, Pipedrive, or another CRM pair. Product-specific import mechanics vary, so verify current documentation, editions, limits, APIs, and contract terms. The gates and formulas below are reusable because they define evidence rather than a particular loader.

How to use this CRM migration checklist

Direct answer. Run the migration in eight controlled phases: charter, inventory, mapping, cleanup and test, reconciliation, freeze and cutover, rollback if a gate fails, then stabilization and decommissioning. Every checklist item needs an owner, due date, evidence link, status, exception, and approver. Do not cut over because a file loaded; cut over because the accepted business workflow and data state are reproducible.

Create a shared register with these columns: item ID, phase, system, object or workflow, requirement, owner, due date, status, evidence URL, exception, risk, approver, approval date, and rollback effect. “Done” without an evidence artifact is “unverified.”

This page owns execution after a CRM decision. For a two-platform choice, use the HubSpot versus Salesforce comparison. For a Pipedrive-specific shortlist, use the Pipedrive alternatives guide.

Phase 1: charter the migration and define acceptance

Define why the migration exists and how the business will prove success before mapping any field. A vague charter such as “modernize CRM” cannot decide whether a missing activity, changed stage, or rebuilt report is acceptable.

• ☐ Name the executive sponsor, program owner, data owner, CRM architect, RevOps owner, integration owner, security and privacy owners, test lead, cutover commander, support lead, and rollback decision maker.
• ☐ State the business constraint, required outcomes, excluded scope, target date, approved outage, budget, and decision rights.
• ☐ List knockout requirements: data residency, identity, required objects, historical depth, audit, retention, exports, permissions, reporting, APIs, and critical integrations.
• ☐ Define recovery point and recovery time objectives in language the business can test.
• ☐ Freeze acceptance thresholds for records, fields, relationships, duplicates, exceptions, permissions, workflows, integrations, reports, and user tasks.
• ☐ Approve stop, rollback, escalation, and waiver authority before the first production load.

Acceptance criteria should name denominators. “99% complete” is meaningless until the team agrees which source records are eligible, which are intentionally archived, how duplicates are treated, and whether deleted or legally restricted records are excluded.

Phase 2: inventory source data and dependencies

Inventory the CRM as a graph of data and dependencies, not a list of tables. Contacts without accounts, activities without participants, and products without opportunity lines may pass object counts while the operating model fails.

• ☐ Export object and field definitions, types, lengths, required flags, defaults, unique constraints, validation rules, formulas, picklists, stages, statuses, currencies, time zones, and record types.
• ☐ Count active, inactive, archived, soft-deleted, duplicate, orphaned, restricted, and legally held records by object.
• ☐ Inventory users, queues, teams, territories, roles, profiles, permission sets, sharing, ownership, former employees, and integration identities.
• ☐ Inventory every parent-child, lookup, many-to-many, same-object, primary, labeled, and polymorphic relationship.
• ☐ Inventory activities, emails, meetings, calls, notes, attachments, files, products, line items, quotes, contracts, campaigns, consent, subscriptions, and custom objects.
• ☐ Inventory workflows, sequences, routing, approvals, scoring, deduplication, enrichment, forms, webhooks, APIs, scheduled jobs, middleware, BI, warehouse feeds, and downstream exports.
• ☐ Inventory dashboards and reports with owners, filters, formulas, refresh cadence, consumers, and frozen expected results.

Profile completeness, validity, uniqueness, consistency, ownership, and freshness using the CRM data quality framework. Record source defects rather than silently correcting them during load; otherwise the team cannot explain why source and target differ.

Document each connected system with the CRM integration checklist. Record direction, object, field, matching key, frequency, timestamp authority, retry behavior, deletion propagation, rate limits, monitoring, and incident owner.

Phase 3: map objects, fields, values, and relationships

Build four linked maps: object, field, value, and relationship. Preserve the source record ID in a migration crosswalk even when the target creates a new identifier. This makes errors, deltas, and audit questions traceable.

HubSpot’s official import-file documentation shows why mapping details matter: field formats vary, updates require unique identifiers, and associations require identifiers for each connected record. It also documents special behavior for blank cells, owner values, multiple values, and subscription-dependent limits.

Salesforce’s official related-record import guidance explains that external IDs can connect related records during upsert but do not work for every reference, including certain polymorphic fields. Load parents before children where the target relationship requires a target ID. Handle activities, owners, and many-to-many join records explicitly.

Before creating target custom fields, use the CRM custom-fields guide to classify each field as migrate, transform, consolidate, archive, or retire. Moving every legacy field reproduces the old CRM’s debt.

Phase 4: clean, transform, and test representative data

Clean against approved rules, then test a production-shaped slice with known expected outcomes. Never start with only clean contacts. Include the edge cases most likely to break mappings and permissions.

• ☐ Back up source data, configuration, definitions, files, and mapping versions; verify that restoration can be initiated by an authorized owner.
• ☐ Deduplicate with survivor, merge, provenance, and relationship-preservation rules approved by the data owner.
• ☐ Normalize dates, times, currencies, phones, countries, domains, email casing, booleans, enumerations, HTML, line breaks, and encodings without destroying original values.
• ☐ Select representative accounts, contacts, leads, open and closed opportunities, activities, notes, files, products, lines, campaigns, custom objects, owners, currencies, languages, and relationship edge cases.
• ☐ Include duplicates, missing parents, archived users, restricted records, maximum-length text, invalid values, multi-selects, deleted records, shared emails, multiple domains, and same-object relationships.
• ☐ Disable outbound notifications and destructive automation in the isolated test environment.
• ☐ Run the load in dependency order; retain input, mapping, timestamps, success logs, error logs, rejected rows, corrections, and rerun IDs.

Salesforce documents Data Loader for bulk insert, update, delete, and export and notes its CSV success and error logs. Its related-record guidance recommends backup and a one-record or small-subset test before a broad operation. These are tool mechanics, not proof of business acceptance.

Microsoft’s official migration UAT guidance recommends business-user testing in a dedicated, integrated environment and explicitly includes data integrity, access, and visibility. Ask sellers, managers, RevOps, finance, marketing, service, and administrators to complete real tasks with known answers.

Phase 5: reconcile with explicit formulas

Reconciliation needs several denominators because record count alone cannot prove usable data. Freeze exclusions and transformation rules before calculating.

Report numerator, denominator, exclusions, query or export version, calculation time, owner, and evidence location with every percentage. For financially or operationally critical fields, perform a full comparison rather than sampling. For sampled fields, predefine the sampling frame, strata, random method, sample size, and permitted errors.

Microsoft’s migration validation documentation demonstrates the core principle: compare source and target, report tests and failure counts by entity, and drill into expected versus actual values. Build equivalent evidence for the chosen CRM pair.

Reproduce frozen dashboards and operating outputs, not just stored values: pipeline totals, forecast categories, stage movement, activity counts, campaign attribution, renewal views, owner books, territory reports, SLA queues, and integration payloads.

Phase 6: freeze, migrate the delta, and cut over

Cutover begins with a controlled change freeze and ends only after the delta and critical workflows reconcile. Publish one timeline with times, owners, commands or jobs, expected duration, evidence, decision points, communication, and rollback step.

1. Confirm approvals, backups, access, staffing, vendor support, monitoring, business communications, and the rollback decision window.
2. Freeze configuration changes in both systems. Restrict who may edit fields, stages, automations, integrations, reports, users, and mappings.
3. Define the transaction freeze or controlled dual-entry window for sellers and connected systems. Record the last accepted source timestamp.
4. Run the final full or incremental export with stable IDs and timestamps. Hash or otherwise identify files according to policy.
5. Apply the approved delta transformation and load in dependency order. Save every job and exception artifact.
6. Run automated count, field, relationship, duplicate, and exception checks. Reproduce critical reports and execute smoke tests.
7. Enable integrations and automation in controlled groups, checking replay, duplicate, timestamp, permission, and failure behavior after each group.
8. Open access to a limited user cohort, then the wider organization only after the cutover commander confirms gates.

Map users and ownership before opening the target. The CRM ownership guide helps resolve former employees, queues, territories, shared accounts, and reassignment. Never default every unresolved record to the administrator without an explicit remediation queue.

Phase 7: trigger rollback when a gate fails

Rollback is a preapproved response to a failed gate, not an admission of failure. Name objective triggers and the final decision time before production cutover.

• Material record loss, corruption, unexplained duplicates, or destructive writes exceed the approved threshold.
• Critical relationships, ownership, permissions, identity, audit, or privacy controls fail.
• Business-critical selling, service, billing, renewal, routing, forecast, or reporting workflows cannot operate.
• Integration replay or timestamp behavior creates an unbounded risk of conflicting state.
• Recovery is forecast to exceed the approved outage or the team cannot explain target state.

The rollback runbook should identify the decision maker, communication owner, target-write stop, integration shutdown order, restore point, source reactivation, delta capture, credential handling, validation checks, downstream notification, customer-impact response, incident record, and criteria for another attempt.

Do not destroy the failed target. Preserve logs and evidence according to security and privacy policy so the cause can be diagnosed. If the source accepted transactions during cutover, reconcile those changes before reopening it as authoritative.

Phase 8: stabilize and decommission the old CRM

Make the old CRM read-only after cutover evidence passes; decommission it only after the retention and dependency plan passes. A hidden API consumer, old email link, finance export, or legal hold can make premature deletion expensive.

• ☐ Run daily reconciliation during the stabilization window and assign every exception.
• ☐ Monitor login, API, integration, automation, sync, duplicate, validation, permission, report, and user-support failures.
• ☐ Complete role-based training and measure task success, not attendance.
• ☐ Rebuild or redirect bookmarks, links, forms, email templates, BI, warehouse jobs, documentation, and operating procedures.
• ☐ Revoke unnecessary integrations and users in stages; rotate credentials and verify no critical traffic remains.
• ☐ Export the final source archive, schema, mappings, logs, audit evidence, attachments, and deletion inventory in usable formats.
• ☐ Obtain legal, privacy, security, data-owner, finance, operations, and business sign-off for retention, read-only access, contract termination, and deletion.
• ☐ Verify vendor deletion or return obligations and record evidence rather than assuming contract cancellation deletes data.

Review the migration after one complete forecast, pipeline, renewal, and reporting cycle. Compare data defects, integration incidents, administrator hours, rep task completion, report reproducibility, and retired costs with the baseline. Cosmetic adoption metrics cannot prove the system is operational.

Printable CRM migration checklist

Print or copy this condensed artifact into the project register. Add an owner, evidence link, exception, and approver beside every line.

1. Charter: ☐ outcome ☐ scope ☐ owners ☐ knockout gates ☐ thresholds ☐ outage ☐ recovery objectives ☐ rollback authority
2. Inventory: ☐ objects ☐ fields ☐ values ☐ IDs ☐ relationships ☐ users ☐ permissions ☐ files ☐ activities ☐ automation ☐ integrations ☐ reports
3. Mapping: ☐ object map ☐ field map ☐ value map ☐ owner map ☐ relationship crosswalk ☐ load order ☐ archive/retire decisions
4. Prepare: ☐ backup ☐ source profile ☐ dedupe rules ☐ transformations ☐ representative slice ☐ expected outcomes ☐ isolated environment
5. Test: ☐ load logs ☐ error queue ☐ user tasks ☐ permissions ☐ workflows ☐ integrations ☐ reports ☐ edge cases ☐ correction rerun
6. Reconcile: ☐ completeness ☐ count variance ☐ field accuracy ☐ relationship integrity ☐ duplicate rate ☐ exception rate ☐ sign-off
7. Cut over: ☐ change freeze ☐ transaction plan ☐ final timestamp ☐ delta export ☐ dependency load ☐ smoke tests ☐ staged enablement ☐ communication
8. Rollback: ☐ triggers ☐ decision time ☐ stop writes ☐ disable integrations ☐ restore source ☐ reconcile delta ☐ validate ☐ communicate
9. Stabilize: ☐ daily reconciliation ☐ monitoring ☐ support ☐ training ☐ complete business cycle ☐ unresolved-exception owners
10. Decommission: ☐ read-only gate ☐ archive ☐ dependency scan ☐ revoke access ☐ terminate contract ☐ deletion evidence ☐ postmortem

Final gate: do not mark the migration complete until accepted data, relationships, permissions, workflows, integrations, reports, recovery, retention, and deletion are supported by evidence and named business owners.