CRM Data Migration Checklist: 10 Checks Before Your First Import

An illustrative CRM migration starts with 10,000 contacts. The team removes 400 duplicates and imports 9,600 records without a single rejected row. Then someone checks the renewal list. It is missing 240 contacts because their company associations did not survive the move.

The record count is correct. The list used to contact customers is not.

That is the kind of failure CRM implementation services should help organizations identify before production. A successful migration requires more than transferring rows between systems. It must preserve the information, relationships, permissions, and workflows that employees rely on.

Before your first CRM import, verify ten things: migration scope, source-data ownership, record identifiers, field mappings, formats and consent, automation, recovery procedures, test-import results, business-process validation, and final cutover approval.

This CRM data migration checklist explains how to complete those checks, with practical mapping examples and platform-specific considerations for HubSpot and Microsoft Dynamics 365.

CRM Data Migration Checklist: 10 Checks Before Importing Records

Use this checklist during migration planning. Each item should have a named owner and evidence of completion before production data is imported.

1. Define migration scope: Identify the customer records, business processes, and historical information required in the new CRM.
2. Inventory source data: Document source systems, object counts, field ownership, data quality issues, and approved exclusions.
3. Establish record identities: Define unique identifiers, duplicate rules, and account-to-contact relationships.
4. Prepare field mappings: Document destination properties, transformations, update priorities, and exception handling.
5. Validate formats and consent: Check dates, currencies, picklists, phone numbers, email permissions, and file encoding.
6. Review automations and integrations: Identify workflows, notifications, ownership changes, and external processes triggered by imported records.
7. Prepare backup and recovery procedures: Save approved source exports and destination values, and rehearse how changes can be reversed.
8. Run a test import: Use representative records, including duplicates, missing values, existing customers, and unusual formatting.
9. Reconcile records and business workflows: Validate totals, associations, reports, permissions, and real user tasks.
10. Approve the final cutover: Define acceptable exceptions, sign-off responsibilities, support arrangements, and the production import sequence.

The sections below explain what to examine and what evidence to collect for each step.

1. Start With Customer Tasks and Work Backward

A customer relationship management system stores more than names and email addresses. It holds the context behind customer relationships. Losing the contract attached to an account can be more damaging than failing to transfer an unused custom field.

Consider a contract renewal.

The sales representative needs the current contract, the correct renewal date, and a person authorized to discuss it. The service team needs access to unresolved complaints. Finance needs the appropriate billing account.

These dependencies define the migration scope more usefully than a general instruction to move everything.

Start by identifying the business tasks that must work immediately after migration:

• Find a customer’s current contract and renewal date.
• Identify the correct company and associated contacts.
• Review open sales opportunities and service cases.
• Confirm customer communication preferences.
• Find the appropriate account owner and billing details.
• Generate the reports used for operational decisions.

From those tasks, identify which records and relationships must be preserved.

Open service cases may require their full history. Closed opportunities may need to remain available for reporting. Outdated prospect lists should go through an agreed retention review instead of being copied automatically.

What Sony Europe’s CRM Migration Illustrates

Sony Europe’s B2B teams encountered difficulties caused by inconsistent account definitions, duplicate customer records, and fragmented sales and marketing systems.

According to a June 2026 Microsoft customer case study, Sony Europe reduced custom CRM attributes by 79% when standardizing its data model and adopting Microsoft Dynamics 365.

Standard Dynamics 365 functionality replaced much of the previous customization, reducing the number of additional field definitions the organization needed to maintain.

The lesson for smaller CRM projects is practical: before transferring a custom field, identify who uses it and which business decision depends on it.

More fields do not automatically produce a better CRM.

Evidence to collect: An approved list of objects, fields, business processes, historical records, and exclusions.

2. Inventory Source Data and Assign Ownership

CRM information often comes from several places: a legacy CRM, spreadsheets, marketing platforms, customer-support software, accounting systems, and internal databases.

Before preparing an import file, create a source-data inventory.

For every source, record:

• Approximate record count and extraction date.
• Objects and fields included in the export.
• Responsible business owner.
• Known duplicates and missing values.
• Required data-retention rules.
• Where the data will be stored and who may access it.

Resolve disagreements about ownership before configuring the destination.

If sales and finance maintain different billing addresses, decide which application is authoritative. If multiple teams use the same contact status field differently, agree on its destination meaning before importing values.

Evidence to collect: A source inventory, named owners, baseline record counts, and documented retention decisions.

3. Decide Which Customer Records and Relationships Should Survive

Two legacy systems might both contain account 1042. Those identifiers do not necessarily refer to the same company.

Even matching names require caution. A headquarters and its subsidiary might need separate billing accounts, while one person may legitimately be associated with more than one organization.

Preserve both the source-system name and the original record identifier when creating the mapping between old and new CRM records.

A migration cross-reference table might look like this:

These identifiers are illustrative. Use the destination CRM’s actual record IDs and supported external-identifier properties.

The cross-reference helps the migration process connect records without relying on someone recognizing a company name.

Determine Your Import Sequence

Many migration workflows are easier to validate when parent records exist before related records are associated with them.

For example:

1. Import or identify company and account records.
2. Import contacts and map their company associations.
3. Import opportunities, contracts, or other dependent objects.
4. Import cases, activities, and relevant history.
5. Validate associations between the imported objects.

This is a planning sequence, not a universal platform requirement. Some CRM systems support multi-object imports that create or update records and their associations together.

HubSpot, for instance, documents multi-object association imports and the unique identifiers required to associate records correctly.

Ask the migration team to demonstrate that a repeated import updates the intended record instead of creating a duplicate.

Also define what happens when a contact matches multiple companies or when a required parent record cannot be identified.

Evidence to collect: Duplicate-matching rules, ID cross-references, association mappings, and tested import behavior.

4. Build a Field-Mapping Sheet Before Preparing the Import

A field map is more than a list of source and destination column names.

It should describe what each field means, how its value changes during migration, and which system takes priority when values conflict.

Consider a representative correcting a renewal date on Friday. On Monday, an older export arrives containing the previous date.

Both dates may be valid historical values. The customer match may also be correct. Yet the import still damages the record if it overwrites the approved correction.

Data migration therefore needs explicit update and survivorship rules.

Example CRM Field-Mapping Template

The field names are illustrative. Actual properties, especially consent and associations, depend on the CRM and its configuration.

Define How Conflicting Values Are Handled

An exception queue is preferable to silently choosing a value when the business rules do not establish a clear winner.

Check How Blank Values Behave

Blank fields do not always mean “remove the existing value.”

For example, HubSpot’s import-file documentation explains how blank spreadsheet cells are handled when updating existing properties.

An empty cell generally does not clear an existing property value. Removing an outdated value requires a separate supported operation.

This distinction should be included in the field-mapping rules, especially when the migration updates records already present in the destination.

Evidence to collect: An approved mapping workbook containing transformations, owners, validation rules, and treatment of missing or conflicting values.

5. Validate Dates, CSV Formatting, and Customer Permissions

Correctly formatted data is not automatically correct business data.

A migration file can pass every structural check and still introduce incorrect dates, monetary values, or marketing permissions.

Keep Calendar Dates Separate From Timestamps

Dates need particular attention in Microsoft Dynamics 365 and Dataverse.

Dataverse distinguishes between values that adjust to a user’s time zone and values intended to remain independent of time zones.

Microsoft’s date and time behavior documentation warns against combining Date only formatting with User local behavior when users should see the same calendar date.

A contract anniversary should generally remain the agreed calendar date, while a scheduled customer call may need an exact time and time-zone interpretation.

Test both cases using users in different time zones.

Check File Formatting Before Import

Validate the actual input files, including:

• Character encoding and accented customer names.
• Leading zeros in identifiers and postal codes.
• Commas, quotation marks, and line breaks inside notes.
• Unexpected spreadsheet type conversions.
• Decimal separators, currency codes, and numeric precision.
• Required fields, picklist values, and maximum field lengths.

RFC 4180 documents common CSV conventions, including the quoting used to preserve embedded commas, quotation marks, and line breaks inside fields.

However, individual CRM importers may have additional formatting requirements. Test the destination’s supported CSV conventions rather than assuming every exporter produces a compatible file.

When engineers need to inspect a fictional or sanitized test dataset, they can convert sample spreadsheet rows to JSON to examine field names and how values are represented.

Always inspect the output carefully. Spreadsheet and conversion tools may change how dates, numeric values, or identifiers with leading zeros are represented. A successful conversion does not establish that the resulting data is ready for CRM import.

Use approved processing environments for confidential customer information rather than uploading real CRM exports to an unapproved online utility.

Preserve Consent and Suppression Status

An old lead imported today must not automatically become eligible for a welcome email.

Before enabling campaigns, test contacts who have unsubscribed, withdrawn consent, or requested communication restrictions.

Confirm that the destination CRM and connected marketing tools interpret these restrictions correctly.

Consent is not always represented by a single Boolean field. It may involve subscription categories, timestamps, communication channels, legal bases, and suppression lists.

Map those elements according to the business’s policies and applicable legal requirements.

Evidence to collect: Validated sample files, date and currency tests, and approved consent mappings.

6. Check What Imported Records Will Trigger

A CRM migration changes more than stored data. It may activate emails, workflows, task assignments, lead-scoring rules, notifications, and integrations.

Before the first production import, identify which automated processes are connected to the records being migrated.

Test at least two scenarios:

• An unsubscribed lead is imported or updated without receiving an unauthorized campaign.
• An existing customer is updated without triggering an inappropriate welcome workflow or duplicate service task.

What Momentive’s CRM Consolidation Shows

A HubSpot case study about Momentive illustrates the operational impact of simplifying automation before consolidating systems.

Following acquisitions, Momentive had more than 200 website forms and 20 automated lead-qualification processes, alongside inconsistent naming conventions.

The company standardized fields and processes before consolidating its marketing systems. Its automated lead-qualification processes fell from 20 to two.

This was more than a change of CRM software. The migration involved redesigning the rules governing marketing operations.

Audit Automations and Connected Systems

Document which processes can:

• Send email or SMS messages.
• Update lead status or ownership.
• Create follow-up tasks.
• Start service workflows.
• Synchronize records with accounting or marketing software.
• Modify data in another connected application.

Then assign an owner to each process and decide whether it should be disabled, modified, or tested during migration.

In Microsoft environments, Dataverse settings for bypassing custom business logic do not automatically bypass Power Automate flows.

Microsoft explains that distinction in its Dataverse business-logic documentation.

Switching off one automation setting is therefore not sufficient evidence that every notification or downstream update has stopped.

Evidence to collect: An automation inventory, test results, and an approved plan for restarting workflows after migration.

7. Prepare a Backup and Recovery Plan Before the First Import

Migration recovery starts before records are changed.

Keep an approved, securely stored copy of the source data and any destination values that may be overwritten.

Creating records and updating records require different recovery methods.

Deleting newly created records does not restore property values that existed before an update. Likewise, restoring CRM records does not recall emails already delivered to customers.

Record the recovery procedure for each type of operation:

Understand CRM Restoration Limitations

HubSpot provides a CRM data restoration feature for eligible subscriptions and supported record types.

The feature can restore eligible CRM changes to a selected point within the previous 14 days. It requires Super Admin permissions, and the available actions depend on the affected objects and change types.

This is not a universal undo operation. Review the restoration preview and check how changes made after the selected point would be affected.

For Dynamics 365 and other CRM platforms, rehearse the recovery mechanism actually available in the destination environment.

Also establish how business changes made after the final source export will reach the new CRM.

Evidence to collect: Verified backups, a tested recovery procedure, the assigned recovery owner, and a documented cutover window.

8. Run a Representative Test Import

A test import should contain more than the cleanest records in the source system.

Use a controlled test environment where available and include cases that reflect the actual business data.

A representative sample should contain:

• An account with multiple associated contacts.
• A contact linked to more than one company, where supported.
• A duplicate email address or company name.
• A record with missing optional fields.
• An existing record that should be updated rather than recreated.
• A withdrawn marketing permission.
• A contract date that must remain unchanged across time zones.
• An accented name and multiline note.
• A record whose owner is no longer active.
• A customer with an open case and active renewal.

Run the test with the same import settings, transformations, permissions, and integration controls planned for production.

Review rejected rows, accepted updates, duplicate creation, and missing associations.

Understand Import Preview Limitations

HubSpot’s import troubleshooting documentation notes that its mapping-stage value correction tools can select values from the first 1,000 rows. Larger files may contain additional errors that remain unresolved.

This is a limitation of the interactive mapping-stage review, not a statement that HubSpot imports or validates only 1,000 records.

Validate the complete export and examine the completed import’s summary and error file instead of treating a clean preview as proof that all data is correct.

Evidence to collect: A test-import log containing processed, accepted, created, updated, rejected, and exception records.

9. Reconcile the Records and Test Real Customer Workflows

Return to the opening example.

The team started with 10,000 contacts, excluded 400 duplicates, and imported 9,600 records. The row-count reconciliation is correct:

10,000 source contacts – 400 approved exclusions = 9,600 expected destination records.

Yet 240 imported contacts have broken company associations.

Those broken relationships represent 2.5% of the imported contacts. If each correction takes three minutes, repairing them requires 12 hours of work.

The hypothetical import demonstrates why record counts alone do not establish migration success.

Reconcile Relationships Separately From Record Counts

After reconciling source and destination records, run a separate association check.

First, identify which source contacts are expected to have a company relationship. Then verify that each required relationship points to the correct destination company.

For example, if 9,200 of the 9,600 imported contacts are supposed to have a company association, the migration should reconcile those 9,200 expected relationships against the destination associations.

Contacts that legitimately have no company assignment should be documented as such rather than counted as migration failures.

The same principle applies to contacts associated with multiple companies, active deals linked to accounts, and support tickets linked to customers.

Compare approved source relationships with the destination’s actual relationships, not just the number of populated association fields.

Reconcile More Than the Total Number of Rows

Compare approved source records with destination records and documented exceptions.

At minimum, review:

• Source, imported, rejected, and intentionally excluded record counts.
• Duplicate merges and their surviving identifiers.
• Company-contact and other required associations.
• Contract values and financial totals by currency.
• Missing or conflicting owner assignments.
• Communication preferences and suppression lists.
• Historical activities and open customer-service cases.
• Business reports affected by the migration.

Keep a reconciliation log so every difference has an explanation, an owner, and a resolution status.

When reviewing non-sensitive mapping rules or configuration changes, developers can compare the original and revised text side by side to identify unexpected changes before applying them.

For production CRM records, use approved database queries, CRM reporting tools, or secure migration-validation scripts. A basic text comparison cannot verify record relationships or replace a complete migration reconciliation.

Let Employees Test the Imported Records

The more revealing test is whether employees can finish their work.

Ask a representative to open an account, find the current contract, identify the renewal date, and confirm who owns the relationship.

Ask the support team to locate a complaint that could affect the renewal conversation.

Ask finance to find the correct billing account and confirm the amount and currency.

Test restricted notes and record permissions after changes in ownership.

If employees must reopen legacy spreadsheets to complete these tasks, the migration may not be operationally ready.

Use failed tasks to plan corrective action and user training. A missing association needs a data repair; a confusing field may require a clearer interface or better instructions.

Evidence to collect: Reconciliation reports, exception logs, and user-acceptance test results approved by business owners.

10. Define Go/No-Go Criteria Before the Final Import

The final migration should not begin merely because a test upload succeeded.

Agree on the conditions required for approval before the production cutover window.

The following table provides an illustrative acceptance framework.

These are example approval criteria, not universal industry thresholds. Define acceptable exceptions and required results according to business risk, legal obligations, and the selected CRM.

Agree on the Production Cutover Sequence

Before the final import, document:

1. When the source export will be finalized.
2. Whether legacy data entry will be paused or restricted.
3. How changes made during the transition will be captured.
4. Who approves the production import.
5. Who monitors the import and connected applications.
6. When users will receive access to the new system.
7. When automations and integrations will be enabled.
8. Which conditions require stopping or reversing the cutover.

After launch, verify the first live working days rather than assuming success from the initial import report.

Evidence to collect: Signed go-live approval, cutover checklist, escalation contacts, and documented support arrangements.

What to Include in the CRM Migration Budget

A CRM implementation estimate that covers data loading but excludes validation and correction understates the work.

Ask whether the proposed migration scope includes:

• Source-system assessment and process mapping.
• Field mapping and data cleansing.
• Duplicate handling and association mapping.
• Test imports and repeated rehearsals.
• Investigation of rejected and incorrectly updated records.
• Automation and integration testing.
• Backup and recovery preparation.
• User acceptance testing and training.
• Post-launch support and issue resolution.

Keep CRM software subscriptions separate from implementation and migration services in the estimate.

If comparing external partners, ask for an example of a completed migration report from a similar project, with confidential details removed.

Look for reconciled totals, documented exceptions, and evidence that the migrated data supported real business tasks.

Also establish who will own data quality after launch. Ongoing corrections, new integrations, and changes in customer workflows can gradually introduce new inconsistencies unless someone remains responsible.

Final Go-Live Sign-Off Checklist

The opening checklist covers what to prepare. Before production cutover, use this final review to confirm that the required work has been completed and approved.

• Scope approved: Business owners have signed off on the objects, fields, and records being migrated or excluded.
• Reconciliation passed: Source and destination totals match the documented rules, and all unexplained differences have been resolved or approved.
• Relationships verified: Contacts, accounts, deals, and other critical associations match the expected source relationships.
• Consent confirmed: Suppression and communication-permission tests have passed.
• Business workflows accepted: Sales, service, marketing, and finance users can complete their critical tasks.
• Automation controlled: Connected workflows have been tested and approved for activation.
• Recovery rehearsed: Backups are available, and the recovery owner understands the rollback procedure.
• Cutover approved: The migration owner has documented the go/no-go decision and unresolved exceptions.
• Support assigned: Post-launch issues have named owners, escalation contacts, and response arrangements.

Do not approve a production import when unresolved problems could disrupt critical customer interactions, compromise consent restrictions, or cause unacceptable data loss.

Final Thoughts

CRM data migration is successful when customer relationships and business processes continue working, not simply when a spreadsheet imports without errors.

A representative should be able to find the right account, read the current contract, identify the authorized contact, and complete a renewal without reconstructing information from another system.

Achieving that outcome requires decisions about field ownership, duplicate handling, permissions, associations, automation, and recovery before the first production import.

Use the checklist to turn those decisions into documented tests and approvals. Keep unresolved exceptions visible, validate the records that matter most to the business, and assign responsibility for correcting data after launch.

The best CRM migration is one in which employees can continue serving customers with accurate information and minimal disruption.