GDPR-Compliant Data Migration: What UK Businesses Must Know in 2025

The GDPR Risk Most Businesses Miss During Data Migration

When UK businesses plan a data migration — whether switching CRM, upgrading ERP, or consolidating databases — they focus almost exclusively on technical delivery: field mapping, record counts, testing windows. GDPR compliance is an afterthought, if it's considered at all.

This is a serious mistake. A data migration is a data processing activity under UK GDPR. Moving, transforming, and loading personal data between systems must be lawfully based, properly documented, and executed with appropriate safeguards. Get it wrong and you're looking at ICO investigation, potential fines, and reputational damage.

This guide covers everything UK businesses need to know in 2025 about running a GDPR data migration service engagement the right way.

What Makes a Data Migration a GDPR Event?

Under Article 4 of the UK GDPR, "processing" means any operation performed on personal data — including collection, organisation, storage, retrieval, use, disclosure, erasure, or destruction. A data migration touches most of these.

Specifically, a migration involves:

• Extraction: reading personal data from the source system
• Transformation: restructuring, normalising, or enriching data
• Loading: writing personal data into the destination system
• Deletion (if decommissioning the source): destroying data in the old system

Each of these is a processing activity requiring a lawful basis and appropriate safeguards.

Step 1: Establish Your Lawful Basis

UK GDPR Article 6 provides six lawful bases for processing. For a CRM or ERP data migration, the most applicable are:

Legitimate Interests (Article 6(1)(f))

For most B2B data (contacts, companies, opportunities, transaction records), legitimate interests is the appropriate basis. You have a genuine business need to migrate operational data to continue processing it in a new system.

You must document this in a Legitimate Interests Assessment (LIA): what is the interest, is it necessary, and does it override data subjects' rights and interests?

Contract (Article 6(1)(b))

Where the migration involves data held under a contractual obligation — customer orders, invoices, service records — contract may be a more appropriate basis. The key test: is the migration necessary for performance of the contract?

Compliance Obligation (Article 6(1)(c))

If you're migrating data to comply with a legal obligation (e.g., tax record retention), this basis applies to those records.

Critical point: you need a separate lawful basis for special category data (health information, political opinions, biometric data) under Article 9. If your dataset includes any special category data, engage a data protection specialist before proceeding.

Step 2: Issue a Data Processing Agreement (DPA)

If you engage a GDPR data migration service provider — an external company to execute the migration on your behalf — they are a data processor under Article 28. You must have a signed DPA in place before any personal data is transferred to them.

Your DPA must contain:

• The subject matter, duration, nature, and purpose of the processing
• The type of personal data and categories of data subjects
• Your obligations and rights as controller
• The processor's obligations: confidentiality, security, sub-processor rules, deletion/return of data, audit rights

A DPA isn't optional or a formality — it's a hard legal requirement. Any GDPR data migration service provider who doesn't proactively issue a DPA before starting work is a red flag.

At 2-IC DATA SYSTEMS, every engagement begins with a signed DPA. No data moves until documentation is in order.

Step 3: Update Your Record of Processing Activities (ROPA)

Article 30 requires organisations with 250+ employees (and smaller organisations carrying out systematic processing) to maintain a ROPA. Every processing activity must be documented.

A data migration event should be recorded in your ROPA as:

• A new or updated processing activity entry for the destination system
• A time-limited processing entry for the migration operation itself
• A deletion record if the source system is being decommissioned

This matters for ICO enforcement. If the ICO investigates a breach and finds your ROPA is out of date — missing an entire system that holds personal data — your accountability posture collapses.

Step 4: Conduct a Data Protection Impact Assessment (DPIA) if Required

Article 35 requires a DPIA where processing is "likely to result in a high risk to the rights and freedoms of natural persons." Migrations that trigger DPIA requirements include:

• Large-scale processing of personal data (the ICO considers 100k+ records significant)
• Processing of special category data
• Migrations involving systematic profiling or automated decision-making
• Cross-border transfers (including EU to UK, and UK to non-adequate third countries)

A DPIA isn't just a compliance checkbox — done properly, it's a useful risk assessment that identifies vulnerabilities in your migration plan before they become incidents.

Step 5: Handle Cross-Border Transfers

Post-Brexit, the UK and EU are separate jurisdictions for data transfer purposes. The UK has granted an adequacy decision to the EU (and several other countries), meaning UK→EU transfers proceed freely. But EU→UK transfers require the EU controller to have a valid transfer mechanism in place.

Common scenarios for a GDPR data migration service engagement:

UK controller, EU data subjects: UK GDPR applies. If using an EU-based processor, ensure the processor relationship is documented and that sub-processing agreements cover any onward transfers.

EU controller, UK processor: UK adequacy applies — but you should document this in your ROPA and review it annually (adequacy decisions can be revoked).

Cloud infrastructure: If your destination system stores data in US data centres, check whether the vendor has appropriate safeguards — typically Standard Contractual Clauses (SCCs) or an equivalent mechanism.

Step 6: Implement Technical Safeguards During Migration

Article 25 (Data Protection by Design and by Default) and Article 32 (Security of Processing) require appropriate technical measures throughout the migration:

Encryption in Transit and at Rest

All data transfers between systems should use TLS 1.2 or higher. Staging/transformation environments should use encrypted storage. Avoid emailing data files, even temporarily.

Access Controls

Migration access should be strictly scoped. Only the engineers who need to read the source data should have access — not the entire development team, not external stakeholders. Log all access.

Data Minimisation

Don't migrate data you don't need. This isn't just a GDPR obligation — it reduces migration complexity, reduces risk, and keeps your destination system clean.

Audit Trail

Maintain a log of every data movement: extraction timestamp, transformation operations applied, load confirmation, and any errors or anomalies. This is your evidence of compliance if challenged.

Step 7: Handle Data Subject Rights During Migration

Data subjects have rights under UK GDPR that don't pause for your migration project:

• Right to erasure: if a data subject requests deletion during your migration window, you must process it in both the source and destination system
• Right of access: DSAR responses must be accurate — if you're mid-migration, ensure your response covers both systems
• Right to rectification: corrections made in the source after extraction must be replicated at migration or post-go-live

Document your DSAR process for the migration window. Most good GDPR data migration service providers will include this in their project plan.

Post-Migration: Source System Decommission

When the migration is complete and the destination system is verified, the source system should be formally decommissioned — with documented deletion of personal data.

Under the UK GDPR, you can't simply "turn off" a system that holds personal data. You must:

1. 1.Export any data required for legal retention
2. 2.Delete all personal data from the system
3. 3.Document the deletion (date, method, confirmation)
4. 4.Update your ROPA

For cloud-hosted source systems, request a formal deletion certificate from the provider.

Summary: Your GDPR Data Migration Checklist

• [ ] Lawful basis identified and documented for each data category
• [ ] Data Processing Agreement signed with migration service provider
• [ ] ROPA updated to reflect migration activity
• [ ] DPIA completed (if high-risk)
• [ ] Cross-border transfer mechanisms verified
• [ ] Technical safeguards implemented (encryption, access control, audit trail)
• [ ] DSAR process documented for migration window
• [ ] Source system decommission plan in place

Running a compliant GDPR data migration service engagement isn't optional — but with the right provider and the right process, it doesn't have to be painful either.

Get in touch to discuss your migration requirements. Every 2-IC engagement ships with full GDPR documentation, a signed DPA, and an Article 30 record you can hand to your DPO.