Clean your customer data before you migrate it, not after. The order matters. If you move messy records into a new system, you carry every duplicate, every dead email and every half-filled field across with you, and now they live in a place that is harder to fix. The safe process is: take a snapshot, audit what you have, deduplicate, correct and standardise, trim what you do not need, then do a small test load before the full move. Done in that order, nothing important breaks and nothing gets lost.
This guide is written for the operations lead who has been handed the migration and wants a repeatable method rather than a scramble. It applies whether you are moving from spreadsheets, an old CRM, or a booking tool that has quietly become the system of record.
Start with a snapshot you can roll back to
Before you touch a single record, take a full, dated export of the source data and store it somewhere safe. This is your undo button. If a deduplication merge goes wrong or a bulk edit does something you did not expect, you can compare against the original and recover. Keep it access-controlled and treat it as personal data in its own right, because it is. The NCSC’s GDPR security outcomes are a sensible checklist for how to hold that copy safely during the project.
Write down where the snapshot lives, who can open it, and when you will delete it once the migration is signed off. A backup you forget to remove becomes a liability.
Audit what you actually have
You cannot clean what you have not measured. Walk through the data and score it against a few plain quality dimensions: is it complete, is it accurate, is it consistent, is it unique, is it still valid. The UK government’s data quality dimensions give you a shared vocabulary for exactly this, and they translate cleanly to a customer database.
In practice that means counting the obvious failures. How many records have no email or no phone. How many phone numbers are clearly not phone numbers. How many entries share a name but nothing else. How many were last touched years ago. You are not fixing anything yet. You are building a picture so you know the size of the job and which fields need the most work.
Deduplicate before anything else
Duplicates are the single biggest cause of a migration that feels wrong afterwards. The same customer appears three times, so reminders go out twice, history is split, and nobody trusts the numbers. Deduplicate in the source data while you still have the full context.
Match on more than one field. Email plus surname, or phone plus postcode, catches far more real duplicates than name alone and avoids merging two different people who happen to share a name. When you merge, decide in advance which record wins for each field: usually the most recent verified contact detail, but the earliest created date for the relationship history. Keep the merge log so you can explain any change later.
Under UK GDPR you are expected to keep personal data accurate and, where necessary, up to date, and to take reasonable steps to erase or correct inaccurate data. The ICO’s guidance on the accuracy principle is worth reading before you start merging, because deduplication is accuracy work whether you frame it that way or not.
Correct, standardise and fill the gaps
With duplicates gone, fix the records that remain. Standardise formats so the new system can read them: phone numbers in one shape, postcodes in upper case, county and country fields consistent, dates in one format. Correct obvious errors, and where a field is genuinely unknown, leave it blank rather than guessing. A guessed email is worse than an empty one because it looks trustworthy and is not.
Where a customer has told you their details have changed, this is the moment to act on it. People have a right to rectification under UK GDPR, so migrating a correction you already know about, rather than carrying the old value across, is the right call on both counts.
Trim what you do not need to move
A migration is a rare chance to move less. You are not obliged to carry everything forward, and you should not. The data minimisation principle says you should only hold personal data that is adequate, relevant and limited to what you need. The storage limitation principle adds that you should not keep it longer than necessary.
So decide, per category, what earns its place in the new system. Old enquiries that never converted and have gone cold for years, fields you collected once and never used, marketing contacts who have not opened anything in a very long time. Some of this should be archived, some deleted. Record the decision and the reason, because being able to show why you kept or removed something is part of handling data responsibly. This is also the point to check consent status carries across correctly, which fits neatly with a clear internal policy on how you handle customer data.
Map fields, then run a small test load
Now map old fields to new. This is where migrations quietly lose information: the source has a field the destination does not, so it drops silently. Build a mapping document, list every source field, name its destination, and flag anything with no home so you can decide where it goes rather than losing it.
Then load a small, representative sample into the new system first. Twenty or thirty records covering your awkward cases: a customer with multiple past jobs, one with unusual characters in their name, one with missing fields. Check they land correctly, that history is intact, and that nothing has shifted into the wrong column. Fix the mapping, then run the full load. This test step is the difference between finding a problem in thirty records and finding it in thirty thousand.
Where clean data pays off, and where Kilij fits
The point of all this is one trustworthy record per customer. When each person exists once, with correct contact details and intact history, everything downstream gets easier: reminders reach the right inbox, follow-up does not double up, and moving from spreadsheets to a CRM becomes a clean lift rather than a rescue job. It also makes connecting quotes, bookings and invoices without re-keying possible, because there is a single source of truth for every field to hang off.
Kilij Digital handles data migration for UK service businesses, so if the cleaning and moving is more than your team can take on alongside the day job, that is work we do. Either way, the outcome to aim for is the same: one clean, accurate record per customer, so that on day one in the new system every booking, reminder and follow-up fires against data you can actually trust.