UK GDPR and Data Migration: Moving Customer Data Safely to a New System

A GDPR data migration is any move of personal information, about customers, staff, tenants or suppliers, from one system to another, and UK data protection law applies at every step of it. Whether you are leaving a spreadsheet for a CRM, replacing an ageing desktop database or switching software providers, the exports, the clean-up and the old system you leave behind all count as processing personal data.

The good news is that the rules ask for nothing exotic. Most of what UK GDPR expects during a data migration is simply good practice: know what you hold, move only what you need, keep it accurate, keep it secure and be able to put things right if something goes wrong. This guide walks through each stage: what to do, and where projects tend to slip.

This article is about systems rather than legal advice. If you are unsure how the rules apply to your organisation, check the ICO’s guidance or speak to a data protection specialist.

Why a data migration is a data protection event

UK GDPR defines processing very widely. Extracting records from an old system, copying them to a laptop, reformatting them, merging duplicates, loading them into new software and deleting what is left over all count. That means the data protection principles apply throughout the project, not just once the new system is live.

Four of the seven principles do most of the work during a data migration:

• Data minimisation: personal data should be adequate, relevant and limited to what you need.
• Storage limitation: do not keep it in a form that identifies people for longer than necessary.
• Accuracy: take reasonable steps to keep it correct and, where necessary, up to date.
• Integrity and confidentiality: protect it with appropriate security, including against accidental loss or damage.

The accountability principle sits over all of them: you need to be able to show what you did and why. In practice, that means a short written plan and a record of your decisions. Breaching the principles falls into the higher tier of UK GDPR fines, up to £17.5 million or 4% of worldwide turnover, whichever is higher. For most small businesses, though, the realistic risks are a lost customer list, an embarrassing disclosure or a complaint you cannot answer.

Our data structure and migration service is built around these principles, but the steps below apply whoever does the technical work.

Step 1: map the personal data you hold

Before any data migration starts, list every place personal data lives and what it is used for. Most small businesses are surprised by how long the list gets:

• the main system being replaced, including fields nobody has used for years;
• spreadsheets that have grown up alongside it, often with copies on individual laptops;
• email inboxes and shared folders holding forms, ID documents and contracts;
• old exports made for mailings or reports that were never deleted.

For each source, note what kinds of personal data it holds and whether any of it is special category data, such as health information, which needs extra care. Note who can access it today and who in the business is responsible for it. Our data migration checklist covers the wider planning, from estimating volumes to choosing a quiet weekend for the cut-over.

Step 2: decide what not to move

A data migration is the best chance you will get to stop carrying information you no longer need. Data minimisation and storage limitation point the same way: if there is no good reason to keep something, it should not arrive in the new system.

Work through your map and sort everything into four groups:

1. Move: current customers, live jobs, open balances and anything staff use day to day.
2. Archive: records you must keep but rarely use, such as financial records kept for tax purposes. These can sit in a secure, read-only archive rather than cluttering the new system.
3. Delete: old enquiries that never became customers, former staff records past their retention period, duplicate exports and test data.
4. Ask: anything where nobody is sure. Give each item an owner and a deadline, or the “ask” pile quietly turns into the “move” pile.

If you do not have a retention schedule, write a simple one now: each type of record, how long you keep it and why. The reason might be a legal requirement, such as HMRC’s record-keeping rules, or a business need you can explain in a sentence. An answer like “we keep everything forever” is hard to defend under UK GDPR.

Step 3: fix accuracy problems before the data migration

The accuracy principle asks you to take reasonable steps to make sure personal data is not incorrect or misleading, and to correct or erase it when you find it is wrong. The ICO’s guidance on the accuracy principle makes some helpful practical points too: be clear about where data came from, historical records are fine as long as they are clearly marked as historical, and you can generally rely on people to tell you when their details change.

A data migration brings accuracy problems to the surface that have been hiding for years, so plan for them rather than discovering them at go-live. Common ones include:

• the same customer recorded two or three times with slightly different spellings, each record holding part of their history;
• marketing preferences attached to one duplicate and not the others;
• old addresses and phone numbers mixed in with current ones, with no indication of which is which.

Merging duplicates is where the risk is highest. Merge two different people by mistake and you may show one customer’s details to another, or send someone’s letters to the wrong address. Agree matching rules in advance, check a sample of proposed merges by hand and keep a log of what was merged so that it can be undone. And if someone has asked you to stop sending them marketing, make sure that request survives the move, whichever duplicate it was recorded on.

Step 4: keep data secure while it is in transit

The riskiest moment in most data migration projects is not the old system or the new one, but the space in between. Data is exported into files, copied between machines, opened in spreadsheets for cleaning and handed to whoever is running the import. Every copy is another thing to protect and, eventually, to delete.

The ICO’s guide to data security explains that UK GDPR requires appropriate technical and organisational measures covering confidentiality, integrity and availability, and that you should test those measures regularly. It recommends encryption when personal data is stored or sent, and points to the government-backed Cyber Essentials scheme as a good starting point. For a GDPR data migration, that translates into a few concrete rules:

• Use secure transfer, not email attachments. Move exports through an encrypted transfer or a shared location with restricted access.
• Keep working copies in one place. Agree where extracts and cleaning files will live, who can open them and on which devices. Avoid USB sticks and personal laptops.
• Limit access to the people doing the work, and remove that access when the project ends.
• Use dummy data for early testing where you can. A test environment full of real customer records needs the same protection as the live system.
• Delete working copies at the end, and make a note that you have done so.

Step 5: check the new system and the supplier behind it

Most small businesses now move into cloud software, which means another organisation will process personal data on your behalf. UK GDPR calls that organisation a processor, and you need a written contract with it that requires, among other things, appropriate security. Mainstream providers usually include this in their terms as a data processing agreement, but read it rather than assuming. The same applies to any developer or consultant who handles your data during the data migration.

Questions worth asking about the new system:

• Where will the data be stored and accessed from? If it leaves the UK, how does the supplier cover international transfers?
• Can you control who sees what, with separate user roles and two-step verification?
• Does it keep an audit log of who changed or exported records?
• Can you export everything in a usable format if you leave?
• Can you find, correct and delete one person’s data easily, so that requests from customers can be answered?

If the change is significant, for example moving health information into a new platform or combining data sets in new ways, consider a data protection impact assessment. UK GDPR requires one where processing is likely to result in a high risk to individuals. Many routine moves will not need one, but a short written note of the risks you considered, and why you reached that view, is still part of being accountable.

Step 6: back up first and plan for things going wrong

Under UK GDPR, losing personal data is a security failure in its own right. A personal data breach is not only a leak to the wrong person: the definition also covers accidental loss, destruction or alteration. Deleting a batch of customer records during an import, with no way of getting them back, counts.

Before the final run of the data migration, take a full backup of the old system and check that you can actually restore it. The NCSC’s guidance for small organisations on backing up your data makes the same points in plain language: work out what you need, keep backups separate from the computers they protect, and make sure you know how to restore them. Our article on backups, disaster recovery and the 3-2-1 rule goes into more detail.

Then write a short rollback plan for the data migration: what would make you abandon the cut-over, who makes that call and how you would return to the old system. Keep the old system available in read-only form rather than switching it off on day one.

If something does go wrong, the clock matters. Unless a breach is unlikely to result in a risk to people’s rights and freedoms, you must report it to the ICO without undue delay and, where feasible, within 72 hours of becoming aware of it. If the risk to individuals is high, you must tell them too. Keep an internal record of every breach, including those you decide not to report. The ICO’s guide to personal data breaches explains how to make that judgement.

Step 7: finish the data migration properly after go-live

The project is not over when the new system goes live. A few loose ends carry real data protection weight:

• Check the result. Compare record counts, sample individual records field by field and ask the people who use the data every day to look for anything odd.
• Update your privacy information if the change affects what you tell people, for example a new processor or data now held outside the UK. Our guide to UK GDPR and cookie consent for business websites covers privacy notices in more detail.
• Test that rights requests still work. Try finding everything held about one person in the new system. You usually have one month to respond to a subject access request, so this is not something to work out under pressure.
• Make sure complaints still reach the right person. Since 19 June 2026, organisations have had to provide a way to make data protection complaints and acknowledge them within 30 days. If inboxes or forms are moving, check nothing falls through the gap.
• Decommission the old system securely. Once nothing more is needed from it, delete or securely wipe the data, including working copies made for the move, in line with your retention schedule.

An illustrative example: a lettings agency changes systems

To make this concrete, here is an illustrative example. The business is made up, but the situation is typical of the data migration projects small firms ask us about.

A small lettings agency has run on a desktop database for twelve years, with spreadsheets for maintenance jobs and a shared inbox full of tenancy documents. It is moving to a cloud property management system. The database holds current landlords and tenants, but also former tenants, applicants who never signed and a long tail of one-off enquiries. Working through the steps above, the agency:

• maps its data and finds copies of tenant reference checks in three places, including a shared folder every member of staff can open;
• agrees a retention schedule with its accountant, archives former tenancy records it must keep and deletes years-old applicant records;
• merges duplicate landlord records using agreed rules, with a manager checking every proposed merge that involves bank details;
• reads the supplier’s data processing terms, confirms where data is hosted and turns on two-step verification for every user;
• takes and test-restores a full backup, runs a trial data migration and keeps the old database read-only for three months before wiping it.

The new system starts life with far fewer records than the old one, which makes it quicker to search, easier to secure and much easier to justify if anyone asks why the agency holds their details.

If someone else is doing the technical work for you, ask them where copies of your data will be held during the project, how merges can be reversed, how they will prove everything arrived and what the rollback plan is. Good suppliers will have answers ready, because the same practices make any data migration more reliable. When we worked alongside JEENI’s project manager, designers and back-end developers on their new entertainment-on-demand platform for creatives, part of the job was migrating their data from the old system into the new one. You can read more in our JEENI.com case study.

GDPR data migration: common questions

Do we need fresh consent for a data migration?

Not usually. Moving data into a new system so that you can keep doing the same things with it does not normally need fresh consent, because your reasons for using the data have not changed. If you plan to use it for something new, such as marketing to people who were previously only customers, that is a separate question to look at carefully.

Is it a breach if records are lost during a data migration?

It can be. Accidental loss or destruction of personal data counts as a personal data breach, not only unauthorised access. If you can restore the data quickly from a backup, the risk to individuals may be low, but you should still record what happened and consider whether it needs reporting.

Should we keep the old system after a data migration?

For a short, defined period, yes. A read-only copy lets staff check anything that looks wrong in the new system. Set an end date, though. Keeping a full second copy of everyone’s data indefinitely works against storage limitation and doubles what you need to secure.

The bottom line

A GDPR data migration does not need to be complicated. Know what you hold, leave behind what you no longer need, fix accuracy problems before they move, protect every copy along the way and make sure you can undo the move if something goes wrong. The same habits leave you with a cleaner, more useful system from the first day.

If you are planning to move customer data and would like a careful pair of hands, tell us about your systems or call us on 01482 212499. We will tell you honestly how much work your data needs before it moves, and what you could safely leave behind.