A CRM Data Migration Checklist Before You Switch Systems

A CRM migration is not finished when the contacts appear in the new system. It is finished when your team can find the right customer, see the right history, continue the right work and explain any differences in the numbers.

You may not need a migration at all. If the current CRM has the right records and permissions but nobody has configured its pipeline properly, changing platforms can reproduce the same confusion with a new invoice. Our custom CRM build-versus-buy guide covers that earlier decision. This checklist starts after you have a concrete reason to move.

The examples below apply whether you are switching between subscription CRMs, leaving spreadsheets or commissioning a custom system. The import controls differ by product. The questions your business needs answered are remarkably similar.

What exactly are you moving?

Start with an inventory of work, not a contact count. List people, companies, opportunities, tasks, notes, attachments and any custom records. Then list the relationships between them. An education consultancy, for example, might have one student with two applications and different counsellors responsible for each.

That is a fictional example, but it exposes the problem: copying one student row does not preserve two applications, their deadlines or their owners. Decide which destination object represents each piece of work before choosing the import method.

An export is not automatically a complete backup. HubSpot's record-export documentation distinguishes record properties and associations from activities such as calls and notes, which have separate export options. Inspect the actual files and test the retrieval of attachments. Do not assume a button labelled “Export” includes everything visible on a customer timeline.

Write down what will move, what will remain in a controlled archive and what will be excluded. Keep the original export unchanged, record when it was taken and work on a copy. Assign someone to approve the exclusions; the developer should not decide that old complaints or closed deals are disposable.

Which fields and relationships need explicit mapping?

A mapping sheet should describe meaning as well as column names. “Status” in one system may mean a customer's lifecycle; in another it may mean an opportunity's sales stage. Matching the labels can produce a technically successful but operationally wrong import.

Use a table like this before loading anything:

Source item	Destination decision	Evidence to check
Customer or contact ID	Preserve as a source reference; map to the new record ID	One source record resolves to the intended destination record
Company and contact link	Recreate the relationship explicitly	A contact opens the correct company's record
Deal stage	Map each old value to an agreed stage	Open and closed totals reconcile under the mapping
Owner	Map active users and agree replacements for departed staff	Work appears in the intended person's queue
Activity timestamp	Preserve the original event time where supported	History appears in the correct order and timezone
Attachment reference	Copy the file or document an accessible archive	An authorised user can open the right document
Communication preference	Map suppression and preference states separately	An opted-out record stays excluded from the relevant campaign

For an Indian team, include a date such as 04/05/2026 in the test set and state whether it means 4 May. Keep phone numbers as text so country prefixes and leading characters survive spreadsheet handling. Check that rupee amounts remain numeric amounts with the intended currency, rather than formatted strings that reports cannot total.

Treat those as validation cases, not a universal format specification. Use the destination's required formats and keep the original values available for comparison. If a mandatory field is missing, agree how to handle that record instead of inventing information to make the import pass.

How will you avoid duplicates and preserve ownership?

Give every source record a stable reference before transforming the files. If several systems contain the same numeric ID, include the source system and record type in the reference. Keep a mapping from that reference to the destination ID so later corrections can target the same record.

Email and phone are useful matching clues, but they are not a complete identity policy. A business may have a shared inbox, a person may change their email, and two genuine records may share a family phone. Define which records should merge and who resolves uncertain matches. Do not merge automatically just because names look similar.

HubSpot's import requirements describe supported identifiers, including Record ID, unique-value properties and, for particular objects, email or company domain. Choose the supported mechanism for your import rather than assuming a column named “Old ID” automatically prevents duplicates.

Zoho's migration FAQ explains how migration IDs connect modules and owners, and recommends migrating user records first for owner associations. These are product-specific mechanics. For either platform, verify the result by opening a relationship and checking the user's work queue, not merely by seeing an ID column in a spreadsheet.

If a migration script retries after a timeout, it should first establish what the previous attempt created or updated. HubSpot's object API documentation provides an upsert operation using supported unique identifiers. That is a tool for implementing controlled updates; it does not settle your matching rules or guarantee that every field, relationship and side effect is safe to repeat.

What should a trial migration prove?

Use a controlled trial before the full move, with access restricted to the people checking it. Synthetic records can cover basic cases. Where real data is necessary, use an approved environment and only the records needed for validation. Keep migration files out of public sharing links and general-purpose chat uploads.

Select difficult cases deliberately: a contact with no email, a renamed company, a departed owner's open deal, a record with several attachments, a duplicate candidate and a customer with more than one active opportunity. A sample containing only clean contacts tests the easiest part of the job.

Ask sales and operations to perform normal work in the destination. Can they find a customer, understand the latest note, open the relevant document and identify the next task? Can a manager reconcile the pipeline? Can a user with limited permissions see only the agreed records?

Inspect import errors as a separate deliverable. HubSpot's troubleshooting guidance distinguishes rows that fail entirely from individual property values that are not imported. A record's presence therefore does not establish that every field arrived. Download the error report, fix or accept each category and repeat the checks on the affected records.

How do you stop a migration from messaging old leads?

Inventory the actions connected to a changed record: welcome emails, WhatsApp messages, lead assignment, task creation, invoice requests and synchronisation to other systems. Decide which must be paused, isolated or excluded during the trial and initial load. Have an owner for restoring each one.

Do not assume importing historical data is invisible to automation. Behaviour depends on the platform, trigger and settings. HubSpot's workflow setup guide includes decisions about enrolling existing records when activating a workflow. Review those decisions with the person who owns the process before switching anything on.

A migrated contact should not silently become a new marketing subscriber. Preserve relevant preferences and suppression states, then validate them in the system that actually sends the messages. Test with controlled addresses and a non-sending path wherever possible. A successful contact import is not evidence that campaign eligibility is correct.

The same caution applies to integrations: replaying historical “won” deals should not instruct another system to raise a fresh invoice. Separate migration from live business events and review queued work before releasing it.

What should happen on the day you switch?

Agree when the old system stops accepting ordinary edits and when the final export is taken. If the team cannot pause work, design a way to capture changes made during the move. A second full import is not automatically a safe substitute for a defined final-change process.

Name the live system for each stage. “Both are available” is insufficient if staff can update either one and the integration does not resolve conflicts. Give the team a clear instruction about where to record new enquiries, calls and tasks, including what to do if the destination is unavailable.

Reconcile against the agreed scope. Check counts by record type, open deals by stage and owner, monetary totals by currency, required relationships and unresolved errors. Counts alone can match while the wrong contacts are linked to the right companies. Combine aggregate checks with record-level inspection.

Set the stop conditions in advance. Missing ownership on active work, unexplained pipeline differences or an accidental messaging trigger may justify delaying the switch. Agree who can make that decision and how the team continues working if it happens.

A rollback also needs a business plan. Once staff have added notes or changed deals in the destination, returning to an earlier export can lose that work. Record those changes and decide how to preserve or reconcile them; do not describe deleting the import as a complete recovery strategy.

What should you receive before closing the old account?

Ask for the mapping sheet, source-to-destination ID references, import and error reports, a list of excluded data and the reconciliation results. Include ownership of the integration credentials and instructions for dealing with a failed or repeated batch. These documents let another maintainer understand what happened.

Keep the old system available only as long as the agreed verification, retention and business needs require. Read-only access can help comparison, but it still needs controlled permissions and a named owner. Before cancelling, check which files, links or records would become inaccessible and whether the archive can actually be searched and opened.

Migration effort should be visible in the proposal. Our custom CRM pricing guide treats migration as part of scope; the useful question is which records and relationships a particular quote includes. A low contact-import price tells you little about rebuilding history or reconnecting operational systems.

When should you postpone the move?

Postpone when nobody can explain the current stages, ownership rules or duplicate policy. Also pause if the destination cannot represent a relationship the business relies on, or if no authorised person can approve the migrated data. Moving first makes those decisions harder to inspect.

Avoid adding a complete process redesign to the same cutover unless it is necessary and explicitly planned. If the data model, stages, reports and platform all change together, every discrepancy has several possible explanations. Separate the changes where practical and document the exceptions where you cannot.

Start with a small migration assessment and a representative trial. The right result may be a straightforward import, a specialist connector or a decision to configure the system you already own. If you need help checking the fit, tell us which systems and records are involved. No customer export is needed for that first conversation.