What a Data Retention Clause Means for a Future Migration

A retention clause tells you how long a vendor keeps your data. It does not tell you whether you can get that data out, in what shape, or before the deletion clock runs down. Those are separate promises, and a migration is where the gap between them becomes expensive.

Retention and export are two different promises

The clause most agreements contain says something in the shape of “the provider retains request and response content for a defined period for abuse monitoring, after which it is deleted”. Read from the security side, that is a ceiling: the shorter the window, the less of your data sits on somebody else’s disk. Read from the migration side, the same sentence is a floor you may be relying on without realising, because the only copy of some of your operational history may be the vendor’s.

The distinction to hold on to is that a retention clause governs the provider’s obligation to delete. An export or portability clause governs your right to receive. A contract can perfectly consistently say that content is retained for thirty days and say nothing whatsoever about your ability to download it, and many do — retention is a privacy commitment, drafted by people thinking about breach exposure, not by people thinking about your exit. If your migration plan assumes “they keep it for N days, so we can pull it during those N days”, the plan is resting on an inference the contract does not make.

The second-order version of this catches teams more often. Even where an export path exists, it is usually a product feature — a dashboard download, a list endpoint — rather than a contractual entitlement. Product features can be rate-limited, paginated in a way that makes a year of history impractical to walk, or scoped to the last N days regardless of what the retention clause permits. The contract is what survives a product change; that is the whole reason to read it.

The three clocks in a retention clause

Most retention language contains three distinct periods, and a migration timeline collides with all three. Find them separately in your agreement, because they are frequently in different sections and are frequently different lengths.

• The in-life retention window. How long content is kept while the account is active and in good standing. This is the number people quote when asked “what is your retention policy”. It governs how far back your usable history goes at any moment during normal operation.
• The post-termination window. How long data survives after the agreement ends. This is the one that matters at exit and the one most often left vague or absent. A clause that promises deletion “promptly” or “within a commercially reasonable period” after termination is not a window you can plan a data pull against.
• The backup and legal-hold tail. Nearly every deletion clause carves out backups, archival systems and data the provider must keep to meet its own legal obligations. This tail is why “deleted” rarely means “gone from every system today”, and it is also why you cannot treat a vendor’s backups as your backups: you have no access path to a carve-out.

The failure mode that follows is specific. A team gives notice, the post-termination window starts, and the export they planned turns out to need engineering work — a script against a list endpoint, a re-shaping of nested JSON, a reconciliation against internal request ids. That engineering work is now racing a deletion clock that started the day notice was served, on a team that is simultaneously running the migration. Pull your history before you serve notice, not after.

The data categories that behave differently

“Your data” is not one thing, and retention clauses often treat the categories differently in the same document. Enumerate them for your own account rather than assuming one policy covers all of it.

Request and response content

The prompts you sent and the completions you got back. This is the category retention clauses are usually written about, and it is the one you most want at exit, because it is the raw material for every evaluation you will need to prove the new provider is as good as the old one. If you keep your own request log — and you should — this category stops being a contractual problem entirely. See what to log for the fields worth keeping locally.

Derived artefacts you paid to create

Fine-tuned model weights or adapters, uploaded training files, batch job outputs, vector indexes hosted by the vendor. These behave differently from content because they are usually treated as service-generated artefacts rather than as your data. The question that decides your exposure is not “how long do you keep it” but “can I download the artefact itself, or only use it through your API”. For hosted fine-tunes the honest default assumption is that you cannot take the weights, which means the migration cost of a fine-tune is the cost of producing it again somewhere else — and the licence on the base model may constrain even that.

Metadata and telemetry

Usage records, per-request token counts, latency, error rates, billing line items. Retention on this category is often much longer than on content, because the provider needs it for its own billing and reporting. It is also the category you most need for the cost comparison in a migration cost estimate, and the easiest to lose access to, because it typically lives behind a console rather than an API.

Zero data retention cuts both ways

A zero-data-retention arrangement — where the provider commits to discarding content immediately after serving the response rather than storing it for an abuse-monitoring window — is a strong privacy posture and a common requirement in regulated procurement. It is also, by construction, a commitment that there is nothing at the vendor to export later.

That is not an argument against it. It is an argument that a zero-retention arrangement makes your own logging pipeline load-bearing, because it is now the only record that a request happened. Teams that adopt zero retention and keep logging as an afterthought discover at migration time that they cannot answer basic questions — which prompt version served which tenant in March, how often a particular tool call failed, what the p95 was before the incident. Under zero retention those answers exist only if you wrote them down.

What to look for in your own agreement

Open the agreement and the data processing addendum together — the DPA usually carries the operative retention language even when the main agreement is silent — and answer these in writing. If an answer is “the documentation says so” rather than “clause 7.3 says so”, that is a finding, because documentation is changed unilaterally.

• Which clause states the post-termination retention period, and is it a number of days or a qualitative phrase?
• Does any clause oblige the provider to make data available for export on request, and within what period? If not, your export path is a product feature, not an entitlement.
• Are derived artefacts — fine-tunes, uploaded files, hosted indexes — named separately from content, and does the export obligation, if there is one, cover them?
• What survives deletion via the backup or legal-hold carve-out, and for how long? This is a security question as much as a migration one.
• Is usage and billing metadata covered by the same retention period as content, and can it be exported in a machine-readable form rather than a PDF invoice?
• Does notice of termination start the deletion clock, and if so, is there a defined transition period during which access continues? That interacts directly with your notice period.

The practical conclusion is the same for almost every team that works through this list: the cheapest fix for retention risk is to stop depending on the vendor’s copy. A request log you own, with the model identifier, the prompt version, the token counts and the outcome on every row, converts most of this section from a contractual negotiation into a database query. Negotiate the clause anyway — but build so that the answer does not decide whether you can leave.