A CRM data migration needs a clear scope, mapped records and relationships, tested imports and business sign-off. An import finishing successfully does not prove that users can find the right customer, see the correct history or continue an open opportunity. Plan for those outcomes before moving data.
Decide what belongs in the new CRM
List the sources you use today: CRM records, spreadsheets, documents and connected applications. For each dataset, decide whether to migrate it, retain it in an accessible archive or exclude it under your agreed retention rules. Do not delete the source merely because an import appears complete.
Separate application setup from business records. Status values, currencies and ownership rules affect how customer data behaves. Microsoft’s data management guidance distinguishes configuration data from migration data and treats both as planned project work.
Prepare a mapping your business can approve
Assign a business owner to each dataset. That person should decide ambiguous meanings, not simply receive a spreadsheet after the import. Preserve a stable source identifier so that migrated records can be traced and reconciled.
| Area | Decision to document | Evidence to keep |
|---|---|---|
| Record scope | Which customers, contacts, activities and open work move? | Approved inclusion and exclusion rules. |
| Field meaning | How do dates, statuses, currencies and required values map? | A field map with transformation rules. |
| Relationships | How are contacts, accounts and transactions linked? | Source-to-target identifiers and dependency order. |
| Duplicates | What identifies a duplicate and who approves a merge? | Matching rules and an exception list. |
| Ownership | Which user or team owns each record? | Owner mapping and access checks. |
| Attachments | Which files and history are needed, and where? | Transfer method and validation samples. |
Validate the chosen import method against current vendor documentation. For example, Zoho’s migration guidance includes mapping, mandatory fields and user ownership considerations. Product-specific limits and supported formats should be checked for your actual method and environment.
Test a representative sample first
Include clean records and difficult ones: missing owners, duplicate contacts, unusual characters, inactive customers and records with several related activities. Keep a record of rejected rows and their reasons. Correct the transformation or source data, then rerun a controlled test to confirm the fix.
Illustrative scenario, not a client case study. A company has one customer account, several contacts, an open opportunity and an unresolved service request. Its migration test follows this whole group into the new CRM. The reviewer checks that the opportunity and request remain attached to the right customer and that the assigned teams can open them.
Validate more than record totals
Reconcile totals by dataset and explain every exclusion or rejection. Then inspect key values, linked records, owners and attachments. Ask business users to complete relevant tasks with the migrated data using their intended access roles. Keep the evidence and the reviewer’s decision alongside the migration run.
A record can exist but still be operationally wrong. A closed opportunity might appear in the active pipeline, a date might shift or a user might see another team’s restricted records. Test these outcomes explicitly rather than assuming the import tool covers them.
Agree the final move and recovery plan
Document the order of the final export, import, validation and release to users. Decide how changes made after the last export will be captured. Name the people who make the go/no-go decision and define what happens if validation fails. Record backups, recovery steps and access to the old system.
Microsoft’s go-live checklist brings together migration validation, user acceptance, dependencies, cutover and operational support. Use the parts relevant to your project, then agree your own acceptance evidence and responsibilities.
Questions about CRM migration
Should we migrate every historical record?
Not automatically. Agree what users need for daily work, reporting and applicable retention obligations. An archive may be more appropriate for some history.
Can we migrate from spreadsheets?
Often, but first review column meanings, identifiers, relationships and data quality. A spreadsheet is a source, not a complete migration specification.
Can the migration happen without downtime?
That depends on the source and target systems, volumes, connections and cutover method. Establish the available options through testing before promising a service window.
Who should approve the migration?
The agreed business owners should accept the data and workflows, supported by technical validation. Record who approves exceptions and who owns unresolved issues.
Prepare for your move
Explore our Dynamics 365, Salesforce, Zoho and integration services. Bring a source inventory and one representative workflow to discuss your migration.
This checklist is DVMSKE’s planning guidance. The official references above explain platform requirements; the migration method and acceptance criteria must be agreed for your systems.
