AI Model Migration
When an LLM your product depends on is retiring, being re-routed or falling behind, we prove which replacement holds up on your own cases, rework the prompts and code for it, and switch you over with a rollback path, before the date.
Bring your model name and its retirement date. Free · 30 minutes · You talk to an engineer.
Your model is being retired, or quietly swapped
Every major model vendor retires older models on a published schedule. Some switch the old model off; others keep the endpoint working and answer your requests with a different model.
| Date | What happens | Vendor's recommended replacement |
|---|---|---|
| 30 Nov 2026 | Anthropic retires Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) on the Claude API | claude-sonnet-5-5 |
| 1 Dec 2026 | Google routes all API requests for gemini-2.5-pro to gemini-3.8-flash, billed at Gemini 3.8 Flash rates | gemini-3.8-flash |
| 11 Dec 2026 | OpenAI removes older GPT-5 and o3 snapshots, such as gpt-5-2025-08-07 | For example gpt-5.6-sol |
| 14 Jan 2027 | OpenAI removes GPT-4o, GPT-4o mini, GPT-4.1 and GPT-4.1 mini from the API, with their fine-tuned versions | gpt-6-luna |
Checked on 8 November 2026 against the Anthropic, Google and OpenAI deprecation pages. Vendors change these dates, and the same model can retire on different dates on Amazon Bedrock, Google Vertex AI and Microsoft Foundry. Always confirm on the vendor's page, and check the retirement emails you've received: they don't always match the page.
Your model may not switch off. It may be swapped.
Google keeps some retired endpoints running and answers them with a newer model: requests to gemini-3.5-flash and gemini-3.7-flash are already answered by newer models. Nothing errors, and the only sign may be a different modelVersion in the response. A baseline scored before the switch is the only way to know what changed for your users.
Retirement isn't the only reason teams move. A newer model may be cheaper or better but untested on your workload, or a contract, data-residency or consolidation decision may move you to another provider or cloud.
What AI model migration is
AI model migration means replacing the model behind a live AI feature (a newer version, a different provider or a different cloud) and proving that output quality, format, latency, cost and data handling still meet your bar before users see the change.
It's for the engineering lead, CTO or staff engineer who owns an LLM feature in production: a support assistant, an extraction pipeline, an agent that calls tools, a classifier built on prompts. The replacement is rarely a drop-in, and the question that matters isn't “is the new model good?” but “is it good enough for this feature?”
It isn't data migration, code migration or cloud infrastructure migration. If your model is fine-tuned, see Fine-Tuned Model Migration, which covers retraining it on a new base.
What usually changes when you swap models
Model failures are often silent to the systems using the model and loud to users. Nothing crashes. Error rates stay flat.
Changing the model name in code can take one line. What changes behind it falls into four groups:
| Group | What can change | Example of what breaks |
|---|---|---|
| Output | Structured output (JSON fields, schema), tool selection and arguments, refusals | A field your parser expects disappears, or the model decides not to call a tool it used to call. After one re-route, developers reported a newer model skipping tool calls for certain prompts while still returning valid JSON |
| Behaviour | Tone, length, hedging, how edge cases are handled | Summaries get longer and more cautious; an edge case the old model handled now gets a generic answer |
| Performance | Latency, time to first token, rate limits and quotas | A synchronous path that was fast enough is now too slow |
| Cost and features | Price per token, token counts, features one model has and the next doesn't | The replacement has no equivalent for a capability you rely on, as developers found with timestamp and speaker-labelling options when one speech model retired |
Removed parameters and API changes add code work on top: a parameter the new model no longer accepts, or a retired API such as OpenAI's Assistants API, which shut down on 26 August 2026.
A model gateway or an OpenAI-compatible endpoint makes the switch easy. It doesn't make it safe: the same request still gets a different model's answer.
What you get
| Deliverable | What it contains | When |
|---|---|---|
| 1. Inventory | Every call site, SDK, gateway and stored prompt for the features in scope; which model version actually serves each; retirement dates per platform | Migration Sprint |
| 2. Evaluation set and baseline | Real cases from your production traffic, with expected answers your domain expert approved, and your current model's scores on them | Migration Sprint |
| 3. Migration memo | Your vendor's replacement and the agreed alternatives, scored on the same set by category; cost per call and latency; a recommendation | End of the Sprint. Gate 1: you choose |
| 4. Re-engineered prompts and code | Versioned prompts, parameters, output parsing and model-calling code for the chosen model | Migration Build |
| 5. Evaluation report | The chosen model re-scored on the same set plus regression checks, with every difference listed | Migration Build. Gate 2: you accept |
| 6. Shadow-run and cutover plan | How a copy of live traffic is compared, the staged rollout, the rollback path and who does what | Migration Build |
| 7. Model record and handover pack | Which model serves which feature, why, the scores that justified it, and how to re-run the evaluation | Handover |
You own the evaluation set, the prompts and the records once the work is paid for; we keep our own reusable tooling. No promise of identical outputs: every difference is measured, and you accept or reject it before live traffic moves.
Want to know what testing the replacement involves for your feature?
Book a free migration fit call(opens scheduling widget)How we migrate
We migrate in six stages, and you make the two decisions that matter.
Migration Sprint
Stages 1–3
Stage 1: Inventory
We find every place the feature calls a model, including gateways and stored prompts, and check which model version actually answers.
- What you do
- Give us repository access and any vendor emails.
- You get
- Inventory
Stage 2: Baseline
We build an evaluation set from your production traffic and score your current model on it.
- What you do
- Your domain expert approves the expected answers.
- You get
- Evaluation set and baseline
Stage 3: Shortlist & score
We score your vendor's replacement first, then the alternatives you allow.
- What you do
- Tell us your constraints.
- You get
- Migration memo
Gate 1: you choose. You pick the model from the scores. If your vendor's replacement holds up, you can stop here.
Migration Build
Stages 4–6, only if needed
Stage 4: Re-engineer
We rework prompts, parameters, output parsing and code for the chosen model, where the scores show it's needed.
- What you do
- Review the code as usual.
- You get
- Versioned prompts and code
Stage 5: Prove
We re-score on the same set, run regression checks and measure latency and cost per call.
- What you do
- Review every difference.
- You get
- Evaluation report
Gate 2: you accept, or send it back. Nothing goes live until you've accepted the evaluation report.
Stage 6: Switch & hand over
A shadow run, where the new model answers a copy of live requests that users never see, then a staged rollout, with the old model ready while it still exists.
- What you do
- Decide when traffic moves.
- You get
- Model record and handover pack
Before automated scores are trusted, we check them against your expert's judgement on a sample: research on enterprise model migrations found that only one of several automated metrics consistently matched human judgement. The order follows the model-migration processes Microsoft and AWS publish.
On timing: we plan back from your vendor's date. The schedule is set in the written Sprint scope, and it depends mostly on how quickly we get access, a traffic sample and your expert's review. Starting earlier leaves more room for testing.
Testing the replacement yourself first? Our guide how to benchmark a candidate model against your own workload walks through the method.
Common migrations
- A newer version from the same vendor. Usually the smallest change, and the one most often assumed to be safe. Score it anyway: every group in the table above still applies.
- OpenAI ↔ Claude API. Different prompting conventions, system-prompt handling, tool-calling formats and refusal behaviour. Prompts usually need restructuring rather than copying.
- OpenAI → Gemini. A different SDK and parameters (Gemini's newer models configure reasoning with
thinking_level), different structured-output settings and safety behaviour. - Closed → open-weight models. You choose where the model runs and when it changes, and take on hosting. Licence terms vary by model.
- Agents and tool calling. Tool selection and arguments are where agents break first after a model change. See also our agent engineering work.
Moving to Bedrock, Foundry or Vertex
Moving a model call into your cloud changes authentication (IAM roles instead of API keys), endpoints, quotas, regions, and sometimes which model versions are available. We have no platform to sell: we score staying where you are against moving, on the same evaluation set, and you decide.
Is this the right service?
Good fit if
- A live feature depends on a model with a retirement or re-route date.
- You're moving provider or cloud, or consolidating providers.
- You want a newer, cheaper model but have no way to prove it's safe for your feature.
- Tool calling, structured output or agents sit in the path.
Not the right service if
- Your model is fine-tuned: see Fine-Tuned Model Migration.
- Your goal is only to cut cost, with no model change planned.
- You need someone to run or monitor the system after the switch. That's your team's job or a separate engagement.
- The feature is low-risk and your vendor's replacement is likely to be fine. A quick test may be enough, and we'll say so on the fit call.
What you provide
- Model names, versions and where each runs (direct API, Bedrock, Foundry, Vertex, self-hosted)
- Access to the prompts and code, or a repository branch
- A sample of production inputs and outputs, or permission to collect one
- A few hours of a domain expert's time to approve expected answers
- Your constraints: region, data handling, approved vendors
- The real deadline, including any vendor emails about it
- A staging environment for the shadow run
We sign a mutual NDA before you share data.
What's not included
- Running, monitoring or cost-managing the system after handover
- Rewriting the wider application or user interface
- Negotiating or ending vendor contracts
- Legal or compliance sign-off (we provide the evidence pack)
- Retraining fine-tuned models (Fine-Tuned Model Migration)
- Model and API usage fees, which your provider bills you directly
- A guarantee of identical outputs or of savings
What drives the effort
| Factor | Why it changes the work |
|---|---|
| Number of features and call sites moving | Each needs its own cases and acceptance threshold |
| Whether you already have test cases | Building the evaluation set is usually the largest part of the Sprint |
| Tool calling, structured output or agents | More ways to break, so more regression checks |
| How many candidate models you want compared | Each one is scored on the same set |
| A provider or cloud change, not only a version upgrade | SDK, authentication and endpoint changes add code work |
| Data-handling and region constraints | They limit where samples live and which candidates qualify |
| How close the deadline is | A near date limits how much testing fits |
The fit call is free. The Migration Sprint is fixed-scope and priced per scope, and you see the price before any work starts. If the Sprint shows your vendor's replacement holds up, the engagement can end there. A Migration Build, if needed, is scoped and priced separately.
Model names, where they run, and your deadline. An engineer replies within one business day.
How to judge us
| Question | Crescent AI | Cloud-platform partners | Gateway and routing tools | Doing it in-house |
|---|---|---|---|---|
| Who picks the target model | You, from scores on your cases | Usually their platform | You configure routing | Your team |
| Can recommend staying where you are | Yes | Rarely: the offer is a move to their platform | Not applicable | Yes |
| Evaluation on your own traffic | Yes, with your expert approving the bar | Varies | Not their focus | If there's time |
| Who accepts the result | You, at Gate 2, in writing | Varies | Not applicable | Your team |
| What you keep | Evaluation set, prompts, model record | Varies | The tool subscription | Whatever gets written down |
| After the switch | Your team runs it | Often a managed-services contract | Platform subscription | Your team |
How you'll know where it stands: a weekly report (done, in progress, next, risks, blockers), a risk register, a decision log and a change-request process for anything that shifts scope. See how we work.
Who leads this work
Yash Amin, founder of Crescent AI. About Crescent AI
What happens next
- 01Book a 30-minute call, or send your model list. Tell us which model you're on, where it runs and the date you're working to. A short, non-confidential note is enough.
- 02You talk to an engineer. We look at what the feature does, how it calls the model and what the retirement or re-route means for it.
- 03You get a written next step: a Migration Sprint scope with its price, or a plain “you don't need us for this”.
If you send details instead, an engineer replies within one business day.
Common questions
What if the retirement date arrives before we're done?
Tell us the date on the fit call and we'll say whether there's room to test properly. The plan works back from it, with your decision point and the shadow run placed before the date. If time is too short, the migration memo names the safest option: switch to the vendor's replacement with the known differences listed, or ask the vendor about extended access where they offer it.
Our model is being auto-routed, not shut down. Does that matter?
Yes, because nothing will fail. From the routing date your requests are answered by a different model, and the only sign may be the model version in the response. Scoring your current model before that date is the only way to see what changed.
We don't have a test set. Can we still do this?
Yes. Most teams don't. Building the evaluation set from your production traffic is part of the Migration Sprint, and your domain expert approves the expected answers.
How much of our team's time does it take?
Mostly a domain expert's review of expected answers (a few hours during the Sprint), access to the code and a traffic sample, and a normal code review during the Build. We do the engineering.
Can you work within our data-handling rules?
Yes. We sign a mutual NDA before you share data, and samples stay within the region and handling constraints you set. For sensitive flows, the shadow run uses a copy of live requests whose answers never reach users.
What if no candidate model is good enough?
The migration memo says so, with the scores. The options are usually to accept a model with known, listed differences, to restructure the prompts or the task and re-test, or, if the old behaviour was trained in, to rebuild it as a fine-tuned model.
Can you move us to Bedrock, Foundry or Vertex?
Yes. We score staying where you are against moving, on the same evaluation set, and handle the authentication, endpoint and quota changes for the model calls. We have no cloud or platform to sell, so the recommendation follows the scores.
How much does an AI model migration cost?
It's priced per scope. The scope depends mostly on how many features move, whether you already have test cases, and whether tool calling or a provider change is involved. The fit call is free, and the Migration Sprint has a fixed price agreed before it starts.
Bring us your model name and its retirement date.
We'll tell you whether the replacement is likely to hold up, and what proving it on your own cases involves.
Mutual NDA before you share data · Vendor's replacement tested first · Fixed-scope Migration Sprint
Part of AI Model Migration & Modernization · Fine-Tuned Model Migration · AI Evaluation · Agent Engineering