CRM migration acceptance checklist: keep customer history usable

A CRM migration is accepted when the agreed customer records remain connected, usable and accessible to the right people in the destination. Compare identifiers and counts, then have a permitted user complete representative sales or service tasks. Importing rows alone does not establish that relationships, ownership, history, reports or workflows survived the change.

This guide is for a sales, operations or systems owner comparing a CRM migration proposal. Moving to another CRM, importing a spreadsheet and building a new custom CRM are different engagements. A supported native importer may be sufficient. The purpose of the checks below is to make that decision and the acceptance boundary explicit before authorising access or cutover.

What are you actually moving?

A record import moves supported data. A platform transition may also require new field definitions, pipelines, permissions, automations, reports and integrations. Some items can be transferred through supported tooling; others must be configured, rebuilt, archived or explicitly excluded. Do not assume that copying a field recreates the rule that used it.

• Spreadsheet to an existing CRM: check identifiers, duplicates, required fields and the supported importer before commissioning code.
• CRM to CRM: inventory the objects, relationships, history, files and operating rules that the team needs in the destination.
• CRM connected to an ERP: distinguish the historical move from the ongoing sales-to-operations handoff. Use the separate CRM/ERP field-ownership example for that continuing connection.
• A new custom CRM: validate whether the actual process needs new software. Our custom CRM development scope compares a standard platform, a custom layer and a full build.

Feasibility depends on the source and destination products, editions, export/API permissions, record types and licensed features. If the work requires a certified platform specialist, identify that requirement before agreeing delivery. A vendor logo or an article about its API is not proof of implementation entitlement.

Eight checks to attach to a CRM migration proposal

Agree expected results with the business owner. These are proposed review cases, not tests run on your systems or a universal compliance standard. Use synthetic records first, then agree a secure and authorised process for representative production validation.

Why can a record exist while its context is missing?

Many import tools handle records and their links as separate concerns. HubSpot's import error reference documents cases where records are imported while an association or owner value is not. Its file-format guidance explains identifiers used for updates and associations. A completed import status therefore needs a review of errors and the destination behaviour you agreed.

Microsoft's Dataverse import documentation describes related data and ownership mapping. Check the corresponding capabilities for your actual products. These examples explain why the boundary matters; they do not establish identical behaviour or universal compatibility across CRMs.

Use one connected case instead of eight unrelated screenshots

Consider a synthetic company, Northbridge Example, with two contacts, two deals, an open task and an attachment. One deal belongs to an inactive salesperson. One contact has a corrected address, and another source row is a known duplicate. The agreed user should be able to open the company, find the intended people, inspect both deals and identify the next task without searching an unrelated archive.

Follow that same case through the mapping, trial import, exception correction and acceptance review. Ask the implementation team to show the old-to-new references and any intentionally omitted fields. Then sign in as a permitted operator to inspect the result. Screenshots taken by an administrator cannot establish what an ordinary salesperson can access.

Try the restricted role as a separate check. A migration that makes formerly restricted notes visible to everyone has not preserved the intended access boundary. Where the source and destination models differ, the owner must approve the destination rule. Do not quietly replace a difficult restriction with broader access.

What about files and old communication history?

Ask whether each type remains a native record, becomes a linked archive or is excluded. A file copied to storage may still lack its original record link. An exported email entry does not automatically grant mailbox access or recreate attachments and threading. Record the required viewing behaviour, retention decision and any platform limitations before pricing the move.

For example, Salesforce's attachment export guidance describes files named by record ID and metadata used to recover their names. Other content types have separate instructions. Keep the source identifiers and file metadata together; a readable filename alone cannot establish the correct destination relationship.

Compare record counts as a useful control, but also compare agreed relationships and usable tasks. Two imports can contain the same number of rows while assigning different owners or linking a contact to the wrong account. A sample exercises named risks; it does not prove every record correct. Agree wider reconciliation appropriate to the volume and consequences.

Agree how work continues while the data moves

A first export is a point-in-time baseline. If staff continue changing the source, those changes need an agreed route to the destination. A freeze may suit one business; another needs staged migration and a delta process. Define which system accepts new work during each stage and who handles an urgent change. Avoid making both systems silently authoritative.

1. Inventory supported exports, fields, relationships, files, users, automations and integrations.
2. Agree the mapping and exclusions with a named business owner, including duplicate and inactive-user rules.
3. Trial the connected review case, inspect exceptions and rehearse operator tasks in a permitted environment.
4. Reconcile the authorised baseline and changes made during the move. Record open differences and who accepts them.
5. Activate destination workflows and integrations under the agreed plan, then confirm who monitors them and responds.

Stopping an import, restoring a backup and undoing downstream business actions are different forms of recovery. A rollback plan must account for new work created after the switch. Reverting code cannot unsend an email or reverse an accounting action. Agree supported restoration, pause controls, ownership and the point at which recovery needs business review.

Compare the same first engagement

Ask each provider to price the same boundary: source and destination editions, record and relationship types, permitted access, data quality, trial scope, cutover window, acceptance owner and support. Separate data transfer from rebuilding workflows, reports and connections. Confirm who controls exports, credentials, backups and the final configuration.

• Use the native tool when its documented scope and your acceptance checks cover the requirement.
• Use a specialist migration product or ecosystem provider when it supports the required pair, history and operational responsibilities. Verify current entitlement and exclusions.
• Commission a custom boundary when the unsupported requirement is specific, feasible and valuable enough to justify development and maintenance.

A useful first milestone can be a migration feasibility and acceptance plan. Its outputs are an inventory, proposed mapping, exclusions, representative checks, risk decisions and an implementation estimate. It may conclude that configuration or a specialist provider is sufficient. Timelines and fees follow the actual access and data review, rather than a universal promise of a loss-free weekend migration.

StackEndBox's CRM transition review starts from that decision. Include only the products and editions, the history that must remain usable, approximate volume and the intended switch window in an initial enquiry. Keep production exports, private customer records and credentials out of the public form. Any later data review needs an agreed secure process.

If the CRM remains in place and only another application needs a connection, compare CRM/ERP integration or API integration scope instead. The right first project is the smallest boundary that meets the business requirement.