A CRM import can finish successfully while leaving a sales team with the wrong pipeline. The contact count may match, yet deals belong to inactive users, notes point to the wrong company, or a repeat import creates another copy of every opportunity.
CRM migration validation means proving that the intended records, relationships and business values survived the move. Before cutover, reconcile the agreed source population, compare records by stable identifiers, test relationships separately, and obtain business sign-off on the exceptions. A green import status is evidence that a job ran; it is not evidence that the new CRM is ready.
This guide provides a practical acceptance worksheet for a team moving between CRMs. The worked numbers are illustrative, not results from an ICT client project. Product documentation was checked on 27 October 2026.
1. Define what the destination should contain
Write down the scope before comparing totals. Separate companies, contacts, deals, activities, attachments and custom objects. For each, record the source export time, filter, owner and destination. Keep the original export unchanged and work from a copy. Restrict access to both copies because a CRM export may contain customer information.
Use a specific snapshot boundary such as “records included in export batch M01 at the recorded UTC timestamp.” A vague instruction to move “all active customers” is difficult to test: a salesperson may change a customer's status between the export and your reconciliation.
Document every exclusion and merge. An archived record is different from a rejected import; two contacts intentionally merged into one are different from a missing contact. Preserve the approval and source identifiers behind each decision. Do not infer permission to delete history from a generic retention rule.
Configuration needs its own review. User accounts, currencies, pipeline stages and required fields determine how imported records behave. Microsoft's migration planning guidance distinguishes configuration from migrated business data and calls for defined dependencies and validation. Apply that distinction to your own destination rather than assuming an export includes its configuration.
2. Build an identity map before loading relationships
Keep a mapping between each source record and its destination record. Use separate columns for source system, source object, source ID, destination object and destination ID. Add the migration batch, result and approved merge target. A source ID alone can collide when two systems both contain a contact numbered 123.
Do not paste an old CRM's internal identifier into a destination's native Record ID field. They belong to different systems. Use a supported external identifier or a controlled mapping file, and record the new destination ID after creation.
HubSpot's import documentation explains its supported identifiers, including Record ID, contact email, company domain and qualifying custom unique properties. It also states that a mapped Record ID takes precedence over other mapped identifiers. Check the destination's actual rules before using email as a universal matching key.
Test the mapping with awkward records: a contact with no email, two people sharing a mailbox, a company with multiple domains, and two opportunities with the same name. If the matching rule cannot distinguish them, resolve that design question before the full import.
3. Reconcile distinct records, not spreadsheet rows
A useful reconciliation begins with an expected destination population. In a simple migration into an empty destination, use:
Expected distinct destination records = source records in scope − approved exclusions − records absorbed into approved merges.
For a destination that already contains data, reconcile the migration population separately using your identity map. A successful update may create no new record. Comparing the total number of destination contacts with the number of imported rows will give the wrong answer.
| Measure | Example | Evidence to retain |
|---|---|---|
| Source contacts in scope | 1,000 | Snapshot and exact filter |
| Approved exclusions | 80 | Source IDs and decision owner |
| Contacts absorbed into merges | 20 | Each absorbed ID and surviving ID |
| Expected distinct contacts | 900 | 1,000 − 80 − 20 |
| Distinct mapped destination contacts | 897 | Destination export joined to identity map |
| Unresolved shortfall | 3 | Rejected or missing IDs to investigate |
The three missing contacts do not become acceptable because the total is close. Determine whether they are test records, important decision-makers or records with a broken transformation. The business impact, not just the percentage, determines whether cutover can proceed.
Also compare identifier sets. Equal counts can conceal one missing record and one unintended duplicate. Check for source IDs without a destination mapping, unexpected destination records in the batch, and multiple destination IDs assigned to a source record where the mapping should be one-to-one.
Repeated rows are not necessarily duplicates. HubSpot's file-format guidance describes repeating a record's identifier to associate it with multiple records. Count distinct entities and relationship pairs separately. Otherwise, a valid association file can look like an inflated contact import.
4. Compare values using explicit transformation rules
Field names do not establish equivalent meaning. “Revenue” might mean annual company revenue in one system and opportunity value in another. Give each important field a business definition, transformation rule, null rule and acceptance check.
| Field | Rule to decide | Validation test |
|---|---|---|
| Deal amount | Preserve amount and currency together | Compare per record and sum by currency and stage |
| Close date | Distinguish date-only values from timestamps | Check boundary dates and intended local display |
| Owner | Map active users; name an approved fallback | List unmapped and fallback-owned records |
| Pipeline stage | Use an approved source-to-target mapping | Compare counts and values by mapped stage |
| Empty values | Define leave unchanged, clear or default | Test each behavior on existing destination records |
| Communication preferences | Preserve evidence and suppression meaning | Check that an import does not activate unintended messaging |
For teams operating across the US, UK, Singapore and UAE, keep currency codes explicit: USD, GBP, SGD and AED are not interchangeable amounts. A combined total without a documented conversion rule is not a useful reconciliation. If the business needs a reporting currency, record the rate source, effective date and rounding rule separately from the original value.
Test date interpretation with deliberately ambiguous inputs, such as 03/04/2026. Agree on the input format before conversion. For timestamps, compare the underlying instant as well as the user's local display. For date-only deadlines, avoid introducing a timezone conversion that changes the calendar day.
These are technical acceptance checks, not a claim that importing consent fields makes a system legally compliant. Have the responsible business owner confirm the intended communication and retention behavior.
5. Treat relationships and history as separate deliverables
A contact can exist without its correct company association. A deal can have the right value but the wrong primary contact. Export or inspect relationships explicitly and compare expected source-to-target pairs through the identity map.
For each relationship type, record the expected pair count, actual pair count, missing pairs, unexpected pairs and unresolved parent IDs. Test both directions where the CRM exposes them: open the company and find its contacts, then open a contact and verify its company.
Review history separately. A migrated note is not necessarily a migrated email thread, attachment or task. Define which history types must remain editable, which can be archived, and how users will retrieve them. Open representative attachments and confirm they are attached to the intended record; a filename in a CSV is not proof that the file moved.
Choose a risk-based sample alongside automated comparisons. Include high-value open deals, records with several associations, unusual characters, long notes, missing optional values and inactive owners. Record why each sample was selected so that a later reviewer can reproduce the checks.
6. Rehearse retries and the final change window
Run a small representative migration into an isolated test environment first. Suppress outbound messages and unrelated integrations there. Then repeat the same batch. The second run should behave according to the documented update or skip rules, without creating unintended records or triggering customer communications.
HubSpot's multiple-object import instructions say that a blank Record ID value can create a new record. This is one reason a partially populated identifier column deserves a deliberate test before a retry. Do not assume that selecting an update-oriented workflow makes every row safe.
For the final migration, choose how to handle changes after the initial snapshot. A write freeze may be suitable for one business; another needs a controlled incremental export. Capture updates and deletions as well as new records, and decide what happens if both systems change the same record. Reconcile the final batch using the same rules as the rehearsal.
Keep website lead delivery in this cutover plan. Identify the point at which forms start sending to the new destination and how queued submissions will be handled. ICT's WordPress CRM integration guide covers ongoing form delivery; use it for that separate connection after defining the migration boundary.
7. Make the go-live decision from an exception register
Maintain one exception register with the object, source ID, failed check, business impact, owner, resolution and retest result. Keep personal data out of shared status summaries where identifiers will suffice. Every accepted exception needs a named approver and a documented reason.
| Gate | Required evidence |
|---|---|
| Identity and population | All in-scope IDs accounted for, with exclusions and merges approved |
| Critical data | Open-deal values, ownership and required relationships reconciled |
| Daily work | Users can find a customer, update a deal and complete a follow-up |
| Integrations | New leads and downstream updates reach the intended destination once |
| Recovery | Named decision owner, rollback trigger and tested recovery steps |
A rollback plan must address writes made after go-live. Restoring yesterday's data does not preserve today's sales updates. Decide how those changes will be captured and reconciled if the team returns to the old CRM. Keep the old system available under the agreed access policy until the acceptance period ends.
If custom objects or connected applications make reconciliation difficult, discuss the required data model and integration work through ICT's custom ERP and CRM development services. Bring an anonymized field map, object counts and exception examples so the scope can be assessed.
Where migration effort actually goes
Estimate effort by work package: source extraction, cleanup decisions, field transformation, relationship loading, history transfer, integration changes, rehearsal, reconciliation and post-cutover support. Record volume alone cannot describe the complexity. A small dataset with undocumented custom objects can require more design work than a larger, consistent contact list.
A migration tool can move supported objects efficiently, but evaluate its behavior with your own sample before committing. Ask what it omits, how it identifies updates, what error evidence it produces and how it handles attachments. Choose custom development when the transformation or connection is genuinely specific to your workflow, not simply because a manual import feels inconvenient.
For a broader implementation discussion, use the ICT software services page to describe the existing systems, desired workflow and measurable acceptance criteria.
Frequently asked questions
How do you validate a CRM migration?
Define the expected population, map source IDs to destination IDs, reconcile distinct records and relationships, compare critical values, test daily workflows and document exceptions. Repeat the checks after the final change batch, not only during rehearsal.
Are matching record counts enough?
No. Equal totals can hide missing records, duplicates or incorrect associations. Compare identifier sets and business values as well as counts.
Should every source record appear in the new CRM?
Only if that is the approved scope. Exclusions and merges can legitimately reduce the count, but each reduction should be traceable. A rejected import is not an approved exclusion.
Can we rerun a failed import?
First determine which records already succeeded and how the destination identifies updates. Correct the failed subset or use a tested repeatable process. Blindly rerunning a create operation can introduce duplicates.
How long should validation take?
Measure it during rehearsal using the actual object types, transformations and exception review process. Reserve time for fixing and retesting failures. A universal number of days would hide the differences between migrations.
When is it safe to switch off the old CRM?
After the business has accepted the migration, required history remains accessible, integrations are stable and the agreed recovery period has ended. Confirm the export and retention arrangements before cancelling access.
Your next step
Choose one object and complete its reconciliation before expanding the migration. You should be able to explain where every in-scope record went, why any were excluded, and how its relationships were preserved. That evidence makes the cutover decision much clearer than an import success message.
