CRM migration checklist: move records without losing context

Start with the customer record you need tomorrow

Your contacts arrive in the new CRM. The total looks right. Then a salesperson opens a proposal and finds the wrong Alex Rivera attached to it. Another deal has its expected close date where the actual close date should be. The import completed, but the team still cannot trust its customer history.

This CRM migration checklist helps a small team prepare, rehearse, and review that move. It assumes you have chosen a destination. If the product decision is still open, use the CRM requirements checklist first. Keep the migration owner, the person checking sales records, and the person approving the switch named in your plan, even if one person holds two roles.

What we checked: official Pipedrive, Zoho CRM, and HubSpot documentation on September 11, 2026. The downloadable records are fictional. We have not imported them into those products, tested account permissions, or performed a rollback. Expected results below are criteria for your rehearsal, not observed CRM results.

Download the field map and linked sample

Use the CRM migration workbook alongside the fictional CRM sample ZIP. Start with the ZIP's README before editing any CSV.

The workbook has four tabs. Field map explains the source fields and leaves your target fields and owners for you to fill in. Checks records acceptance criteria, observations, and evidence. Reconciliation compares expected and observed counts by record type. Change log provides blank rows for changes made after the snapshot and the evidence that each was resolved. Observation cells start blank, and the checks start as not tested.

The ZIP contains companies, contacts, deals, and activities. It deliberately includes one activity whose deal does not exist. Keep the original file intact. Put that row in a quarantine list and exclude it from the working import until its relationship is resolved.

These are sample counts. Replace them with your own scoped counts when adapting the workbook. The four CSVs describe relationships in a neutral format. They are not ready-made import files for every CRM. Your destination may need different headers, separate batches, newly created fields, or another route for some history.

1. Inventory records, history, and export access

Write down what the team must retrieve after the move. Include companies, contacts, leads if used, deals, owners, activities, notes, attachments, custom fields, and communication preferences. Decide which closed records remain searchable and which records are excluded. Give every exclusion a reason and a person who approved it.

Count each type from the same export scope. Record filters, visibility restrictions, and the time of the snapshot. A salesperson's export may cover less than the administrator's export. Compare like with like before treating a count difference as missing data.

Check the documented permissions and the actual account you will use:

Sources: Pipedrive export and import, Zoho export and new import tool, HubSpot export and import.

Keep untouched source exports and a snapshot of any existing target records you intend to update. Store them with restricted access and record which copy each transformation used. A downloaded export only proves that you have that export. It does not prove you can restore the account or recreate unsupported history elsewhere.

For attachments, record the source file ID, parent record ID, filename, retrieval route, and destination confirmation. Open representative files using the intended user's access. Pipedrive excludes Google Drive files from its global export. Zoho describes complete backup separately from module export. Neither fact establishes that the destination can import all the resulting files.

2. Map meanings, IDs, and relationships

A field map should answer what a value means and how the destination will use it. Mapping two similar labels without checking their meaning can leave a plausible but inaccurate pipeline.

In the sample, Willow Workshop is C01 and Harbor Office is C02. Alex Rivera P01 belongs to C01. Alex Rivera P02 belongs to C02. Dana Lee P03 is the primary contact on deal D01, but activity A02 involves P01 on that same deal. A single contact column copied everywhere would lose that distinction.

Create a crosswalk with the record type, source ID, target ID, and import batch. Use IDs as text so leading zeros or long identifiers survive spreadsheet editing. C01 and P01 are sample source keys, not Pipedrive System IDs, Zoho record IDs, or HubSpot Record IDs.

Pipedrive's spreadsheet update workflow uses its System IDs. Preserve those destination IDs after creation. Its field reference also distinguishes importable values from system fields. Where the destination cannot set an original system timestamp, decide whether a clearly named historical field can preserve the necessary information.

Approve the relationship route before importing. For a staged process, create or identify parent records, collect their target IDs, then map contacts, deals, and activities using the supported identifiers. A supported multi-object import can handle some of this together. Check its mapping preview rather than assuming four files can be uploaded unchanged.

3. Clean a copy without guessing who is a duplicate

Normalize whitespace, date formats, and permitted stage values in a working copy. Keep a log of each rule and the affected IDs. Resolve an ambiguous value with the record owner instead of replacing it with the most common value.

P01 and P02 share the name Alex Rivera but have different emails and companies. Both must survive this sample. An email address is useful evidence of identity, but it is not a universal merge rule. People can share an inbox, change addresses, or have incomplete records.

Pipedrive's duplicate detection can merge matching names when organization, phone, or email also matches. Two different emails alone do not protect same-name contacts at the same organization. Deal titles do not prevent duplicate deals. Review the merge setting and test the collisions relevant to your data. Our base sample does not cover the same-name, same-company case, so add that case to a separate rehearsal copy if it occurs in your source.

Activity A05 points to D99, which is absent from the sample deals file. Quarantine A05 with the reason, owner, and next action. Do not attach it to a similar-looking deal just to remove an import error. The raw total remains 14, while the first approved import covers 13 records.

Treat opt-out information as data to preserve through the move. P04 has marketing_opt_out=true. A false or unknown value elsewhere in the example is not evidence of permission to send marketing. Verify suppression behavior before enabling any connected campaign or sequence.

4. Rehearse dates, blanks, and repeated imports

Use an isolated test destination or an approved test area, with a documented cleanup route. Review workflows, assignment rules, integrations, and outbound actions before adding records. Confirm the available controls in the actual account. Do not use real customer recipients for the rehearsal.

Prepare the transformed sample for that account's importer. Save the mapping and settings, import the approved records, and download the result and error lists. Record created, updated, merged, and skipped results separately. Inspect individual records even when the import summary has no errors.

Three documented differences deserve specific tests:

Sources: HubSpot file requirements, HubSpot multi-object imports, and Zoho's new import tool. Check which Zoho import interface the account uses before applying these controls to it.

Keep date-only values separate from timestamps. D02's expected and actual close dates are different on purpose. A01's 2026-09-15T09:00:00+03:00 represents the same instant as 2026-09-15T06:00:00Z. A different display zone can be correct; a different instant is a migration defect. D03 has a separate October 6 review date and November 2 expected close date.

The sample's due_at field is the scheduled due time. It is not a completion timestamp. A02 and A03 have completed status, but their completion times are not supplied. Keep that distinction in the field map, and do not automatically use a due time as the date a historical interaction happened.

For a repeated-import check, use the target IDs from the first run. In a disposable copy, change one D01 field that your chosen route supports updating. An update-only rehearsal should change the intended record and leave the number of deals at three. A second deal with a similar title is a failed identity check. Do not repeat the complete activity file to test this, and do not assume blank fields will repair unwanted values.

5. Reconcile records and links separately

Compare distinct target IDs within the migrated batch. If the destination already contains records, its full-account total is the wrong denominator. Retain the crosswalk and distinguish new records from existing ones that were matched or updated.

The sample's approved result has two companies, four contacts, three deals, and four activities. Two deals are open and one is won. The open deals total USD 7,400 and the won deal USD 1,800. Those totals are arithmetic controls for this fictional single-currency example; matching them does not prove that each deal is correct.

Check the actual relationship pairs as well:

These describe the source relationships the migration must preserve. If the target represents one through an intermediate object or another supported relationship, document that route and verify the resulting user view. A file with the right parent IDs is not evidence that the importer created the associations.

Open D01 as the intended salesperson. Confirm Dana is its primary contact and the completed proposal review with Alex is still attached. Open D03 and confirm it remains open, retains the Paused stage and review date, and has an internal review activity. Check the completed handoff on D02. Inspect P04's communication settings.

The workbook leaves target counts and unresolved relationship errors blank until you enter observations. Counts match only describes that reconciliation row. It does not approve dates, owners, permissions, suppression, attachment access, or cutover. Keep unresolved issues visible even when totals agree.

6. Control the final changes during cutover

Choose the system that will accept new work during each part of the switch. Tell the team when to stop editing the source and when to begin in the target. Include forms, mailbox integrations, and automations in that decision because they can keep writing while people are waiting.

If a short editing pause is practical, take the final source snapshot inside that agreed window. If work must continue, define how changes after the snapshot will be captured and applied. An updated-at filter alone may miss deletions, relationship changes, or events outside the exported object. Check the source's available history and reconcile those cases explicitly.

For illustration, a change log after the first snapshot might contain:

These are separate examples, not extra rows in the downloadable fixture. Recalculate expected counts for your final approved changes. Keep the record type, batch ID, source ID, change timestamp with time zone, operation, previous value, new value, and resolution together. This distinguishes IDs reused across record types and records the order of changes so a retry does not quietly repeat a create operation.

Use the workbook's Change log tab to capture those details, the affected field or relationship, the target ID, and the owner. Its working rows are empty. Record a completed change as applied, then verify its value and relationships before marking it verified. An entry in the log does not apply an update to a CRM or automatically change the reconciliation totals.

Use a go/no-go decision with the named owner. A missing primary contact, unresolved required relationship, incorrect opt-out, or broken recovery route is a reason to stop. A nonessential historical field may be deferred only with an agreed workaround and owner. Do not label unexplained differences as accepted exclusions after the fact.

7. Plan recovery for creates and updates

A rollback plan must say which changes can be reversed and how new work will be preserved. Before cutover, keep the target's earlier values for records you will update, the IDs of records created by each batch, and the association changes. Rehearse the supported recovery route on disposable records.

Sources: Pipedrive import recovery, Zoho import history, and HubSpot import review.

If a serious defect appears, pause affected user edits, further imports, and the integrations that could amplify it. Record the failure and the time those writes stopped, then capture work added since cutover. Decide whether to repair the target or return work to the source. Before reopening the source, reconcile those later edits so a newly logged customer call or corrected preference is not lost.

Give the team a temporary place to log urgent work while writes are paused, including the customer identifier, event time, action, and owner. Reconcile that log into the chosen system before closing recovery.

Avoid deleting an imported batch merely because it is easy to select. Someone may already have added notes or relationships to those records. Review dependencies and use the recorded repair route. Keep the old system accessible under your agreed retention and access plan until acceptance and recovery needs are resolved.

8. Verify daily work before closing the migration

Ask the person who handles customers to complete a small set of real work checks with the intended permissions: find a company, identify the right contact, read the last interaction, see the next action, and update a deal. Review reports against the same record scope and status definitions used before the move.

Then check the connections you enable, one at a time. Confirm the destination receives the expected event once, under the correct owner, with the correct relationships. Review errors and unwanted duplicate creation after normal work resumes. Keep a named owner and a follow-up date for every deferred issue.

Save the field map, original exports, approved working files, ID crosswalk, import logs, exceptions, and acceptance evidence in a controlled location. Record which source snapshot and final changes they describe. This makes later repairs possible without reconstructing the migration from memory.

If migration work changes your implementation budget, add it to the software cost checklist. If the rehearsal reveals a product requirement the destination cannot meet, revisit the Pipedrive vs Zoho CRM comparison or the HubSpot alternatives guide before moving the full dataset.

Common CRM data migration questions

What should a CRM data migration checklist include?

Include export scope, record counts, field meanings, identity matching, relationships, history and files, a sample import, reconciliation, final changes, recovery, and user acceptance. The owner and evidence for each step matter as much as the checkbox.

Is a CSV export a complete CRM backup?

Check what the export actually contains. A list of contact properties can omit activities, files, associations, or configuration. Preserve each required item through a supported route and test retrieval. Even a broader backup does not establish that another product can recreate the original account.

How many records should be in a test migration?

Choose records that cover your meaningful cases rather than an arbitrary percentage. The included 14 raw records cover linked companies and contacts, two same-name people, open and won deals, dates, activities, an opt-out, and a broken reference. Add the situations it does not cover, including your notes, attachments, genuine duplicates, extra currencies, and custom relationships. Expand only after the smaller rehearsal behaves as expected.