CRM data migration checklist: how to prove your records survived the move

A CRM data migration is successful only when people can trust and use the new system. A completed import is not enough. Customer records may be present while company links, deal ownership, consent status, notes, permissions or reporting logic are wrong.

The practical answer is to define success before moving production data, run at least one representative test migration, and reconcile the result at several levels. Check record volumes, critical field values, relationships, files, permissions and real business workflows. Every unexplained exception should have an owner and a decision before go-live.

This checklist is for organisations replacing a CRM or moving from spreadsheets and disconnected systems into an off-the-shelf, semi-bespoke or bespoke CRM system.

What does CRM data migration include?

CRM data migration is the controlled transfer of business data from one or more source systems into a new CRM data model. It includes deciding what to retain, cleaning it, mapping fields and relationships, transforming values, loading the data, validating the result and managing the final cutover.

The scope can extend well beyond contacts and companies. Depending on the organisation, it may include:

• leads, opportunities, quotations and orders;
• service cases, complaints and renewals;
• emails, calls, meetings, notes and attachments;
• account ownership, territories and team assignments;
• marketing preferences and the source of consent;
• custom objects, such as sites, assets, memberships or projects;
• audit history and legacy identifiers; and
• data used by reports, automations, portals and integrations.

The difficult part is preserving meaning. A contact without the correct company, an opportunity without its activity history, or a site visit without its parent asset may be technically imported but operationally useless.

Step 1: define what a successful migration must preserve

Start with business outcomes rather than file formats. Ask each affected team which information and workflows must work on the first day, which history is genuinely useful, and which reports drive decisions.

Turn those answers into measurable acceptance criteria. Examples include:

• all open opportunities have the correct value, stage, owner and associated company;
• active service cases retain their priority, history and linked customer or asset;
• users can see and edit only the records permitted by their role;
• management pipeline totals reconcile to an agreed source report;
• customer-facing portals show the correct account data; and
• connected finance, marketing or operational systems complete agreed test transactions.

These criteria should be approved by business owners, not just the project’s technical team. The people who use a workflow are best placed to notice that a seemingly valid value has the wrong business meaning.

Step 2: decide what to migrate, archive or delete

Moving every available field and record can increase cost, testing effort and risk without improving the new CRM. Classify source data into four groups:

This is also a data-governance decision. The Information Commissioner’s Office says personal data should be adequate, relevant and limited to what is necessary. Its storage-limitation guidance says organisations must justify how long they keep personal data and should erase or anonymise it when it is no longer needed. A migration is therefore a useful point to apply an approved retention policy, not a reason to retain everything indefinitely.

Do not delete records merely because they are old. Legal, contractual, regulatory and operational requirements vary. Assign an accountable owner to approve retention and disposal decisions, and preserve the evidence behind them.

Step 3: create a source-to-target data map

A data map documents where each item comes from, what it means, how it changes and where it will go. It should cover objects and relationships as well as individual fields.

For each mapped field, record:

• the source system, object and field;
• the destination object and field;
• data type, allowed values and maximum length;
• whether the field is mandatory;
• transformation or defaulting rules;
• the owner of the business definition;
• validation rules and acceptance criteria; and
• the treatment of blank, invalid or conflicting values.

Preserve a stable legacy identifier for each migrated record where practical. That identifier creates a trace between source and destination, helps rebuild relationships and makes automated comparisons easier.

Pay particular attention to changed business meanings

Two fields with similar names may not be equivalent. A legacy “customer status” field might mix payment state, account health and lifecycle stage. Copying those values into one destination picklist would preserve the text but corrupt the meaning.

Where there is no clean match, choose deliberately between configuration, a bespoke extension, a transformed value, an archive reference or a process change. Semi-bespoke and bespoke CRM development can accommodate unusual entities and relationships, but customisation should solve a justified operational need rather than reproduce every historic quirk.

Step 4: clean data without losing its context

Cleaning should follow agreed rules and produce an audit trail. Common tasks include standardising dates and telephone numbers, resolving invalid codes, identifying incomplete records and merging duplicates.

Deduplication needs a survivorship rule: when two records are combined, which value wins for each important field? “Newest record wins” may be appropriate for a telephone number but unsafe for consent evidence, contractual terms or account ownership.

The ICO’s accuracy guidance says organisations should take reasonable steps to ensure personal data is not incorrect or misleading, keep the source and status clear, and correct or erase inaccurate data when appropriate. In migration terms, that means a clean-looking record is not enough. The team should be able to explain where important values came from and why a transformation was valid.

Keep a log of rejected, merged, corrected and excluded records. Without it, teams cannot distinguish an intentional clean-up decision from accidental data loss.

Step 5: run a representative test migration

A test migration proves the mapping and migration process before production cutover. The sample should represent complexity, not merely be a convenient set of clean records.

Include examples such as:

• records with several related contacts, opportunities or sites;
• duplicate candidates and incomplete values;
• long notes, unusual characters and large attachments;
• historic and current records;
• different currencies, date formats and picklist values;
• users with contrasting permission levels; and
• records affected by automations, reports or integrations.

HubSpot’s official migration pilot checklist follows the same essential sequence: clean the source, define object and field mappings, prepare associations, run a test import, then review fields, associations and engagement data. The principle applies whichever CRM platform or bespoke system you use.

When testing with personal data, use an appropriately secured environment and only the data needed for the test. Consider anonymised, pseudonymised or synthetic data where it can represent the necessary scenarios. Your data-protection lead should approve the approach where personal or sensitive information is involved.

Step 6: reconcile the migration at six levels

Reconciliation is the documented comparison of source data, migration outputs and destination data. A useful framework checks six levels:

1. Volumes: compare expected, loaded, rejected and excluded record counts by object, business unit and status.
2. Critical values: compare high-impact fields such as opportunity value, renewal date, service priority, consent status and ownership.
3. Relationships: identify orphaned contacts, missing parent records and incorrect links between companies, opportunities, activities, projects or assets.
4. History and files: verify that agreed notes, emails, timestamps, authorship and attachments are present, readable and associated correctly.
5. Access and behaviour: test permissions, calculations, automations, integrations, dashboards and notifications using realistic user roles.
6. Business workflows: ask representative users to complete end-to-end tasks and confirm that the data makes sense in context.

Use automated comparisons for high-volume or high-risk data, then add targeted manual checks. Counts can reveal missing records but not a date shifted by a timezone conversion, a value placed in the wrong field, or every contact linked to the wrong account. Manual sampling alone can miss systematic problems across thousands of records.

Maintain an exception register with the affected records, severity, owner, cause, decision and retest result. A difference is not automatically a defect. It may reflect agreed deduplication or exclusion, but it must be explainable.

Step 7: set go-live and rollback criteria

The final migration usually requires a defined period in which changes to the source CRM are restricted, or a controlled way to capture and migrate changes made after the main extraction. This is the cutover plan.

The plan should name:

• who can make the go or no-go decision;
• the source-data freeze or delta-migration method;
• the order in which objects and integrations are moved;
• the checks required before users receive access;
• the communication and support arrangements;
• the point beyond which rollback is no longer practical; and
• the conditions that trigger rollback or delay.

Avoid a vague target such as “all data migrated”. Agree thresholds for critical defects, unresolved exceptions and failed workflows. A few approved exclusions may be acceptable. One broken permission rule exposing sensitive records may not be.

Keep the old CRM appropriately secured and read-only for an approved period if there is a justified operational or assurance need. That is not permission to retain it indefinitely. Its access, retention and eventual decommissioning should be documented.

Questions to ask a CRM migration partner

Prospective suppliers should be able to explain both their migration mechanics and their assurance process. Ask:

• How will you discover custom objects, integrations and undocumented data dependencies?
• Who owns data-cleansing, mapping and retention decisions?
• How will legacy identifiers and record relationships be preserved?
• What does the test migration include, and how will its sample be selected?
• Which reconciliation checks are automated?
• How will rejected and excluded records be reported?
• How will permissions and connected workflows be tested?
• What are the proposed go-live, rollback and sign-off criteria?
• What support is available immediately after launch?
• How and when will temporary extracts and the legacy CRM be decommissioned?

A credible answer may differ for a configured off-the-shelf CRM, a semi-bespoke implementation and a fully bespoke system. The important point is that the approach matches the complexity and consequence of your data, rather than relying on a generic CSV import.

Frequently asked questions

How long does a CRM data migration take?

There is no reliable duration based on record count alone. Timescale depends on the number of source systems, data quality, custom objects, relationships, attachments, transformation rules, integrations, access controls, test cycles and availability of business owners. Ask for an estimate after discovery and data profiling, with assumptions and responsibilities stated.

Should we clean data before or after migration?

Clean and standardise predictable issues before the final migration, then validate and resolve destination-specific exceptions afterwards. Cleaning only after go-live makes it harder to tell whether an issue came from the source, a transformation or the import itself.

Can we migrate CRM data with CSV files?

CSV files can be suitable for straightforward records and supported associations. They become less suitable when the migration includes complex relationships, large activity histories, attachments, repeated test cycles or transformations across several systems. APIs, specialist migration tools or bespoke scripts may provide better control and repeatability in those cases.

Who should sign off a CRM migration?

Technical owners should confirm that the migration ran correctly, but accountable business owners should approve the meaning and usability of the result. Data protection, security or compliance specialists may also need to approve aspects of scope, testing, access and retention.

Make migration evidence part of the CRM decision

The safest time to define migration acceptance criteria is before choosing the final implementation approach. Data complexity can affect platform fit, customisation needs, cost, delivery sequence and risk.

Whether you choose an off-the-shelf, semi-bespoke or bespoke CRM, insist on evidence that the new system preserves the records, relationships and controls your teams depend on. If your current data model is unusually complex, a structured discovery exercise can identify the risky areas and shape a proportionate migration plan before development begins.