AI Model Migration & Modernization
Move the models inside your product to newer versions, providers or clouds, and rebuild the AI components that have fallen behind, with proof on your own cases that nothing got worse.
Bring your model name and its retirement date. Free · 30 minutes · You talk to an engineer.
What is AI model migration and modernization?
AI model migration and modernization means keeping the AI inside a live product current: moving each feature to a newer model, provider or cloud when the old one retires or falls behind, and rebuilding AI components that no longer meet the bar, while proving on your own cases that quality, format, latency, cost and data handling still hold.
What it isn't: using AI to modernize legacy software such as mainframe or COBOL code; cloud or data migration; or a general programme to make your systems ready for AI. If you're building a new AI system, see AI development.
Why it comes up now
Model vendors retire older models on a published schedule, and some don't switch the old model off: they answer your requests with a newer one.
| Date | What happens |
|---|---|
| 30 Nov 2026 | Anthropic retires Claude Sonnet 4.5 (claude-sonnet-4-5-20250929) on the Claude API |
| 1 Dec 2026 | Google routes all API requests for gemini-2.5-pro to gemini-3.8-flash |
| 11 Dec 2026 | OpenAI removes older GPT-5 and o3 snapshots |
| 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 |
Checked on 8 November 2026 against the Anthropic, Google and OpenAI deprecation pages. Vendors change these dates; always confirm on the vendor's page. Replacements and what changes are on the AI model migration page.
Deadlines aren't the only trigger. Older AI components fall behind too: a hand-built classifier nobody can retrain, a prompt chain that breaks whenever the model changes, or a system built on a framework that has been shut down, such as OpenAI's Assistants API on 26 August 2026.
Three services, one method
| Service | Who it's for | What you get |
|---|---|---|
| AI Model Migration | A live feature that calls a model through an API, and the model is retiring, being re-routed, or you're moving provider or cloud (Bedrock, Foundry, Vertex) | The replacement scored on your cases, prompts and code reworked for it, a shadow run and a switch with a rollback path |
| Fine-Tuned Model Migration | A fine-tuned model whose vendor is retiring it or its tuning service | The vendor's replacement tested first; if it falls short, your fine-tune rebuilt on a model you control |
| Legacy AI system rebuild | An older AI component that no longer meets the bar: a hand-built ML model, a fragile prompt chain, a system on a retired framework | The old system scored first, then rebuilt on a current model and architecture, or a hybrid of old and new, whichever the scores support |
On rebuilds, we measure the old system first. A newer model isn't automatically better at a narrow task, and the best answer is sometimes a hybrid: rules for the obvious cases, the existing model for the bulk, and an LLM only where judgement is needed. Ask about a rebuild on the fit call.
Which one do you need?
| Your situation | Start with |
|---|---|
| Your model is retiring or being re-routed, or you're changing provider or cloud | AI Model Migration |
| Your model is fine-tuned and its vendor is retiring it | Fine-Tuned Model Migration |
| It's an older ML model, a fragile prompt chain or a retired framework, and an LLM may now do the job better | A legacy AI system rebuild (ask on the fit call) |
| It's a classic ML model that should stay classic ML, retrained or re-engineered | Machine Learning Engineering |
| You're building a new AI system rather than changing an existing one | AI Development |
One method across all three
Every engagement runs the same six stages, and you make the two decisions that matter.
Migration Sprint
Stages 1–3
Stage 1: Inventory
Every place the feature calls a model, which model version actually answers, and the dates per platform.
Stage 2: Baseline
An evaluation set built from your production traffic, with expected answers your domain expert approves, and your current system scored on it.
Stage 3: Shortlist & score
Your vendor's replacement first, then the alternatives you allow.
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 or rebuild
Prompts, parameters, output parsing and code for the chosen model, or a rebuilt model where the old one was trained.
Stage 5: Prove
Re-scored on the same set, with regression checks, latency and cost per call.
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 on a copy of live traffic, a staged rollout with the old model ready while it still exists, then handover.
Before automated scores are trusted, we check them against your expert's judgement on a sample. The order follows the model-migration processes Microsoft and AWS publish. Evaluation is the first stage of every engagement; for evaluation as a standing practice, see AI evaluation.
What you keep
- The evaluation set, built from your traffic, so the next retirement starts from it instead of from zero.
- The scores for every model compared, broken down by category: format, tool calls, refusals, tone and length, latency, cost per call.
- The prompts, code or rebuilt model, versioned, in your repositories.
- A model record: which model serves which feature, why, and how to re-run the evaluation.
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.
Have a model with a date on it?
Book a free migration fit call(opens scheduling widget)How to judge us
- No platform to sell. We score staying where you are against moving, and your vendor's own replacement first. Cloud partners and gateway tools tend to move you onto theirs.
- You make the calls. You choose the model at Gate 1 and accept the result at Gate 2, in writing. Nothing goes live on our say-so.
- A stop point that can save you the project. If the replacement holds up, the Migration Sprint ends with “take it”.
- You can see where it stands. A weekly report, a risk register, a decision log and a change-request process. See how we work.
Who leads this work
Yash Amin, founder of Crescent AI. About Crescent AI
How you buy it
- 01Free fit call (30 minutes). You talk to an engineer about the feature, the model and the date. You get a written Sprint scope with its price, or a plain “you don't need us for this”.
- 02Migration Sprint. Fixed scope, priced per scope and agreed before it starts. Inventory, baseline and scores, ending in a migration memo and your Gate 1 decision.
- 03Build, only if needed. Scoped and priced separately: re-engineering or rebuilding, proof on the same set, the shadow run, the switch and handover.
What sets the size of the work
How many features move · whether you already have test cases · tool calling, structured output or agents in the path · how many candidate models you want compared · a provider or cloud change rather than a version upgrade · data-handling and region constraints · how close the deadline is.
Model and API usage fees are billed by your provider, not by us. We sign a mutual NDA before you share data.
Model names, where they run, and your deadline. An engineer replies within one business day.
Common questions
Is this the same as legacy application modernization?
No. Legacy application modernization uses AI to rewrite old software such as mainframe or COBOL systems. This work modernizes the AI itself: the models and AI components inside a product that already uses AI.
Which service do I need?
If a model you call through an API is retiring or you're changing provider or cloud, it's AI Model Migration. If the model is fine-tuned, it's Fine-Tuned Model Migration. If it's an older ML model, a fragile prompt chain or a system built on a retired framework, it's a legacy AI system rebuild. If you're not sure, the fit call sorts it out.
Can't we just change the model name in our code?
You can, and nothing will crash. What changes is behind it: output format, tool calls, refusals, tone, latency and cost per call can all shift without an error. Scoring the old and new model on your own cases before the switch is how you find out.
What if our vendor's replacement is good enough?
Then we tell you, and the work can stop after the Migration Sprint. You keep the evaluation set and the scores, so the switch is backed by evidence rather than a launch announcement.
Do you run the system after the switch?
No. Every engagement ends at handover, with the evaluation set, the records and a runbook. Running and monitoring the system afterwards is your team's job or a separate engagement.
How is it priced?
Per scope. The fit call is free. The Migration Sprint is fixed-scope, with its price agreed before it starts, and a Build, if needed, is scoped and priced separately. The size depends mainly on how many features move, whether you already have test cases, and whether tool calling or a provider change is involved.
Bring us your model name and its retirement date.
We'll tell you which service fits, 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
AI Model Migration · Fine-Tuned Model Migration · AI Evaluation