PIPELINEGuide
Data migration and privacy: what GDPR requires
As soon as personal data is processed in data migration, clear obligations apply. What these are specifically, what's almost always missing in practice, and what actually suffices.
As soon as personal data is processed in data migration, you need a legal basis, purpose limitation, defined retention periods, notification of data subjects, and a data processing agreement with every involved service provider. In practice, almost always the same three things are missing: the retention period, the notice at the collection point, and clarification of whether the provider uses the data for its own training.
01 — Data Protection
What GDPR requires
As soon as personal data is processed — and that happens faster than expected, for instance as soon as someone enters a name or phone number — the usual obligations apply: name the legal basis, define the purpose, maintain data minimization, define retention periods, inform data subjects.
In practical terms, that means for data migration: a data processing agreement with every service provider involved, checking where processing takes place, a documented deletion period, and a clear section in your privacy policy. Three things are almost always missing in practice: the defined deletion period, the notice at the point where data is collected, and clarification of whether the provider uses the data for its own training.
A data protection impact assessment is only required when there's likely high risk — not for most projects of this type. The review itself should still be documented so that if questions arise, it's clear why it was omitted.
02 — Contract
What needs to be clarified in writing
- Ownership of data and access. They belong to the client. If a provider won't clearly confirm this, that's the most important information from the conversation.
- Handover upon termination. In what format, within what timeframe, at what cost.
- No minimum term without consideration. Lock-in is justifiable if something is delivered in return — otherwise not.
- What a later change costs. The total cost isn't determined by the project price, but by the hourly rate in year three.
- Documentation as a deliverable. Not as a promise, but as a line item in the proposal.
03 — Risks
What can go wrong
- The system answers incorrectly. Containable by having it work exclusively from verified content and escalate when uncertain rather than guess. This is a configuration decision, not a property of the technology.
- The effort is underestimated. Most common reason: unclear starting situation. An honest assessment of the current state before the proposal prevents this more reliably than any buffer.
- No one maintains it. The biggest risk of all — and the most easily avoidable.
- Data protection gaps. Almost always arise from missing deletion deadlines and unclear responsibility, rarely from the technology itself.
- Vendor lock-in. Avoidable if access credentials, data, and documentation contractually remain with the client.
04 — Questions
Frequently asked questions
How long does a migration take?
The transfer itself usually hours. The time goes into analysis, rules, and trial runs — typically two to six weeks, depending on the condition of the legacy data.
What if something is missing after the switchover?
That's why count protocol and fallback option: the legacy inventory remains untouched until acceptance is complete. Subsequent additions of individual areas are possible.
Do we take everything?
Rarely makes sense. Dead records, test datasets, and ten-year-old transactions burden the new system. We recommend migrating the active inventory and keeping the rest archived and accessible.
Do we need access to both systems simultaneously for the migration?
Yes, at least for the period of trial runs and the actual switchover. After that, access to the legacy system can be restricted or terminated.
What happens to attachments and documents on the record?
They are transferred along, provided the target system supports them. Where the format doesn't fit, it's clarified beforehand whether conversion is necessary or external storage remains more practical.
How do we ensure nothing gets lost?
Through the count protocol: number of records before and after is compared, samples are checked for content. Only after this acceptance is the migration considered complete.
Can we keep working in parallel?
For short transitions yes, with a cutoff date. For longer migrations, you typically continue working in the legacy system until the switchover and transfer the additions at the end.
05 — Next
Related pages
Next step
Send us a few sentences about your project.
We read every inquiry ourselves and respond personally. No sales team, no callback form into the void.