Your fine-tuned model's base is retiring: what to do before cutoff

The clock on a fine-tune is not the clock on its base

A fine-tuned model is a base model plus weights you paid to produce. When the base is deprecated, the weights go with it, and the replacement your vendor names is usually a base model. That is why a fine-tune needs its own plan rather than a line in the general deprecation checklist.

The dates differ by platform. On OpenAI's API, fine-tuned versions of the deprecated GPT-4o and GPT-4.1 snapshots follow the same shutdown schedule as their base models, which is 14 January 2027 ¹. That is 71 days from today, 4 November 2026. On Azure, fine-tuned models retire in two phases, training and deployment, and training retires no earlier than the base model's retirement date unless stated otherwise ².

Two consequences follow. First, Azure's later deployment dates give you runway, but not a place to retrain: the training door closes at or before the base retirement for most customers ². Second, Microsoft states that fine-tuned workloads cannot be auto-upgraded, carry their own training and deployment clock, and that adapting them means distillation or re-training rather than prompt and schema changes; it advises planning to re-tune against the replacement base early ³. And retirement dates are not extendable ³.

Step 1: Inventory every fine-tune and what it was for

Before choosing anything, list each fine-tuned model id you call and the job it does. Fine-tuned ids on OpenAI start with ft:; search code, config and stored settings for that prefix, and pull 30 days of requests grouped by model id as sent, from a provider usage export, a gateway or your own logs ¹.

For each fine-tune, write down five facts:

• The behavior it encodes. Output format, tone, label set, domain vocabulary, refusal rules. If nobody can state it, the training file is the spec.
• The training and validation data, and whether you still hold them. Many teams do not.
• The failure it was meant to fix in the base model. Models improve; some fixes may no longer be needed.
• Request volume and token shape, so cost can be projected later.
• The dates from the table above, for every platform it runs on.

The third item matters most. A fine-tune is often a patch for a weakness of an older base: inconsistent JSON, a house style, a classification boundary. A newer base may meet that bar with a prompt. A fine-tune that encodes proprietary knowledge or a subtle labeling policy usually will not.

Step 2: Decide between retrain, prompt and switch

You have three real options, plus a fourth that is a trap: do nothing and wait for an automatic upgrade. Auto-upgrades exist for Azure pay-as-you-go base deployments, and Microsoft calls them a safety net, not a migration plan; fine-tuned deployments are explicitly excluded ³. On OpenAI's API, the page as relayed describes no automatic upgrade; a request naming a retired id is simply a failure ¹.

The first constraint is whether a fine-tunable target exists. OpenAI's recommended replacement for the GPT-4o and GPT-4.1 family, gpt-6-luna, does not support fine-tuning ¹. Before you plan to retrain, confirm on your vendor's fine-tuning page which bases accept new training jobs today and until when; this guide could not read that page, so treat it as a check you owe yourself.

Walk it in this order:

1. Does a base with a later retirement date accept fine-tuning? If not, retrain is off the table; go to step 2.
2. Run the untuned candidate on the frozen eval set. If it clears your pass mark with a prompt and a schema, stop. This is the cheapest path to finish and the easiest to roll back.
3. If it misses by a small margin, try few-shot examples drawn from the training set and a stricter output schema before spending on training.
4. If it misses by a lot on a behavior the data encodes, retrain where you can, or switch to a vendor whose model passes. If you plan to distill your old fine-tune's outputs into a new model, read the provider terms first; see can you train on AI outputs.

Do not carry the old prompt across unchanged. Microsoft's guidance is to replay the current configuration on the target first, to separate behavior the model changed from changes you introduce, and then adapt parameters, tool definitions, schemas and calling code ³.

Step 3: Reuse the eval set, and freeze it

The eval set is the asset that survives the migration. Microsoft's process treats the test dataset as a gating dependency: you cannot replay without inputs or score without ground truth and criteria, and it should be built before you pick a target because it describes your workload, not the candidate ³.

Assemble it from three places:

• The fine-tune's validation split, if you kept one. It has labels and was never trained on, so it is your cleanest ground truth.
• Recorded production requests, sampled across the input shapes you really see, including the long and ugly ones. Do not sample only the easy median.
• Known failures: tickets, escalations, and cases where the fine-tune was wrong. A candidate that fixes them is worth more than one that matches the rest.

Never score a candidate on training rows; the fine-tune will look better than any untuned model, and a retrained model will look better than it is. Hold the training data out of the eval set entirely.

Freeze it. Microsoft's guidance is to keep inputs, ground truths and success criteria fixed for the whole migration, because changing any of them makes source and target results incomparable ³. Write the pass mark first: task success, schema or parse failures, refusals, truncation. For free-text outputs where you use a model as grader, calibrate it against human labels before trusting it; see can an LLM judge be trusted.

If you have no recorded requests, start capture today. Microsoft notes that production content capture is opt-in and never retroactive, so you cannot evaluate traffic you did not record ³. Replaying that traffic safely is covered in replaying production traffic.

import json, hashlib

def load_frozen(path):
    rows = [json.loads(l) for l in open(path)]
    digest = hashlib.sha256(open(path, "rb").read()).hexdigest()
    return rows, digest  # log the digest with every result

def passed(row, output):
    # pass mark written before the first run
    return (
        output.get("parsed_ok")
        and not output.get("truncated")
        and output.get("label") == row["expected_label"]
    )

rows, digest = load_frozen("eval_frozen.jsonl")
for candidate in ["old-finetune", "base+prompt", "other-vendor"]:
    results = [passed(r, run(candidate, r)) for r in rows]  # run() is yours
    print(candidate, digest[:8], sum(results) / len(results))

Always include the old fine-tune as a candidate. Its score is the baseline every replacement is judged against, and it tells you whether the eval set is measuring what the fine-tune was built for.

Step 4: Compare cost per passed task, not per token

Per-token rates mislead in this migration in two directions. A prompted base model carries instructions and examples the fine-tune did not need, so input tokens rise. A reasoning model bills hidden reasoning tokens as output. Microsoft warns that reasoning tokens, cached input and structured-output overhead can swing unit economics by 2x or more, and advises projecting monthly cost from historical traffic rather than list price ³.

Reference points, as relayed from OpenAI's list rates per million tokens: GPT-4o mini $0.15 input and $0.60 output, GPT-6 Luna $0.10 and $0.50 ¹. Luna defaults to medium reasoning effort, and on Chat Completions it supports function calling only at effort none ¹. Your provider bills at your contract's rates, so substitute those.

Then add the one-off column the per-token view hides: engineer weeks, training runs, eval grading, a canary period, and for a vendor switch the integration and contract work. Amortize it over the months you expect the replacement to stay in service. Microsoft's lifecycle shows the cadence: standard GA lifecycles run 18 months, and several third-party publishers 12 ⁴. A choice that costs more to adopt but runs a year longer can still win. Our general method is in cost per successful task.

Step 5: Cut over with the old model as the fallback

Put the new model behind a name you control, a config key or a route, and move traffic in steps: shadow first, then a small share, then the rest, with the old fine-tune as fallback until the last step ¹. Do not cut over on the shutdown date. Leave time to roll back to the old model while it still exists, since after the date there is nothing to roll back to.

Watch things your eval set cannot fully cover:

• Latency and truncation. A reasoning model can spend its output limit before it writes visible text ¹. Set the output limit with that in mind.
• Tool calls. Moving from a fine-tune to Luna on Chat Completions means either effort none or the Responses API for function calling ¹.
• Drift after launch. Keep scoring a sample of live answers against the same rubric.

Finally, retire deliberately: make your own systems refuse the old ft: ids before the vendor does, so a missed caller fails in staging with a clear message, and archive the frozen eval set, training data and results with the digest. You will repeat this migration, and the second one should start from a finished eval set.

Where a control plane helps

If your traffic passes through INFRO on your own provider connections, usage analytics group requests by model, key and project, which answers the inventory question for traffic that went through it; calls made straight to a provider do not appear. INFRO records vendor retirement dates, warns organizations still sending a retiring model, and from the shutdown date refuses the request before any provider call, naming the replacement and never substituting a model on your behalf ⁵. Routes with weighted targets can run the staged cut-over, and eval monitors can score a share of served answers against your rubric. Prompt and completion logging is off by default, so turn it on, with a retention window you choose, if you need recorded requests for the eval set. Details are in the models docs (opens in a new tab).