CRM Data Migration
CRM Migration Data Quality: The Preflight Checklist That Prevents Bad Imports
ExpansaOS Editorial Team · 2026-10-31 · 7 min read

Quick answer
A safe CRM migration starts before the first import: define how every record is identified, decide which duplicate wins, document each field and relationship, and preserve the consent and retention context that makes a record usable. Prove the mapping on a representative test set, reconcile the production result against agreed controls, and keep a source snapshot plus a tested reversal path. The goal is not merely a completed upload; it is a target system whose records can be trusted.
Key takeaways
- Choose and test a stable source-to-target identity key before matching or updating any record.
- Treat merge rules and field transformations as governed decisions, with an exception queue for ambiguous matches.
- Map consent, lawful-basis context where applicable, suppression status, source, and retention review data rather than only contact details.
- Reconcile counts, relationships, required-field completion, and sampled business records before declaring cutover complete.
- A rollback plan needs a preserved source snapshot, import-level traceability, decision authority, and a platform-specific reversal procedure.
A CRM import can finish without errors and still weaken revenue operations. When a new CRM cannot tell whether an incoming row is an existing contact, a new company, or a duplicate, it can split history, overwrite a better value, or make communication status unclear. Complete this preflight before the detailed cutover plan. Its purpose is to establish records the business can trust.
Set a record-identity policy before deduplicating
Define an identity policy for every migrated object: contacts, companies, deals, activities, products, and custom objects in scope. For each, name the matching key, system of record, and action for a match, non-match, and uncertain match. A stable legacy record ID is often the strongest crosswalk key. Email and company domain can change, be shared, or be absent.
Vendor documentation shows why the rule must be explicit. HubSpot requires a unique identifier to match an imported row to an existing CRM record and documents record ID, contact email, company domain, and configured unique-value properties as possible identifiers. 1 Microsoft documents alternate keys for identifying and updating records during import, with duplicate-detection behavior dependent on the selected configuration. 3
Create an identity register. For example: legacy_contact_id maps to a non-editable migration crosswalk; email is a secondary review signal; records sharing an email but carrying different legacy IDs enter a steward queue. Automate only defined, high-confidence matches. Human review is appropriate where a merge could combine distinct people or accounts.
A duplicate rule also needs a survivor and field-level precedence, not just “keep the newest row.” The survivor may retain the canonical ID, while the most recently verified phone number wins and the most restrictive communication preference wins. Preserve losing IDs in an approved crosswalk so the result remains traceable.
Check relationships separately. A contact may be correctly identified but attached to the wrong company, opportunity, owner, or activity. List every relationship type, matching key, and load order. Test association labels or lookup mappings with edge cases rather than assuming related rows will connect correctly. 1 3
Turn field mapping into a governed contract
Make the mapping workbook a decision record, not a two-column heading list. For every source field, capture the source object and format, target object and field, transformation, allowed values, required status, owner, privacy classification, and blank-value rule. For excluded fields, state whether they are archived, deleted under policy, or retained only in the source snapshot.
Define values that look similar but mean different things. “Lead source” might be a campaign label in one system and a controlled attribution category in another. Specify the time zone and business meaning of dates such as created, updated, consented, and last activity. Map owners through a controlled user-ID crosswalk, not a display-name guess. For picklists, write the source-to-target value table and the disposition of values with no valid target equivalent. Microsoft notes that required mappings need source data and that unmapped values in a fixed value set may be dropped rather than created. 3
Use a test cohort small enough to inspect and varied enough to fail. Include ordinary records, duplicates, missing fields, changed emails, multiple relationships, inactive records, opt-outs, special characters, time-zone boundaries, and invalid values. Document expected results before importing.
Carry consent and retention context with the person
Migration does not reset data-protection obligations. For personal data in scope, identify the purpose, applicable lawful-basis or other authorization context as determined by the organization, source, communication preferences or suppression status, and the date or event needed for retention review. Do not collapse nuanced history into a generic “consented” flag. Permission for a channel or purpose is distinct from the fact that a person exists in the CRM.
Article 5 of the EU General Data Protection Regulation (GDPR) requires personal data to be adequate, relevant, and limited to what is necessary; accurate; retained in identifiable form no longer than necessary; and processed with appropriate security. It also makes the controller responsible for demonstrating compliance. 2 In practice, document why each personal-data field moves, where evidence lives, and how the target system will respect suppression and retention processes. This is operational guidance, not legal advice; the privacy or legal owner should assess applicable requirements.
Flag data that should be excluded, restricted, or accompanied by original evidence or an audit reference. Do not make a contact marketing-eligible merely because it was imported. HubSpot exposes separate legal-basis choices for imported contacts where its data-privacy settings are enabled, which is a reason to review target settings rather than assume the import carries the context needed. 1
Define reconciliation before cutover
Reconciliation asks whether the approved population, values, and relationships arrived as intended. Define controls before the production load so they cannot be relaxed afterward. Compare source and target by object, then review exceptions.
- Population: extract count, excluded count by reason, imported count, failed count, and duplicate or exception count.
- Identity: source IDs with exactly one target crosswalk, unmatched source IDs, and target records without an approved source ID.
- Completeness: required-field completion and null-rate comparison for selected business-critical fields.
- Relationships: expected parent, owner, and activity associations, plus a sample of high-value or recently active records.
- Consent and retention: counts by permission or suppression state and a sample of evidence fields and review dates.
Use automated comparisons and human inspection. Counts can hide a column shift or wrong-owner mapping; a risk-based sample can reveal both. Import-job reporting is part of the evidence. Microsoft distinguishes successful, failed, and partially failed rows and supports exporting error rows for correction. 3 Retain the extract, transformation version, import-file identifier, job report, exception log, and reconciliation sign-off.
Make rollback safe, specific, and authorized
“Undo if needed” is not a rollback plan. Preserve an immutable, access-controlled source extract and record which target records and properties each import can create or change. Name the person who may stop the load, the business owner who may authorize rollback, and the communication path if a critical control fails. Pause automations and downstream syncs where the approved cutover design requires it, so a bad update is not propagated during investigation.
Validate the reversal mechanism in a test environment. Some platforms can delete or restore import-associated changes; others require a purpose-built reversal file; limits can depend on object, subscription, and time window. HubSpot currently documents a CRM-change restoration capability for specified objects and plans, with rollback to a prior point within 14 days and import as a selectable restore source. 4 That vendor-specific feature does not replace an independent source snapshot or a tested destination-specific plan.
Set decision gates. Stop for identity-key corruption, unexpected overwrites, consent-state errors, or material relationship failures. Correct and retry bounded row errors that do not compromise control totals. Preserve the source state until the reconciliation owner accepts the result and the cutover plan’s rollback window has passed.
Preflight review checklist
Before production import, confirm that the team can answer yes to each question:
- Is there a documented identity and matching policy per object, including an exception workflow?
- Does every duplicate rule define survivor, field precedence, provenance, and review owner?
- Does the mapping define transformations, blanks, required fields, controlled values, relationships, and exclusions?
- Have consent, suppression, source, and retention-review data been deliberately handled for personal data in scope?
- Has a representative test demonstrated expected creates, updates, associations, errors, and non-overwrite behavior?
- Are reconciliation controls, acceptance thresholds, evidence, and sign-off owners agreed before loading?
- Can the team stop, reverse, and communicate a failed import using a tested, platform-specific path?
This preflight complements a detailed cutover plan; it does not replace one. The cutover plan governs timing, people, system changes, and communications. The preflight gives it clean identity rules, traceable mappings, acceptance evidence, and a safe response when the data does not behave as expected. For teams evaluating a revenue-operations platform, use the same questions to assess CRM and Pipeline capabilities and plan the operating model around them.
References
- HubSpot: Import records for multiple objects
- EUR-Lex: Regulation EU 2016/679 General Data Protection Regulation
- Microsoft Learn: Import data and control how duplicate records are identified
- HubSpot: Restore CRM changes
Frequently asked questions
What is the best unique identifier for a CRM migration?
There is no universal best identifier. Prefer a stable legacy record ID when it is consistently present and preserved in a source-to-target crosswalk; use business identifiers such as email or company domain only with documented limits and exception handling. Official HubSpot import guidance treats the identifier as the field used to match imported data to an existing record and lists record ID, email for contacts, company domain for companies, and configured unique-value properties as options. [1]
Should consent and opt-out fields be migrated with CRM contacts?
Where personal data and communications are in scope, migrate the context needed to apply the organization’s approved privacy, suppression, and retention processes, not just a generic consent flag. GDPR Article 5 requires purpose limitation, data minimisation, accuracy, storage limitation, security, and accountability; the applicable lawful basis and implementation should be reviewed by the organization’s privacy or legal owner. [2]
How do you reconcile a CRM migration after import?
Compare agreed source and target controls by object: approved and excluded population counts, imported and failed rows, one-to-one identity crosswalks, critical field completion, relationship integrity, and consent or suppression states. Review a risk-based sample and retain import reports and exception evidence. Microsoft documents import outcomes including successful, failed, and partially failed records, along with exporting failed rows for correction. [3]
AI-assisted editorial guidance with linked primary sources. Evaluate applicability and current product details before implementation.