A CRM migration is not complete when records appear in the new system. It is complete when the right data is accurate, connected, permissioned, reconciled and usable.
A dependable CRM migration checklist has eight control points: discover the source data, decide what should move, cleanse it, document the mapping, run repeatable test migrations, reconcile the result, rehearse cutover and define rollback before go-live. Treat data protection, ownership and acceptance criteria as part of every stage rather than a final compliance check.
One person approves scope, cleansing rules and the final migration decision.
Repeat the complete process until the result and duration are predictable.
Reconcile record counts, financial totals and a sampled record trail.
This guide is deliberately focused on moving data. It does not repeat the wider decisions involved in choosing and configuring a CRM. If you are still planning the wider programme, read our guide to Zoho CRM implementation costs in the UK.
Start with a migration control sheet
Before anyone exports a spreadsheet, create a control sheet. Record the source systems, target CRM, environments, accountable owner, authorised handlers, cutover window and acceptance criteria. Link it to the mapping, cleansing rules, issue log, test evidence and decision record.
List the business objects and date ranges in scope, plus explicit exclusions such as obsolete attachments or historic system logs.
Name a business data owner, a technical migration lead and representatives who can approve sales, marketing, service and finance data.
Agree completeness, accuracy, relationship, permission and performance tests before seeing the migrated result.
Record who can amend mappings, cleansing rules and scope. Re-test any change that could alter the output.
A migration becomes repeatable only after the extraction, transformation and load have been run against realistic data, timed and checked. Go-live is not the time for improvisation.
1. Discover what the source data really contains
System labels can mislead. “Contacts” may include former customers, suppliers and duplicate enquiries; notes may contain details that need a structured destination. Examine the content, relationships and use of each source—not only its headings.
| Inventory item | Questions to answer | Evidence to capture |
|---|---|---|
| Objects and volumes | Which accounts, contacts, leads, opportunities, activities, cases, products and attachments exist? | Counts by object, owner, status and useful date band. |
| Relationships | How are people connected to organisations, deals, emails and custom records? | Source keys, relationship rules and orphan counts. |
| Field quality | Which fields are empty, inconsistent, free text or overloaded? | Null rates, value frequencies and representative exceptions. |
| Operational dependencies | Which reports, automations, integrations and teams use the data? | Named consumers and impact if a field changes. |
| Compliance data | Where are lawful-basis, consent, preference, retention and suppression records held? | Source, timestamp, wording/version and permitted channels where relevant. |
Profile a full export or representative copy in a controlled environment. Count distinct identifiers and locate malformed dates, invalid postcodes, truncated text and encoding problems. Users will know which apparently unused fields drive reports or handovers.
2. Clean and deduplicate before loading
Do not use the target CRM as a cleaning bucket. Define a trustworthy record, apply the rules consistently and cleanse a controlled copy while preserving the untouched export.
- Standardise dates, country names, telephone formats, currencies and controlled pick-list values.
- Remove test records and data that has no defined business or retention purpose.
- Correct provable errors; do not “guess” missing personal details from unrelated sources.
- Define duplicate matching rules using more than one signal where possible, such as email, company domain and postcode.
- Agree survivor rules: which source wins for ownership, status, address, marketing preference and most-recent activity?
- Preserve conflicting values for review when an automatic merge could discard important history.
- Create an exception queue for records that cannot be resolved safely before cutover.
A “duplicate” person may represent two legitimate roles or relationships. Agree the matching and survivor policy with record owners before bulk merging.
3. Build a field-mapping specification
A mapping document is the contract between source and target. For each field, state its source, target, type, transformation, default, validation, owner and invalid-value behaviour. Include identifiers and relationship keys.
| Source | Target | Rule | Exception behaviour |
|---|---|---|---|
| Company name | Account name | Trim spaces; preserve legal punctuation. | Quarantine blank values if account is mandatory. |
| Lead status | Lifecycle stage | Translate through an approved value table. | Send unmapped values to the issue report—never silently default them. |
| Owner email | Record owner | Match against an active-user lookup. | Assign to a nominated holding owner and flag for review. |
| Legacy record ID | Migration reference | Retain as an immutable external key. | Reject duplicates and investigate before re-running. |
Document the load sequence: accounts may precede contacts, then opportunities and activities. Decide whether emails, notes and attachments need their original author and timestamp, and test for content limits.
4. Put UK GDPR controls into the migration
A migration does not remove data-protection responsibilities. The ICO’s data-protection principles include purpose limitation, minimisation, accuracy, storage limitation, security and accountability. Ask: should this data move, is it correct, who can access it, how long should it remain and can the decision be evidenced?
Confirm the processing purposes and lawful basis. If the new CRM introduces a materially different use, obtain appropriate data-protection advice rather than assuming the old decision covers it.
Review the CRM provider, sub-processors, contract terms and data locations. The ICO explains the controller–processor contract requirement.
Use least-privilege accounts, encrypted transfer methods, controlled staging areas and logs. Remove temporary access and migration copies according to the agreed schedule.
Preserve information needed to respond to access, correction, deletion and objection requests. Carry forward retention dates and marketing suppression records accurately.
Update the record of processing activities where required. The ICO’s ROPA audit framework highlights purposes, recipients, transfers, retention and security. Screen whether a DPIA is required before processing likely to result in high risk, including some dataset matching or large-scale sensitive-data activities.
Migrate the evidence behind the preference where it matters: source, channel, date, wording/version and any withdrawal or objection. The ICO recommends retaining a suppression or “do not contact” list so an opt-out is not accidentally lost when records are deleted or re-imported.
5. Run a full test migration
Use a safe test environment with representative volumes and edge cases. A tiny clean sample will not expose slow loads, broken relationships or unexpected values. Version repeatable steps and record the input, mapping version and run time.
Did records load without errors, preserve identifiers and connect to their parents? Are text, dates, currencies, files and audit fields intact?
Can users find a customer, understand the history, progress an opportunity and produce the operational reports they rely on?
Can each role see only what it should? Test ordinary users and exceptional roles—not just the administrator account.
Log every rejected or transformed record. Fix the rule and re-run rather than applying undocumented target patches. A clean repeat is stronger evidence than one-off corrections.
6. Reconcile the result and complete user acceptance testing
“The import succeeded” is not an acceptance test. Reconciliation should combine several forms of evidence:
- Counts: compare extracted, excluded, rejected and loaded records by object and agreed segment.
- Control totals: compare values such as open-pipeline amount, invoice totals or case volumes where relevant.
- Relationship checks: identify orphan contacts, activities without parents and opportunities without valid owners.
- Field-level samples: trace selected records from source through transformation to target, including awkward edge cases.
- Operational tests: run reports, searches, automations, permissions and representative end-to-end user journeys.
Define tolerances before testing. The signed reconciliation should explain every variance, including intended exclusions. Give business representatives written acceptance scenarios and record their approval or unresolved concerns.
7. Rehearse cutover—and agree rollback
The cutover plan should be repeatable by another authorised person. Include the freeze, final extraction, validation, load sequence, reconciliation, user activation, communications and latest safe rollback time.
| Gate | Go when… | Stop or roll back when… |
|---|---|---|
| Source extract | File checks, counts and timestamps match the approved scope. | The extract is incomplete, corrupted or taken outside the controlled freeze. |
| Target load | Error levels and duration remain within agreed limits. | Critical objects, identifiers or relationships fail. |
| Security | Roles and sharing rules pass representative tests. | Users can access records or fields they should not see. |
| Business acceptance | Reconciliation is explained and accountable owners approve release. | A critical process, report or customer history cannot be trusted. |
Rollback must state how the old system resumes, how cutover-window transactions are captured and who decides. Keep a protected source copy. NCSC cloud guidance recommends ensuring backups can restore a known good state—a useful migration standard too.
8. Stabilise, then retire the old system safely
After launch, separate migration issues from training and feature requests. Monitor rejected integrations, duplicates, ownership, key totals and access. Retain the mapping, transformation logic, source export, reconciliation and approvals as an evidence pack.
Do not cancel the old platform on day one. Confirm retention, audit and recovery needs first. Then remove integrations and access, obtain appropriate deletion or return assurances, and dispose of temporary files securely on schedule.
Approved mapping; repeatable migration; reconciled counts and totals; passed permissions; resolved critical issues; trained users; monitored integrations; accessible support; protected recovery copy; named go/no-go authority; written rollback route.
Futuro Digital Consultancy provides Zoho CRM consultancy and CRM strategy and optimisation for UK and EU service businesses, including data discovery, migration design, validation and practical handover.
CRM migration checklist FAQs
How long does a CRM migration take?
It depends on data volume, quality, relationships, attachments, integrations and stakeholder availability. A modest dataset can still require several test cycles. Estimate from discovery and a realistic trial run rather than record count alone.
Should we migrate every historic CRM record?
Usually not automatically. Move data that has a defined operational, legal or evidential purpose. Apply retention policies and consider an appropriately controlled archive for history that users do not need in the live CRM.
How many test migrations should we run?
Run enough complete cycles to make the result and timing predictable—commonly at least two after the process is technically working. Re-test whenever mappings, transformations or scope change materially.
What is CRM data reconciliation?
It is the comparison of source, exclusions, errors and target using counts, totals, relationships and record-level samples. Its purpose is to explain differences and demonstrate that the migrated data meets agreed acceptance criteria.
Can we migrate marketing consent into a new CRM?
Relevant preference and consent records may need to move, but a simple tick is rarely enough evidence. Preserve the source, channel, time, wording/version and withdrawal or objection history where applicable, and obtain specialist advice for your circumstances.
When should we roll back a migration?
Agree the triggers before cutover. Examples include a critical permission failure, unexplained material reconciliation variance, broken record relationships or an unavailable core process. The decision owner and latest safe rollback point should be written into the plan.
Plan a CRM migration you can evidence
Futuro Digital Consultancy can help you define the data scope, clean and map records, test the migration and build a controlled cutover plan around your teams and systems.
This article provides general operational information, not legal advice. Data-protection requirements and ICO guidance can change; confirm the current position and obtain appropriate professional advice for your organisation and migration.