Data Portability Clauses Worth Negotiating Before You Sign

Portability asks are easy to wave through as boilerplate and easy for a vendor to accept in a form that is worthless. The way to make them real is to derive each one from a specific thing your migration will need, so that the clause names an artefact and a format rather than a sentiment.

Start from what the migration consumes

A provider migration consumes four inputs, and every portability guarantee worth having exists to secure one of them. If a proposed clause does not map to one of these, it is decoration.

• An evaluation corpus. Real requests, with their responses, spread across the shapes your system actually sees. This is what you replay against the new provider to establish that quality has not moved. Without it you are comparing a new provider against a memory.
• A cost baseline. Per-request token counts and spend, broken down finely enough to attribute by feature or tenant. Without it, “the new provider is cheaper” is a claim you cannot check. See cost attribution.
• Training and tuning artefacts. The datasets you uploaded, the job configurations, and — where the arrangement allows it — the resulting weights or adapters. These are the items whose replacement cost dominates a migration budget.
• Configuration state. Assistants, hosted prompt objects, stored conversation state, tool definitions, hosted vector stores. Anything that lives in the vendor’s account rather than in your repository is state you will have to reconstruct.

Notice that the first two are almost entirely solvable on your own side. If you log every request with its model, prompt version, token counts and outcome, you own the evaluation corpus and the cost baseline outright and the corresponding contract asks become insurance rather than necessity. The last two are not solvable on your own side, which is why they deserve the negotiating capital.

Format: machine-readable and specified

“The provider will make customer data available for export” is satisfied by a PDF. Ask instead for a named, machine-readable format, and if you can, ask that the export preserve the structure the API produced rather than a flattened reporting view.

The reason structure matters is that the interesting fields are nested. A usage record flattened to total_tokens throws away the split between input and output — which is the split that determines cost, since providers price the two differently — and throws away the cache and reasoning sub-fields that modern usage objects carry. A message export flattened to a single text column throws away the content-block structure, tool calls, and the stop reason, which is exactly the metadata an evaluation replay needs. Line-delimited JSON preserving the original response objects is a reasonable thing to name in a clause; “CSV export” usually is not.

Three format details worth naming explicitly, because each has bitten somebody:

• Encoding and escaping. Prompts contain newlines, quotes and non-Latin scripts. A CSV export without a stated quoting convention is a corruption waiting to happen.
• Identifiers. The export should carry the request id the API returned, so rows can be joined back to your own logs. An export you cannot join to your own telemetry answers half the questions you have.
• Timestamps in UTC with an explicit timezone. Reconciling a vendor’s billing day against your own is impossible if either side is ambiguous about the boundary.

Scope: name the artefacts, not “your data”

The word “data” in a portability clause tends to be read by each side as the thing that side finds convenient. Enumerate. A scope list that names request and response content, usage and billing records, uploaded files, fine-tuning job configurations, evaluation results and any hosted configuration objects is much harder to satisfy narrowly than one that says “customer data”.

Two scope questions are worth asking directly rather than drafting around, because the answer is often a flat no and it is better to know:

• Can fine-tuned weights or adapters leave? For a hosted fine-tune on a proprietary base model the answer is normally no, and it is not a negotiating failure — the base weights are not yours to take. What you can reasonably ask for is the training data and the job configuration back, which is what lets you reproduce the tune elsewhere. Whether you may is a licence question covered in fine-tuning licences.
• Does the scope survive termination? A portability right that only exists while the agreement is in force is close to useless, since the moment you most need it is the moment after you have served notice. Ask for a defined post-termination window during which export remains available, and check it against the deletion clock in the retention clause — an export right that outlives the data is theatre.

Timeline and fee

Two numbers turn a portability clause from an intention into a plan: a maximum time from request to delivery, and a fee, ideally zero for a standard export. Both matter for the same reason — an export that arrives in an unspecified number of weeks, at an unspecified cost, cannot be put on a critical path, so a migration plan has to be built as if it does not exist.

A reasonable shape to ask for is a self-service export available continuously at no charge, with a contractual backstop of a fulfilment window measured in days for anything the self-service path does not cover. Vendors resist unbounded free obligations, so the practical compromise is usually: standard export free, bespoke extraction billed at a rate named in the agreement rather than determined later.

On regulated personal data there may be a statutory right in play as well. The EU General Data Protection Regulation grants data subjects a right to receive their personal data in a structured, commonly used, machine-readable format under Article 20 — the consolidated text is published by EUR-Lex. That right belongs to the individual whose data it is and is not a general commercial export right for your operational logs, so it is a poor substitute for a contractual clause. It is worth knowing about because it sometimes means an export mechanism already exists for other reasons; it is not worth relying on for a migration.

The ask list

Condensed into the form you can paste into a redline conversation. Each line is followed by the migration input it protects, which is the argument to make when it is pushed back on.

1. Named machine-readable format, preserving the API response structure and the request id. Protects: the evaluation corpus and its join to your own logs.
2. Enumerated scope listing content, usage records, uploaded files, job configurations and hosted configuration objects by name. Protects: configuration state you would otherwise rebuild by hand.
3. Usage data at request granularity, with the input and output token split preserved rather than a total. Protects: the cost baseline you will compare against.
4. Return of training data and job configurations for any tuning you paid for, whether or not weights can leave. Protects: the ability to reproduce a tune elsewhere.
5. A post-termination export window that is at least as long as the deletion clock, stated in days. Protects: the whole thing, at the only moment it matters.
6. A stated fee — preferably none — and a delivery deadline. Protects: your ability to put the export on a critical path at all.

One closing observation, because it changes how much of this you need to win. Every ask above is weaker than the equivalent engineering decision. A team that logs its own requests, keeps its prompts in version control rather than in a vendor’s hosted prompt object, and holds its training data in its own storage has already secured three of the four migration inputs without a single redline. Negotiate the clauses — and then build as though you had lost the negotiation.