Operations
Part of Customer data platform migration UK: how to avoid data loss
Customer data platform migration UK: how to avoid data loss
A practical customer data platform migration UK guide: sequence the move off a legacy CRM or DMP, keep a rollback point and stay inside UK data rules.
What to take away
- Most migration data loss is created before cutover, by untested field mappings and unresolved identifiers.
- Keep the legacy system available, and writable, until a dated rollback window closes.
- Move in batches by source or audience, so one fault affects a single slice rather than the whole estate.
- Decide retention, lawful basis and any transfer route before the first extract leaves the old system.
- A customer data platform inherits old defects, so clean records at onboarding rather than after go-live.
Why migration data loss starts before cutover
Data loss rarely happens at the moment the new platform goes live. It happens in the weeks before, when a field mapping is agreed in a meeting and never tested against the real spread of values in the source table.
Two failures do most of the damage. The first is identity: the same person exists under a work email, a personal email and a phone number that has since changed. The second is history: the legacy system often holds the only record of consent and suppression flags.
Sorting that out is cheaper before the pipeline exists: profile the source fields, count nulls and default values, and de-duplicate on verified identifiers while the old platform is still the reference copy. Our guide to customer data quality before implementation covers the checks worth running in more detail.
A seven-step migration sequence with a rollback point
The sequence below assumes the legacy platform keeps running throughout. Each step ends with an artefact somebody can inspect later: a signed mapping, a failed-value log, a merge rule, a consent extract, a reconciliation sheet or a switch-off record.
- Freeze the field inventory. List every source table and field, the target object and field it maps to, its format, and the owner who signs the mapping off. Anything without a named owner stays out of the first slice.
- Test the mapping against the real spread of values. Run it over a full extract rather than a tidy sample, and log every value that fails to parse, truncates or lands in a default.
- Set the identity resolution rules. Decide which identifier wins when a work email, a personal email and an old phone number point at one person, match on verified identifiers before any fuzzy name or address matching, and record how a merge is reversed if a customer asks.
- Carry consent, suppression and erasure state across. Move the lawful basis, the consent wording and the soft opt-in evidence with each audience, and hold back records with an open erasure request until the request is closed in both systems.
- Fix the batch order. Move the smallest, least critical audience first and the largest or most consent-heavy audience last, so a fault is contained to one slice.
- Reconcile each slice against the tolerance agreed for that table before the next one starts. Row counts, null rates, consent counts and suppression counts are signed off by the data owner, not by the project team alone.
- Cut over, then close the rollback window. The legacy system goes read-only, and then off, on the dates written into the plan, and the closure is recorded with the evidence from step six.
Seven-step migration sequence
- Inventory every source field and owner
- Agree identity keys and conflict rules
- Profile real values, not documented ones
- Dry load and compare counts and nulls
- Migrate one audience or region first
- Freeze writes, route new to both
- Close rollback after line-for-line match
The rollback point is the purpose of the sequence. If the first slice cannot be reversed inside a working day, the plan is too aggressive for the estate you actually have.
Roll a slice back when any of these is true: the row count, consent count or suppression count for that table falls outside the tolerance agreed for it; a customer cannot be deleted in the new platform while the legacy copy still holds them; or the slice cannot be reversed before the window closes. Put the date the legacy system goes read-only and the date it switches off in the plan, and name the one person who can authorise the reversal.
UK data residency and what the law already requires
Personal data moving into a customer data platform stays governed by the Data Protection Act 2018, whatever the hosting region.
Hosting in the UK removes one question, not all of them. You still need a retention schedule, a lawful basis recorded for each audience, and a tested route for erasure requests while both systems hold the same person.
Build the retention schedule before the extract, not after it. Set a retention period per audience and per source table, record the trigger that starts the clock, apply the same periods in the new platform, and delete anything already held beyond its period rather than migrating it across. Review the schedule at least once a year and whenever a new audience is added.
Practical expectations on transfers, retention and accountability sit in the ICO's UK GDPR guidance and resources hub, which is worth reading before the extract design is fixed.
Where a supplier, a group company or a support team outside the UK can reach the data, that access is a transfer and needs a transfer mechanism: the ICO's International Data Transfer Agreement, the International Data Transfer Addendum to the EU standard contractual clauses, or a UK adequacy regulation. Record a transfer risk assessment alongside whichever route applies, and note who can reach the data, and from where.
If migrated audiences will drive email or SMS, the privacy rules for electronic marketing apply alongside the UK GDPR, so consent and soft opt-in evidence must survive the move. The ICO's direct marketing guidance sets out what that evidence looks like.
What to freeze, check and reconcile
| Check | Evidence to keep |
|---|---|
| Source row counts by table | Dated extract counts from the legacy system |
| Null and default rates per field | The profiling report from step three |
| Consent and suppression flags | Field-level mapping naming the legacy owner |
| Erasure requests in flight | Log with request dates and handling system |
| Identity merge rate | A hand-checked sample of 200 merged profiles |
| Post-migration reconciliation | Counts inside the agreed tolerance |
Reconciliation tolerances should be agreed in writing before anything moves, table by table, and recorded in the migration plan. A gap of a few dozen rows is ordinary where timestamps differ; a gap of a few thousand means the mapping is wrong. Consent, suppression and erasure tables carry no tolerance at all: one missing or altered flag stops the slice. High-volume event tables can carry a small tolerance, but only where the timing difference between the two extracts is documented and the same on every run.
Freeze, check, reconcile
- Source row counts by table
- Null and default rates per field
- Consent and suppression flags
- Erasure requests in flight
- Identity merge rate sample
- Post-migration reconciliation counts
Once the slice is live, an observable customer data platform workflow keeps reconciliation visible instead of buried in a project file.
Common questions
How long should a customer data platform migration take?
It depends on how many sources you have and how messy identity is. For a UK mid-market business, planning in batches across eight to twelve weeks is more realistic than a single cutover weekend.
Can we run the legacy system and the new platform at the same time?
Yes, and during migration you probably should. Dual running costs money and adds reconciliation work, so set an end date and name an owner for closing it.
What should we check before switching the legacy system off?
Row counts, consent flags, erasure handling and the list of reports still reading from old tables. If any report has no replacement, the switch-off date is wrong.
Does UK data residency remove the need for transfer checks?
No. Residency covers where data sits, but access from a parent company or a support team outside the UK can still amount to a transfer. Document who can reach the data, not only where it is stored.
