A CRM migration is not a contact import. Audit the current system, define the target data model, preserve stable IDs and relationships, test representative records, reconcile the results, and prepare a cutover and rollback plan before production changes begin.
- Back up records, associations, activities, owners, configuration, and control totals—not just contacts.
- Every retained field needs a destination, transformation rule, owner, and validation test.
- Record counts can match while relationships, permissions, workflow, and reporting remain wrong.
- Do not decommission the old CRM until business owners approve the migrated system.
Your CRM contains more than names and email addresses. It connects companies, contacts, opportunities, owners, tasks, notes, files, pipeline stages, marketing sources, automations, integrations, and reports. A file can import without errors while those relationships disappear.
That is why the real migration objective is not “move the data.” It is preserve the business process that turns an inquiry into a customer and a customer into completed work. This vendor-neutral checklist applies whether you are moving into a major CRM, leaving one, consolidating several systems, or replacing a specialist platform.
CRM migration checklist at a glance
Before migration
- ☐ Name the migration owner, data owners, and go-live approver.
- ☐ Inventory objects, fields, users, reports, workflows, integrations, and historical data.
- ☐ Decide what to migrate, transform, archive, or retire.
- ☐ Identify the authoritative system for each data set.
- ☐ Export records, stable IDs, relationships, activities, and control totals.
- ☐ Design the target model and approve the field map.
- ☐ Define duplicate, ownership, permission, validation, and rollback rules.
During migration
- ☐ Clean and transform data in a staging environment.
- ☐ Test single records and linked record sets before increasing volume.
- ☐ Run a representative pilot, full rehearsal, and timed cutover rehearsal.
- ☐ Load parent records before dependent records.
- ☐ Reconcile errors, counts, totals, owners, and relationships after every wave.
- ☐ Freeze changes and capture the final delta before launch.
After migration
- ☐ Test lead capture, assignment, follow-up, reporting, and critical integrations.
- ☐ Obtain business-owner sign-off for each major object and workflow.
- ☐ Train users by role and publish a support path.
- ☐ Monitor duplicates, orphan records, failed syncs, and incomplete fields.
- ☐ Remove temporary migration access.
- ☐ Retire the old CRM only after reconciliation, archive, and retention approval.
1. Audit the CRM and every connected system
Start with an inventory. List contacts, companies, leads, opportunities, tickets, products, line items, activities, notes, files, custom objects, fields, archived records, and suppression lists. Then list the configuration surrounding them: pipeline stages, validation rules, workflows, forms, calendars, phones, email, quoting, accounting, reporting, middleware, APIs, and webhooks.
Give every item one disposition: migrate as-is, transform, archive outside the CRM, or retire under an approved policy. Recreating every unused field and obsolete workflow simply moves technical debt into a newer interface.
If the underlying sales and service process is still unclear, audit the business system before buying another CRM. The destination software cannot repair a workflow nobody has defined.
2. Decide whether to reconfigure or replace
Some businesses need a migration. Others need a cleaner pipeline, better permissions, a repaired integration, or a simpler workflow inside the platform they already own. Compare the current CRM against the actual operating requirements before treating replacement as inevitable.
Ask whether the current system can support the required objects, relationships, automation, reporting, access model, integrations, and user experience at a reasonable operating cost. If the destination is not decided, compare GenCRM, HubSpot, and Salesforce through those operating requirements—not feature volume alone.
When replacement is justified, define the expected business outcome: faster follow-up, clearer ownership, reliable pipeline reporting, fewer manual handoffs, or a controlled customer record. “A newer CRM” is not an acceptance criterion.
3. Assign ownership and decision rights
Name an executive sponsor, migration owner, sales-process owner, service or operations owner, technical owner, data steward, security approver, and final go-live approver. Smaller businesses may assign several roles to one person, but the decisions still need named owners.
Define the system of record for every important data set. The CRM may own sales stage; accounting may own invoice status; the scheduling platform may own appointment availability. Those are business decisions, not defaults supplied by the migration tool.
Record who can approve mappings, cleansing rules, ownership changes, access, exclusions, cutover, and rollback. Unresolved responsibility becomes last-minute delay—or silent data loss.
4. Back up more than records
An export is useful only if you know what it contains. HubSpot documents that its CRM backup can exclude associations and activity data, while separate export and activity methods cover other information. Salesforce similarly advises backing up affected data before bulk operations. Product capabilities vary by platform and subscription, so verify the exact export scope before assuming it can restore the system.
Capture object records, property values, stable source IDs, associations, owners, notes, calls, meetings, tasks, files, pipeline history where available, user and role configuration, workflows, integration settings, source counts, filters, dates, and exclusions.
“We exported the contacts” is not a rollback plan.
Store extracts securely, limit access, record the custodian and retention date, and keep the source CRM read-only for an approved period after cutover when licensing and policy permit.
5. Design the target model and field map
Map objects before fields. Decide how each source entity corresponds to the target, then create a mapping workbook with the source object and field, source type, target object and field, target type, transformation rule, allowed-value translation, required status, unique-key role, security implication, archive decision, approver, and test result.
Map business meaning, not labels alone. “Qualified,” “Customer,” or “Closed” may represent different rules in two systems. Microsoft’s migration guidance emphasizes target-schema mapping and transformation because unmapped or incompatible data does not become usable merely because it exists in a source file.
Preserve original source, campaign, opportunity, and revenue fields carefully. The deeper guide to preserving lead source data through closed revenue explains why contact-level source alone is not enough for trustworthy attribution.
6. Clean and deduplicate before loading
Standardize whitespace, capitalization, phone formats, dates, currencies, countries, stages, categories, placeholder values, and invalid email handling in staging. Define the match hierarchy and the survivor rule before merging anything.
Use stable identifiers. Depending on the system, those may include a legacy record ID, email, company domain, account number, or a custom external ID. HubSpot’s import guidance notes that identifiers support updates, duplicate avoidance, and associations; Salesforce uses External IDs for matching and relationship work.
Keep the legacy record ID in the target even when another key performs the match. It becomes the crosswalk for reconciliation, retry processing, duplicate investigation, association repair, and future integrations. Quarantine ambiguous matches for human review rather than forcing them into an automatic merge.
7. Preserve relationships, ownership, and history
Build a relationship matrix for contact-to-company, opportunity-to-company, opportunity-to-contact, ticket-to-customer, parent-to-subsidiary, line-item-to-opportunity, activity-to-record, and custom-object relationships. Include primary associations, labels, junction records, and many-to-many links where they exist.
Target systems usually assign new record IDs. Preserve a crosswalk from source object and ID to target object and ID, batch, status, and exception reason. Then test questions the business understands: Does every open opportunity retain the right company, contact, owner, amount, stage, and activity history? Are notes attached to the intended customer? Are service records linked to the correct account?
A correct record count does not prove those connections survived.
8. Map permissions, automations, and integrations
Resolve inactive owners and decide how unassigned records will be handled. Build a role matrix covering view, create, edit, delete, merge, export, assign, share, association editing, workflow access, and administrative changes. Test with representative non-admin users; an administrator’s successful test does not prove the sales or service team has correct access.
Inventory every integration and automation that reads or writes CRM data. Imported values can trigger emails, tasks, notifications, stage changes, syncs, and duplicate records. Define which processes are disabled during each load, which are tested in a sandbox, and the order in which they return during cutover.
The test must include the complete pipeline and follow-up system: form submission, lead creation, source capture, assignment, response timing, stage progression, handoff, and reporting.
9. Sequence the migration around dependencies
Load parent and reference records before dependent records. A common sequence is users and reference data; companies; contacts and leads; opportunities and service records; products; line items and junctions; associations; then activities, notes, files, and historical data. The actual order must follow your configured model.
Separate the baseline load from the delta load. The baseline establishes the main data set. The delta captures records and changes created after the first extract. Use timestamps or change markers, batch identifiers, success files, and error queues so the process is traceable and restartable.
Do not let one failed row erase the evidence for an entire batch. Log the failure, preserve the input, correct the cause, and reprocess only the affected records where the platform supports it.
10. Test linked records and run a representative pilot
Use progressive rehearsals: schema test, single record, linked record set, representative pilot, full-volume rehearsal, and timed cutover rehearsal. Official Salesforce and HubSpot guidance supports sandbox or small-sample testing before production, though sandbox availability and supported assets vary by product tier.
The pilot should contain common and difficult cases: multiple relationships, old owners, missing optional values, uncommon stages, long text, unusual characters, files, multiple currencies, international formats, custom objects, and records that violate new validation rules.
Test work, not just data. Create a lead, assign it, schedule follow-up, update an opportunity, hand it to delivery, find its history, run a forecast, and inspect the manager’s dashboard. Those scenarios reveal whether the migration preserved operations.
11. Validate and reconcile the result
For each object, the control equation is:
Source records eligible for migration = loaded successfully + rejected + deliberately excluded.
Explain every difference. Then reconcile business totals: open pipeline value, opportunities by stage, active customers, tasks due, tickets by status, owners, and other decision-critical measures. Measure orphan records, missing primary relationships, inactive owners, absent activities, and import errors.
Use four validation layers: structural for objects and fields; quantitative for counts and totals; relational for associations and ownership; and business for workflows, reports, and integrations. Obtain sign-off from the people who own those processes.
12. Execute a controlled cutover—and know how to reverse it
The cutover runbook should specify the freeze window, final backup, delta extraction, automation pause, load order, validation checkpoints, go/no-go authority, user-access switch, integration restart order, communication schedule, and hypercare contacts.
Define how urgent leads, calls, bookings, proposals, and customer requests will be handled while the CRM is frozen. The business cannot stop serving customers because a database is moving.
Rollback must be defined by failure type. New records may be removable; overwritten records may require a pre-load snapshot; broken associations may need the ID crosswalk; integrations may require queued transactions to be replayed. HubSpot warns that deleting an import does not reverse updates to existing records. A severe failure may require returning users to the source and preserving the target for diagnosis.
Set rollback triggers, authority, deadline, and verification steps before cutover. Once substantial new activity enters the target, returning to the old CRM becomes more complex.
13. Train the team and install post-launch controls
Train by role and workflow rather than menu. Representatives need lead, opportunity, and follow-up routines. Managers need pipeline and forecast controls. Service teams need customer history and handoff rules. Administrators need error, access, and integration procedures.
A CRM your team will adopt is designed around real work. The guide to a CRM your team will actually use covers the workflow and adoption principles in more depth.
During hypercare, review duplicate creation, failed syncs, routing failures, unassigned records, permission issues, incomplete required fields, high-value opportunities, and user-reported discrepancies daily. Move to weekly and then monthly governance only after the system stabilizes.
Decommission the old CRM after signed reconciliation, archive and retention approval, completed integration transition, no unresolved critical defects, and a named owner for future archive access.
When a CRM migration needs a systems integrator
Specialist help becomes valuable when the CRM has several connected sales and service systems, custom objects, complex relationships, uncertain system-of-record ownership, significant automation, multiple teams or permission models, historical activities that must be preserved, strict downtime limits, or no internal owner for migration decisions.
The value is not operating an import tool. It is coordinating process, data architecture, permissions, automation, integrations, testing, cutover, and governance as one controlled system. Generaite’s CRM implementation services begin with that operating context rather than a predetermined platform.
A safe migration gives every retained record a destination, every relationship a key, every load a validation test, and every production change an owner and recovery path.
Sources and further reading
- Microsoft: CRM data migration to Dataverse—key insights and best practices
- Microsoft: Suggested workflow for a complex data migration
- HubSpot: Back up CRM data
- HubSpot: Export records
- HubSpot: Format import files and preserve associations
- HubSpot: View and analyze past imports
- Salesforce Architects: Integration patterns and system ownership
- Salesforce: Data Import Wizard
Vendor features, limits, export scope, sandbox availability, and import behavior can vary by product, subscription, and release. Confirm current platform documentation before finalizing a production migration plan.
Continue with: Business Systems Audit Framework, The CRM Your Team Will Actually Use, and Lead Source Tracking: From First Click to Closed Revenue.
Service path: review CRM implementation services, then request a Systems Review before committing to a platform or cutover plan.
