GDPR Email Migration: Article 28, DPIAs, and Data Residency

GDPR did not invent the discipline of moving personal data carefully. It did make the consequences of moving it carelessly far more expensive. Every mailbox you migrate contains personal data about employees, customers, suppliers, and incidental third parties. Most contain at least some special-category data: health, ethnicity, trade-union membership, political opinion. A migration is not exempt from any of the Articles you would apply to any other processing. This guide is the working playbook for getting it right.

The Articles that actually fire#

GDPR has 99 Articles. A migration project touches a handful of them in practice. Knowing which ones, and what each one demands, lets you build a defensible project file without rewriting your DPO's library.

Article 5 sets the principles: lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, integrity and confidentiality, accountability. A migration must respect all seven. The principle most often violated is storage limitation — migrations are the moment when ten-year-old mail gets copied forward without anyone asking whether it should be.

Article 6 demands a lawful basis for processing. The migration does not need a new lawful basis if you are continuing existing processing on a new system. You are not collecting fresh data; you are moving processing infrastructure.

Article 28 demands a written contract with every processor. Your destination platform is a processor. Your migration vendor, if you use one that touches the data, is a processor. Both contracts need to be in place before any mail moves.

Article 30 demands a record of processing activities (ROPA). The migration is a processing activity. Add it to the ROPA, even if temporarily.

Article 32 demands appropriate security. Encryption in transit, access controls, audit logging, and tested incident response all live here.

Article 33 demands breach notification within 72 hours of becoming aware. Your migration runbook needs a clear escalation path that meets that clock.

Article 35 demands a DPIA where processing is likely to result in a high risk to data subjects. A large-scale migration of personal data almost always qualifies.

The rest of the framework is mostly a question of how you apply these.

Picking the lawful basis#

A common mistake: writing a consent notice to all employees and customers asking them to agree to "the migration of their data to our new email platform." This is wrong in three ways. First, the data subject did not consent to your original choice of platform either, so they cannot meaningfully refuse the new one. Second, consent under GDPR is freely given, which it would not be in an employment context. Third, you do not need it.

The lawful basis that fits an internal mail migration is almost always legitimate interests (Article 6(1)(f)) or contractual necessity (Article 6(1)(b)). You are continuing the same processing under the same legal basis, on different infrastructure.

For a customer-facing mailbox (sales@, support@, info@), the customer's data is processed under the basis you already documented when you first opened that mailbox. The migration is incidental to the original purpose.

Where consent does enter the picture is for marketing data and certain cookies-and-tracking categories that you should not be storing in email anyway. If you are, the migration is the moment to clean them out.

Article 28 contracts for migration vendors#

Article 28(3) sets out what a processor contract must contain: subject matter, duration, nature and purpose, type of personal data, categories of data subject, your obligations and rights as controller, and the processor's obligations. Most reputable migration vendors offer an Article 28-compliant Data Processing Addendum (DPA) on request.

The DPA must, at minimum:

• Bind the processor to act only on documented instructions.
• Require staff confidentiality.
• Mandate appropriate technical and organisational measures (Article 32 measures).
• Authorise (or not) the use of sub-processors and require notice of changes.
• Require the processor to assist with data-subject rights requests.
• Require breach notification to you without undue delay.
• Provide for deletion or return of data at the end of the engagement.
• Allow audits.

Read the DPA against the contract. Some migration vendors quietly carve out their sub-processor list, their breach-notification clock, or their audit rights in the master services agreement. The DPA is not enough on its own if the MSA undoes it.

When the vendor is in a third country#

If your migration vendor is established outside the EEA, the Article 44 transfer rules apply. The standard route is the EU Standard Contractual Clauses (SCCs), supplemented by a transfer impact assessment (TIA) where the destination country is one where surveillance laws may compromise the SCCs.

For US-based vendors, the EU-U.S. Data Privacy Framework is currently the cleanest route if the vendor self-certifies. If they do not, you fall back to SCCs plus a TIA. The TIA work is non-trivial and is the single most common reason migration projects slip in EU contexts.

Avoid the problem entirely by picking a vendor with EU establishment, or by running the migration on a desktop tool that does not move data to a third-country vendor cloud in the first place.

EU data residency on the destination#

GDPR does not strictly require data to stay in the EU. It does require that any transfer outside the EEA meets one of the Chapter V mechanisms. In practice, large controllers prefer to keep primary data in EU regions to avoid the transfer analysis entirely.

Microsoft offers the EU Data Boundary for Microsoft 365 commercial plans. This commits Microsoft to processing customer data within the EU and EFTA for in-scope services, with documented exceptions. The boundary covers Exchange Online, SharePoint, OneDrive, Teams, and Purview. The exceptions are narrow but real — automated abuse detection, some support traffic, and a small number of feature backends.

Google Workspace offers a data-region policy on Business Plus, Enterprise Standard, Enterprise Plus, and Education Standard or Plus. The policy lets you pin primary data for covered services to Europe or the United States. Covered services include Gmail, Drive, Docs, Sheets, Slides, Sites, Calendar, Keep, and Vault.

Pick the destination region as part of the design, not as an afterthought. Walk through the data-residency migration guide for the cross-provider view.

DPIA for a migration project#

A DPIA does not need to be long. It needs to cover the high-risk elements of the processing, the necessity of the processing, the risks to data subjects, and the safeguards.

A workable DPIA structure for a migration project:

• Description: what you are migrating, from where, to where, over what timeframe, using which tools and vendors.
• Necessity and proportionality: why the migration is needed, what alternatives were considered, why you are moving the data you are moving.
• Risks: confidentiality breach during transit, data loss, unauthorised access, retention drift, third-country transfer.
• Safeguards: encryption in transit, MFA on admin accounts, audit logging, vendor due diligence, post-migration validation, breach plan.
• Residual risk: what is left after safeguards.
• Consultation: with the DPO, with affected business units, with the supervisory authority if residual risk is high.

The compliance migration guide covers the framework view of DPIAs in more depth. The migration-specific cut here is to scope the DPIA to the project rather than to a steady-state processing activity.

Right-to-erasure during the migration window#

The data subject's rights do not pause because you are migrating. If a deletion request lands during the window, you must honour it.

The cleanest pattern:

• Maintain a flag list of mailboxes or message-IDs subject to an active erasure request.
• Before the migration batch runs, action the erasure on the source.
• Confirm with a delta sweep that the deleted items do not propagate to the destination.
• Document the action in the audit log.

A common failure mode is that the source action and the migration batch run in parallel, the migration copies the message moments before it is deleted on the source, and the message lives on in the destination. Build the runbook so that erasure actions are processed and confirmed before the migration touches the affected mailbox.

The same pattern applies, with adaptation, to rectification requests under Article 16 and to access requests under Article 15.

Pseudonymisation is not an excuse#

You cannot pseudonymise your way out of an erasure obligation by replacing the message body with hashes during the migration. The personal data is still the personal data. If the data subject is identifiable from any field — sender, recipient, subject line, metadata — it is in scope.

Breach notification during the project#

Article 33's 72-hour clock starts when you become aware of a breach. A migration is a period of elevated risk because credentials are in motion, integrations are being re-authorised, and unfamiliar tools are running.

Build the breach-response shape before the project starts:

• A named on-call for the migration team during the cut-over window.
• A documented escalation path to the DPO.
• A pre-drafted notification template ready for the supervisory authority.
• A pre-drafted communication template for affected data subjects.
• A list of subjects to notify if a high-risk breach occurs (think on this in advance).

Most migration projects do not result in a notifiable breach. The ones that do almost always run into the 72-hour clock because nobody decided in advance who has the pen on the notification.

Auditing the migration#

Article 28(3)(h) entitles you to audit your processors. Article 24 and Article 30 entitle you to evidence your own controls. Both interests are served by a comprehensive migration audit log.

The audit log shape is the same as for any compliance framework: per-mailbox operator, source, destination, message counts, timestamps, errors. The audit log article covers the schema in depth. For GDPR specifically, ensure the log:

• Is retained for the lifetime of the related ROPA entry.
• Is itself secured as personal data (mailbox addresses are personal data).
• Is accessible to the DPO without engineering involvement.
• Can be produced for a supervisory authority on request.

A common shortcut is to store the audit log in a shared spreadsheet without access controls. That is itself a controller obligation failure. Treat the log with the same care as the source data.

Cross-framework alignment#

GDPR controls overlap heavily with SOC 2, HIPAA, and other frameworks you may already operate under. Aligning them saves substantial work.

If you operate under SOC 2, the SOC 2 email migration guide covers the evidence collection that also satisfies most Article 32 obligations. If you handle health-related data in the EU, the HIPAA migration guide covers the controls that overlap with GDPR special-category handling. The compliance pillar guide maps frameworks against each other.

The principle to keep in mind: a control implemented once should satisfy the most demanding framework you operate under. Engineering the same control three times once per framework is wasted effort.

When the data subject is also the employee#

Employee mailboxes deserve their own paragraph. The data subjects whose data is most touched by a corporate email migration are the employees themselves. They have the right to information about the processing, the right of access, and in some cases the right to object.

The fair approach is a short, factual notice to staff:

• We are migrating email from platform A to platform B between dates X and Y.
• The purpose is operational and the lawful basis is legitimate interests (or contractual necessity).
• The data categories are those already held in your work mailbox.
• The processors involved are platform B and (if applicable) the migration vendor.
• Your existing rights under GDPR apply unchanged.
• Contact the DPO with questions.

Most employees will not engage with the notice. The ones who do are the ones with sensitive correspondence in their mailboxes, and they deserve the answer.

After the migration#

The post-migration housekeeping that GDPR cares about:

• Update the ROPA to reflect the new processor relationship.
• Update the data subject privacy notice if the controller-of-record or the international transfer surface changed.
• Confirm retention policies are firing as documented on the destination.
• Confirm the source data is deleted or archived per Article 5(1)(e).
• Confirm the migration vendor has deleted or returned any working copies they held.
• File the audit log.
• Close the DPIA with a residual-risk note.

The last item is the one most often skipped. A DPIA that is never closed is a DPIA that nobody trusts.

FAQ#