What Changes About Data Processing Agreements During a Migration

The reason a data processing agreement belongs on the migration plan rather than beside it is that two of its clauses have dates in them, and those dates can be longer than the engineering work.

Who is the processor of what

Under the GDPR, a controller decides why and how personal data is processed, and a processor processes it on the controller’s instructions. Article 28 requires a contract between them and sets out what it must contain — subject matter, duration, nature and purpose, types of data, categories of data subject, and a specific list of processor obligations. The text is published by the EU at EUR-Lex, and reading Article 28 once is a better use of an hour than any summary of it.

In an ordinary application the chain is: your customer is the controller, you are the processor, and the inference provider is your sub-processor. That third position is the one that matters for a migration, because a sub-processor is somebody you engaged and somebody your customer has rights about. It is also why “we changed vendors” is not an internal decision the way changing a hosting region within an existing vendor might be.

Why the old DPA does not move

The agreement with the outgoing provider bound that provider. Nothing in it constrains the incoming one, and the new agreement will not be identical — so the practical work is a difference, not a signature. Compare the two on the clauses that actually vary between vendors:

• The processing description. Categories of data, purposes and duration. If the migration coincides with a change in what you send — adding retrieval context, adding file uploads, adding a new modality — the description you inherited is already wrong and needs rewriting rather than copying.
• Security measures. Article 28 requires them; what is listed varies. Compare the specifics rather than the presence of a section: encryption in transit and at rest, key management, access control, personnel screening, incident detection.
• Breach notification. The clause that binds a processor to notify you without undue delay, and how quickly in practice. A longer window at the new provider directly shortens the time you have to meet your own downstream obligation, which is a real change to your risk position even though nothing in your system changed.
• Audit and information rights. Whether you may audit, or whether the provider satisfies the obligation by furnishing a third-party report. The latter is normal at scale; confirm the report covers the service and region you are buying.
• Assistance obligations. Whether and how the processor helps with data-subject requests and impact assessments. For an inference provider this is thinner than for a storage vendor, and it is worth knowing before somebody exercises a right.

Sub-processor notice is a schedule dependency

This is the clause that surprises engineering teams. Your own DPA with your customers almost certainly contains a sub-processor change provision: you notify customers before adding a new sub-processor, they have a window to object, and the window is often fourteen or thirty days. Adding an inference provider is adding a sub-processor.

The consequence is arithmetic. If your notice period is thirty days, the earliest the new provider can receive customer data is thirty days after the notice goes out — which means the notice must be drafted and sent while the engineering work is still in progress, not when it finishes. A migration plan that discovers this in the final week loses a month, and there is no engineering shortcut around it.

Two details worth checking early: whether the notice must be individual or whether a maintained list page with subscription is sufficient, and what happens if a customer objects. An objection right that is really a termination right changes the commercial calculation of the migration, and it is better known at the decision than at the cutover.

Note the interaction with dual-running. Sending a copy of production traffic to the candidate provider for shadow evaluation is processing by that provider, and the notice obligation attaches to it just as it does to the cutover. If the notice period has not elapsed, shadow traffic must be synthetic or fully de-identified — which is a real constraint on how you validate, and one that argues for building the redacted fixture set the load test needs anyway.

Transfers and the mechanism behind them

Where personal data moves outside the jurisdiction it is protected in, the transfer needs a lawful basis of its own. Under the GDPR that is Chapter V — an adequacy decision, standard contractual clauses, or one of the narrower derogations. Which mechanism applies depends on where the receiving entity is and what it is certified under, and adequacy determinations are exactly the kind of thing that changes on a court judgment rather than on a product roadmap.

For a migration the questions are concrete: which entity is contracting with you, where is it established, which mechanism is being relied on, and is a transfer impact assessment expected of you. If the answer involves standard contractual clauses, they are usually attached to the DPA as a module — check that the module selected matches the actual relationship, because a controller-to-processor module and a processor-to-sub-processor module are different documents and the wrong one is a defect that surfaces at the worst time.

This overlaps heavily with the residency audit and should be resolved with the same conversation. Residency answers where the data is; the transfer mechanism answers whether it is allowed to be there.

Deletion, return and what exit actually costs

The clause you use last is the one you should read first. A processor agreement normally requires the processor to delete or return personal data at the end of the service, at the controller’s election. The things to establish, in this order:

1. What form the return takes. For an inference provider there is often little to return beyond stored files, fine-tuning datasets and batch artefacts — but if you have uploaded training data or built fine-tuned models, ask specifically whether the tuned weights are exportable. Frequently they are not, and that single fact can make a fine-tuned model an anchor holding you to a provider regardless of the rest of the migration.
2. How long deletion takes. Backups have their own cycle, so “deleted” usually means deleted from live systems with backup expiry following on a stated schedule. Get that schedule in writing.
3. What evidence you receive. A certificate of deletion, or nothing. If your own customers can ask you to evidence it, you need the former, and asking for it after termination is markedly harder than agreeing it before.
4. What is exempt. Data retained under a legal obligation, and anything already absorbed into aggregated or derived form. This is where the training-use question from the terms reading becomes concrete: content used to improve a model before you left cannot be extracted from that model afterwards, so a training permission is functionally irreversible in a way a retention period is not.
5. Notice to terminate. If the outgoing contract has a notice period or a minimum commitment, the migration date and the date you stop paying are different dates. Plan to run both providers through the overlap and budget for it rather than discovering it.