A migration plan begins with use, not fields
A CRM migration succeeds when people can complete priority customer journeys with records they understand and trust. Moving every source column into a new container can preserve duplicates, obsolete meanings and hidden workarounds with greater speed. Begin by naming the decisions and interactions the target data must support.
Build the plan around entities such as organisations, contacts, opportunities, activities, consent records and service cases. For each entity, record its authoritative source, owner, lifecycle, relationships and required history. A migration tool can move values, but it cannot decide which source should win when two teams disagree.
Treat the first output as a migration contract: scope, exclusions, mapping rules, quality thresholds, privacy controls, reconciliation evidence, cutover conditions and accountable approvals. It should be concise enough to use during delivery and precise enough to prevent undocumented decisions inside scripts.
| Control | Question | Evidence |
|---|---|---|
| Purpose | Which journey or decision uses it? | Approved use cases |
| Authority | Which source and owner decide truth? | Source register |
| Quality | What is acceptable and how is it measured? | Profile and threshold |
| Privacy | Why is it needed and how long is it kept? | Processing and retention record |
| Reconciliation | How will completeness be proved? | Counts, totals and samples |
Inventory every source and shadow source
List production systems, marketing tools, service platforms, spreadsheets, shared drives, personal exports and integration stores that influence customer records. Record the owner, format, extraction method, update frequency, approximate volume and access restriction. A shadow source may be unofficial while still containing the value staff rely on.
Distinguish authoritative records from reference copies and convenience lists. If a spreadsheet repairs a missing segment or contact preference, investigate why the formal system cannot provide it. Migrating the sheet without resolving that gap creates a second shadow process in the new CRM.
Freeze new sources from appearing during the project without review. A late file is not automatically harmless. It may change identity matching, consent interpretation, cutover volume or the definition of a complete account. Route additions through the same owner and evidence process as the original scope.
Define identity and relationship rules
Decide how an organisation, person, household or location is identified. Email addresses change, names collide and a customer may hold several roles. Use stable source identifiers where available and preserve provenance so a merged record can be explained and, where necessary, separated.
Write matching rules in business language before implementing them. State which exact identifiers can merge automatically, which combinations suggest a candidate and which conflicts require review. A high fuzzy-match score is not authority to combine two people’s history.
Test relationships as carefully as individual fields. Account hierarchies, contact roles, opportunity ownership and service entitlements can survive row counts while becoming operationally wrong. Include relationship totals and representative journey checks in every rehearsal.
Profile quality by business consequence
Measure completeness, validity, uniqueness, consistency, timeliness and referential integrity, but connect each measure to use. A missing industry code may affect reporting, while a missing communication preference may create a privacy or customer-experience risk. The same percentage does not carry the same consequence.
Sample records from important cohorts and exceptions rather than reviewing only averages. Newly acquired customers, inactive accounts, international addresses, shared mailboxes and long-running service cases often expose rules that the dominant population hides.
Set thresholds with owners and treatments. Decide whether an issue is corrected at source, transformed, quarantined, accepted with a limitation or excluded. A migration should not silently invent a default that looks complete but changes the meaning of the record.
Minimise what enters the target
Question every field and historical period. Keep information when a current purpose, obligation or defensible operating need supports it. Convenience and the low cost of storage are not sufficient reasons to reproduce years of personal data in a system with wider access.
The UK Information Commissioner’s data minimisation guidance describes personal data as adequate, relevant and limited to what is necessary for the stated purpose. Organisations in other jurisdictions should confirm their own requirements, but the practical test remains valuable during migration design.
Separate archive, legal hold and operational history. A read-only governed store may suit records that must be retained but are not needed in everyday CRM journeys. Define access, search, export and deletion for that store rather than treating it as a forgotten remainder.
Build mapping and transformation as controlled decisions
For each target attribute, record source, transformation, allowed values, null treatment, owner and examples. Include formatting, time zones, currencies, controlled vocabularies and calculated values. A mapping document should show meaning, not only technical names.
Version the rules and link every change to a decision. If a team changes the definition of an active customer halfway through rehearsal, identify which extracts, metrics and tests must be repeated. Hidden rule drift makes two apparently successful loads incomparable.
Keep transformations reversible where practical. Preserve source identifiers and load references so an issue can be traced to the original record and rule version. Traceability shortens diagnosis and prevents a correction from becoming another unexplained overwrite.
Rehearse with real controls and safe data
Run multiple mock migrations through the actual extraction, transformation, load and reconciliation path. Use protected representative data or an approved substitute that still exposes lengths, relationships, character sets and edge cases. A tiny clean sample proves little about production behaviour.
Measure extraction duration, load performance, rejected records, manual review, reconciliation time and the support required after access begins. Test an interrupted load and a rollback. The cutover plan needs evidence about recovery, not only the ideal sequence.
Have sales, service, marketing, operations and administrators complete priority journeys. Ask them to trace a record, explain its provenance and handle an exception. User acceptance should validate data meaning and work, not merely confirm that fields appear on a screen.
Plan cutover as an operating event
Define the final extraction window, change freeze, delta method, access transition, communication, support capacity and go or no-go authority. State what happens to work created during the freeze. A cutover is incomplete if transactions must later be reconstructed from email and memory.
Use explicit acceptance measures: expected entity and relationship counts, control totals, critical-field thresholds, sample journey results, unresolved severity and rollback feasibility. A single overall accuracy percentage can hide a small but operationally decisive cohort.
Prepare hypercare by issue type. Routing every question to the migration team slows resolution and masks whether the cause is data, permission, workflow, integration or learning. Give each path an owner and a method for feeding repeated problems into permanent controls.
Close migration with reconciliation and deletion
After cutover, reconcile deltas, exceptions and deferred records. Obtain business approval against the defined thresholds and record accepted limitations with owners and dates. Do not close the project because the load job finished successfully.
Remove temporary files, privileged accounts, staging tables and local extracts according to the plan. Confirm that backup, support and analytics copies follow the same decision. Migration workspaces often become an ungoverned duplicate of the most sensitive customer data.
Transfer the mapping, quality rules, provenance and reconciliation evidence to the operating team. Connect recurring quality work to the enterprise applications pathway so the target does not deteriorate after project attention moves away.
Verify accuracy and lifecycle after the move
Migration acceptance should include a plan for keeping important records accurate after cutover. The ICO publishes guidance on the accuracy principle, which explains the need for reasonable steps and careful treatment of challenges to accuracy. Confirm the applicable framework for the organisation and jurisdiction.
Connect correction, duplication and suppression workflows to the ICO storage limitation guidance. A new CRM should not keep every migrated record indefinitely simply because the source did. Set operational owners for review and deletion before the project closes.
Schedule a post-cutover sample after ordinary teams have created and changed records. Compare provenance, relationships, duplicates, corrections and support demand with the migration baseline. This catches deterioration caused by new workflows rather than mislabelling every issue as a conversion defect.
