CRM Data Migration Without Losing History: UK Guide

In charity CRM projects, everyone checks whether contacts and donations arrived in the new system. Fewer teams check whether the history that gives those records meaning survived intact. Which campaign produced the donor, when consent wording changed, why a direct debit failed, what stewardship notes informed the next ask. Lose that layer and the new CRM starts with clean tables but weaker fundraising and compliance capability. This guide focuses on preserving history, because that is where most migration value sits.

Define what history means before extracting data

History is not just notes. For most UK charities it includes donation chronology, campaign attribution, consent provenance, communication interactions, payment status events, volunteer or service episodes, and key relationship touchpoints. If these are not explicitly listed in scope, they get partially migrated by accident.

1. Create a history scope list approved by fundraising, operations, and compliance owners.
2. Mark each history element as mandatory in target, archive-only, or drop.
3. Assign source tables and target destinations for each element.
4. Define acceptance tests for each element before build starts.

Field mapping is not enough: map business meaning

Technical mapping alone does not preserve reporting intent. A field called campaign_code may represent different logic across systems. Document meaning, not just format. For every critical field, state how users relied on it in decisions and reports. If the target model changes, document the replacement logic.

This is especially important for consent fields and fundraising attribution. The legal and operational meaning must survive, even if field names change.

The three reconciliations that matter most

1. Financial reconciliation

Total donations by period, payment method, and status should match agreed tolerances between source and target. Include refunded and failed payments, not just successful gifts.

2. Supporter reconciliation

Unique supporter counts by key segments (active donors, regular givers, volunteers) should match. Duplicates and merges should be audited to ensure survivor-record logic did not remove valid history.

3. Consent reconciliation

Channel permissions, legal basis, and consent timestamps should match for active supporters, with random sample evidence checks back to source records.

Parallel run and report continuity

Run old and new reporting in parallel for one or two reporting cycles. During this period, finance and fundraising should compare headline metrics and segment-level outputs. Differences are normal where model logic changed, but every difference must be explained and documented.

Prepare a transition note for trustees describing any metric-definition changes so board papers remain interpretable across periods.

Cutover sequence that protects history

1. Announce source-system freeze window and user responsibilities.
2. Take final source extract including delta changes since last rehearsal.
3. Load to target and run automated validation scripts.
4. Run reconciliation suite and sample audit checks.
5. Sign off release gate with named owners from finance, fundraising, and compliance.
6. Open target system with extended support cover in the first week.

Rollback planning is part of governance

Rollback is not pessimism. It is a control. Define what conditions trigger rollback, how long rollback remains viable, and who can authorise it. Without this, teams push forward despite material history defects because there is no clear alternative path.

• Keep source system read-only available during initial go-live window.
• Retain migration scripts and logs for replayability.
• Document point-of-no-return event clearly in runbook.

A CRM migration is successful when users trust history on day one. If they cannot trust what happened before, they will not trust what the new system says now.

First 30 days after go-live

Prioritise defect triage on history-impacting issues, not cosmetic fields. Monitor fundraising operations, supporter care workflows, and compliance reporting closely. Close high-severity data defects quickly and publish weekly status to leadership. Teams that run disciplined post-go-live control usually stabilise within one month and preserve confidence. Teams that underinvest in this period often spend six months repairing credibility.

Related reading: CRM Data Quality: The Monthly Routine, Password Managers For Charity Teams: Practical Rollout and MFA Rollout Without Tears: A UK Charity Field Guide.