CRM data migration reconciliation is not satisfied by equal source and target row counts. Customer records are relational: contacts belong to accounts, accounts may form legal or commercial hierarchies, opportunities refer to products and owners, and activities provide the context behind current state. Consent is purpose- and channel-sensitive evidence, not a convenient marketing flag. A migration can load every row and still leave sales teams with broken rollups, compliance teams with ambiguous permissions, and service teams without the history needed to act.
The acceptance question is whether the target supports the same approved business decisions with traceable meaning. That requires a source-to-target semantic contract, stable identity crosswalk, dependency-aware loading, consent provenance, and reconciliation at population, relationship, field, workflow, security, and user levels. Vendor tools can move records, but program owners must define what completeness means and who can accept residual exceptions.
Inventory CRM meaning and migration scope
Create an inventory by entity and population. Include active and inactive accounts, contacts, leads, opportunities, quotes, cases, assets, campaigns, consent records, notes, emails, appointments, tasks, attachments, custom objects, users, teams, territories, sharing artifacts, and audit history. For each, record the business purpose, owner, retention basis, volume, growth, sensitivity, source key, relationships, target representation, migration rule, archive choice, and acceptance method. Treat open transactions separately from closed historical records because they require different workflow and ownership validation.
Model relationships explicitly. Salesforce's ERD notation illustrates cardinality, optionality, recursive relationships, and relationship meaning; those distinctions matter even when platforms implement them differently. Document whether a contact must have an account, whether parent account means legal ownership or selling hierarchy, and whether an activity can relate to multiple business objects. Map source record types and polymorphic references to target concepts without assuming similarly named fields have equivalent semantics.
| Population | Core acceptance question | Common hidden failure | Evidence |
|---|---|---|---|
| Accounts and contacts | Are identity and relationships usable? | Duplicates, orphans, wrong parent, mutable key | Crosswalk and relationship tests |
| Consent | Can permitted contact be proven by purpose and channel? | Latest boolean erases source or withdrawal | Provenance samples and policy rules |
| Open pipeline | Can owners continue work without state loss? | Stage, amount, product, or approval mismatch | Workflow scenario reconciliation |
| Activity history | Can users understand prior interaction? | Broken regarding links, order, owners, attachments | Timeline and retrieval samples |
| Security | Do personas see only authorized records? | Ownership and sharing semantics change | Positive and negative access tests |
Resolve identity with durable crosswalks
Preserve every source record ID and assign the target ID in an immutable crosswalk with entity, source environment, migration run, match method, confidence, and disposition. Use stable organizational identifiers where available, but do not assume names, email addresses, or domains are unique or permanent. Define deterministic normalization and matching rules, then quarantine ambiguous candidates. A human-approved merge should retain the evidence and all source-to-survivor links so activities, consent, integrations, and later audit questions can follow the decision.
Run deduplication before and after loading. Before migration, it reduces known source debt and clarifies survivorship. After migration, it detects target-side automation, alternate keys, or concurrent creation that produced new duplicates. Define survivorship per field, including whether recent, verified, system-owned, or manually curated values prevail. Never let a generic newest-wins rule overwrite verified legal name, contact preference, or account ownership. Report unresolved identities as an exception population with value and business owner.
Rebuild account hierarchies without cycles or orphans
Separate legal, billing, service, and selling hierarchies if the source overloaded one parent field. Load accounts first without recursive parents, establish the crosswalk, then apply parent references in dependency order. Detect self-parenting, cycles, missing parents, excessive depth, and children attached to archived or out-of-scope parents. Decide whether excluded parents become minimal stub records, redirect to a retained ancestor, or leave an approved orphan. Each choice affects visibility, rollups, routing, and reporting.
Reconcile hierarchy edges, not just nodes. Compare counts by level, root population, child distribution, orphan rate, and selected full paths. Recalculate rollups and territory assignment in the target and compare business results for representative global, regional, subsidiary, and franchise structures. Ask account owners to validate high-value and structurally complex families. If the target has different sharing inheritance, include access validation because a correct parent link can still expose or hide records unexpectedly.
Preserve consent provenance and restrictions
Model contact permission as evidence: data subject, channel, purpose, status, source, captured time, effective time, notice or text version, lawful basis where applicable, geography, proof reference, expiry if defined, and withdrawal or objection. Under GDPR, consent must be demonstrable and withdrawal must be possible; other jurisdictions and lawful bases differ. Have privacy counsel approve the target model and migration rules. A single opt-in field cannot safely represent several brands, purposes, channels, and changes over time.
Use a conservative precedence policy. A later, scoped withdrawal should suppress the corresponding purpose and channel without inventing a broader withdrawal; an older broad permission should not override a newer restriction. Preserve original timestamps and source evidence rather than assigning the migration date. Reconcile status distributions by purpose, channel, jurisdiction, and source, then sample complex histories. Verify that downstream campaign, messaging, preference-center, and suppression integrations consume the governed target decision, not a stale copied field.
| Reconciliation layer | Measure | Example stop condition | Owner |
|---|---|---|---|
| Population | Expected, loaded, rejected, archived | Unexplained missing active records | Data lead |
| Relationship | Expected and valid edges | Cycle or material orphan population | CRM architect |
| Consent | Status and provenance parity | Unknown permission created | Privacy owner |
| History | Activities, links, timestamps, attachments | Missing high-risk case history | Business process owner |
| Workflow | Open work completes correctly | Critical stage cannot continue | Revenue or service owner |
| Security | Persona access and denial | Cross-team or cross-region exposure | Security owner |
Reconstruct activity history as a usable timeline
Decide which history remains live, becomes read-only, or moves to a governed archive. Preserve activity type, subject, body subject to retention, start and end time, original owner, participants, direction, completion state, regarding relationships, attachment reference, and source ID. Map departed users to historical identities rather than a generic migration user when audit and context require attribution. Maintain chronological meaning across time zones and distinguish business occurrence from migration creation time.
Attachments deserve their own control totals, hashes, malware handling, access rules, and retrieval tests. Microsoft guidance notes that activities and attachments can create substantial storage considerations; scope should be driven by business and retention needs, not only platform cost. Sample complete customer journeys across calls, emails, meetings, cases, opportunities, and documents. Verify search, timeline ordering, links, and permissions through the interfaces users will actually use. A blob count is not proof that a service agent can find the warranty photo.
Rehearse cutover and obtain layered sign-off
Run multiple full-volume rehearsals with production-shaped data, repeatable scripts, timed dependency steps, validation, and rollback. Establish a source freeze or controlled delta method and define how new records, edits, deletes, consent changes, and activities are captured during cutover. Make imports idempotent. Microsoft recommends a cutover plan with sequence, owners, verification, sign-off, and rollback, practiced in a test environment. Record actual durations and throughput rather than relying on estimates from small samples.
Use automated reconciliation for complete populations and human validation for business meaning. Publish exceptions with record IDs, reason, risk, owner, and disposition. Go/no-go criteria should distinguish zero-tolerance issues such as unauthorized consent or cross-boundary access from bounded defects that have approved workarounds. Obtain sign-off from data, CRM architecture, privacy, security, revenue or service operations, and support. After release, monitor duplicate creation, integration rejects, missing timeline complaints, hierarchy edits, and suppression failures through a defined stabilization period.
Business acceptance should use named personas and complete tasks, not isolated field checks. Ask an account executive to navigate a global hierarchy and update an open opportunity, a service agent to reconstruct a disputed case, a marketing operator to build a permitted audience, and a manager to review rollups. Capture the source records, expected target result, access context, and observed evidence. These scenarios reveal relational and permission defects that automated field comparison cannot interpret.
Key takeaways
- Define acceptance around business meaning, relationships, permission, workflow, and access, not source and target row counts alone.
- Keep immutable source-to-target identity crosswalks and auditable merge decisions for every migrated entity.
- Load and reconcile hierarchy edges deliberately, including cycles, orphans, rollups, territories, and inherited visibility.
- Preserve consent by purpose, channel, source, time, text, and restriction history under counsel-approved rules.
- Validate activity history through user retrieval and complete customer journeys, then rehearse delta handling and rollback at production volume.
Frequently asked questions
Why are matching record counts insufficient?
Counts do not prove correct identity, field meaning, parent-child relationships, consent restrictions, ownership, access, timeline links, or workflow behavior. They are one population control inside a broader reconciliation model.
Must every historical activity stay in the new CRM?
No. Keep history live when it supports current work, audit, or customer context; use a secure, searchable archive for appropriate older records; delete only under approved retention rules. The choice must preserve references and authorized retrieval.
Can consent be migrated as one current status?
That is risky when permission varies by purpose, channel, brand, jurisdiction, or time. Preserve provenance and restrictions needed to demonstrate and apply the approved contact decision, with privacy counsel defining jurisdiction-specific requirements.
Conclusion
A trustworthy CRM migration preserves the customer graph and the evidence around it. Semantic inventory, durable identity, relationship-aware loading, consent provenance, usable history, security tests, and layered sign-off turn migration from bulk transport into controlled business continuity. The remaining exceptions are then visible decisions, not surprises discovered by users after cutover.