Migrating Away From a Model That's Being Sunset Mid-Contract

The model you built on is being retired in sixty days. The commitment you signed runs for another nine months. These two facts are almost never connected by anything in the agreement, and the gap between them is where the negotiation is.

Two clocks that were never linked

Model lifecycle and commercial term are separate mechanisms. The lifecycle is a published, unilateral schedule: the provider announces a retirement date and the model stops answering on it. The commercial term is a bilateral agreement about money and duration. Nothing automatically ties one to the other, and the asymmetry is the point — you are committed for a period during which the specific thing you were building on may cease to exist.

This is usually not a breach, and starting from the assumption that it is will waste the conversation. Most agreements are written against a service, not against a model version, and most providers document a lifecycle that the customer is taken to have accepted. The realistic goal is not remedy. It is to convert a schedule you cannot change into concessions that reduce what the migration costs you: time, credits, engineering support, or flexibility in how the commitment is consumed.

Note also that the retirement date is not necessarily one date. Where a model is available through more than one platform — a first-party API and a cloud marketplace, say — those platforms may run separate schedules, so one deployment can have months of runway that another does not. Check each surface you call rather than assuming a single deadline.

The clause types that decide this

Find these in your own agreement before you contact anyone. Which of them exist, and in what form, determines the entire shape of the conversation.

• What the commitment is denominated in. A commitment in currency, consumable across whatever models exist, is barely affected by a retirement. A commitment expressed in units of a specific model, or in capacity reserved against a specific model, is directly impaired by it, and that impairment is the strongest argument you have.
• Whether the service is defined by version. If the agreement names the service generically, a version change is inside what you agreed to. If it names a model version, you have a much more direct conversation.
• Deprecation and change-of-service clauses. Some agreements set a minimum notice period contractually, which may be longer than the public policy, and some give the customer a defined response if a material component is withdrawn. This is the first clause to look for and the one most often absent.
• Rollover and carry-forward. Whether unconsumed commitment survives the term, and under what conditions. If a retirement forces a pause in your usage, rollover is often the cheapest thing for a vendor to grant and the most valuable thing for you to receive.
• Exit and notice. How much notice you must give not to renew, and whether that window is already open. A retirement that lands close to a renewal notice deadline is a materially different situation from one that lands just after it, and the calendar is not negotiable once passed.
• Data portability and retention. What you can take with you and in what format — fine-tuned artefacts, stored files, batch results, logs — and how long they persist after the term. This costs nothing to check now and is expensive to discover at the end.

A fine-tune deserves a paragraph of its own, because it is the case where the impairment is unambiguous. A model you paid to train is derived from a base model, and when the base is retired the derived artefact usually goes with it. Establish immediately whether your training data and configuration are exportable, and whether the fine-tune can be reproduced on a successor base at the vendor’s cost or yours. That single question is often worth more than everything else on this list.

What to raise with the vendor, and when

Contact them early. A retirement schedule is not going to move for one customer, but the accommodations around it are decided by people with budgets and quarters, and those are much easier to obtain sixty days out than five days out.

1. Establish the facts in writing first: which model strings you call, what volume, on which surfaces, and what commitment is outstanding. A request backed by usage figures is a different conversation from one backed by an assertion.
2. Ask what the successor is and what the vendor’s own migration guidance says. Providers generally publish a recommended replacement alongside a deprecation, and starting there costs nothing.
3. Ask for an extension on the specific model, and expect no. Ask anyway, in writing, because the answer sometimes differs for large deployments and because the refusal frames everything after it.
4. Ask for the things that are actually grantable: credits against migration cost, an extension of the commitment period, rollover of unconsumed spend, relief from a minimum during the transition quarter, or engineering support for the port. These are decisions a named account manager can make.
5. Get whatever is agreed recorded as an amendment. A helpful email from an account manager who changes role is not a term.

Sequencing the work while the conversation runs

Do not let the commercial thread gate the engineering one. The model stops answering on the published date whatever anyone says, and a team waiting on a negotiation is a team that has spent its window.

Run the operational plan in parallel and unchanged. Planning the grace period lays that out: inventory, evaluate, dual-run, ramped cutover, finish early. The commercial conversation changes what the migration costs, not whether it happens.

Two things are worth doing differently in the mid-contract case. Keep your usage on the old model steady rather than winding it down early, if the commitment is consumption-based — spending down against a model that is about to disappear is better than forfeiting the commitment, and it is a lever you lose by moving too fast. And instrument for the retirement itself: after the date, calls to the retired string will fail, typically as a 404 with a not-found error type, and you want that to be an alert with a name rather than a model-not-found error surfacing to a user.

What to change before the next renewal

This will happen again, and the cheap fixes are all upstream.

Denominate commitments in currency rather than in a model wherever you have the choice. Ask, during renewal, for a contractual notice period on model withdrawal rather than relying on published policy, and for rollover in the event that a withdrawal interrupts consumption. Ask what happens to fine-tuned artefacts when a base model is retired, and get the answer in the agreement.

On the engineering side, stop letting a model string be a load-bearing constant. An internal alias layer means the retirement is a configuration change in one place rather than a search across every service, and it is the difference between a fortnight’s notice being survivable and being an incident.