How to Handle AI Model Deprecation Without a Scramble

Model deprecation arrives on a timeline you do not control, and the work is the same size whether you start early or late. This playbook covers handling one without a scramble, drawing on FISTA Solutions' AI agents work.

When is this worth doing?

On the day a deprecation is announced, and before that as a preparation exercise.

The preparation matters more than the response. An organisation with a dependency map and a provider abstraction handles a deprecation as a normal migration; one without spends the window discovering its own architecture.

What does the sequence look like?

Step	Purpose
1. Know the dependencies	Which systems, which versions
2. Act on the announcement	Not on the deadline
3. Assess impact per system	Not all are equal
4. Run the normal migration	Compressed, not skipped
5. Cut over with time to spare	Before the hard date
6. Reduce exposure	Abstraction, pinning, alternatives

Step 1 — Know which systems depend on which models

Maintain a map: system, model, version, and who owns it.

Organisations without one spend the first week of a deprecation window finding out what is affected, which is the week they most need. Systems calling providers directly from several places make this harder than it should be.

A gateway that logs model usage by system produces this map automatically, which is one of several reasons to have one. See what is an ai inventory.

Step 2 — Act on the announcement

Start the work when the notice arrives rather than when the deadline approaches.

The window is fixed and the work does not shrink for starting late. Teams that defer discover in the final weeks that prompts need substantial rework, which leaves no room for shadow running and forces a cutover on faith.

Assign an owner immediately. Deprecation notices that arrive in a shared inbox with no owner get actioned at the deadline.

Step 3 — Assess impact per system

Not all affected systems are equal. Some use the model for a task the replacement handles identically; others depend on behaviour that may differ.

Triage: high-consequence systems, systems with structured output that downstream code parses, and systems with validation or regulatory evidence attached go first. Low-consequence internal tools can follow.

That ordering matters because the window is finite and the risk is concentrated.

Step 4 — Run the normal migration process, compressed

Baseline the current behaviour, compare the replacement on your own cases, rework prompts, shadow run, and cut over in stages.

Compression means shorter periods, not fewer steps. The step most often skipped is shadow running, and it is the one that catches the failures your evaluation set did not contain.

If the window genuinely does not allow shadow running, that is a reason to escalate the timeline rather than to skip it. See how to run a model migration.

Step 5 — Cut over with time to spare

Plan to complete before the hard date, not on it.

Deprecation deadlines are enforced, and a system still on a retired model stops working. The margin also covers the discovery that something did not migrate cleanly, which happens often enough to plan for.

Keep the old model available until it is switched off by the provider rather than by you. That preserves the rollback option for as long as it exists.

Step 6 — Reduce exposure afterwards

A provider abstraction, versions pinned and recorded per system, at least one tested alternative, and where possible a contractual notice period.

Those four turn the next deprecation from an emergency into a planned piece of work. The abstraction and the recorded versions are engineering; the notice period is a negotiation worth having at renewal.

Write down what the scramble cost. That number is the argument for the preparation.

What if the replacement is worse for your task?

Evaluate alternatives from other providers rather than accepting the successor by default.

A deprecation is a natural moment to reconsider the provider relationship, and the abstraction that makes migration easy also makes switching easy. Teams that treat the successor as the only option miss that.

Where no option meets the quality bar, that is an escalation rather than a technical problem, and it needs saying early.

What about fine-tuned models on a deprecated base?

They do not carry over. A fine-tuned model is specific to its base, and deprecation means retraining on the successor with the same data and re-validating.

That is a project rather than a migration, and it needs the training data, the configuration, and the validation evidence to still exist. Organisations that cannot reproduce their fine-tuning are in a difficult position, which is an argument for treating fine-tuned models as build outputs. See how to version prompts and models.

Who needs to be involved?

An owner for the deprecation overall, the owners of each affected system, and whoever manages the provider relationship.

The overall owner is what prevents the common failure where every team assumes another team is handling it.

How long does it take?

Whatever the provider's window allows, minus a margin. Start within days of the announcement; a window of several months is comfortable and a window of weeks is not.

What are the common failure modes?

No dependency map. Waiting for the deadline. Treating all systems equally. Skipping shadow running. Cutting over on the hard date. And not reducing exposure afterwards.

How do you know it worked?

Every affected system migrated before the deadline with margin, no production surprises, and a dependency map plus abstraction that makes the next one routine.

What does it cost?

Mostly people's time rather than tooling. The expensive version is the one that stalls halfway and leaves the organisation with neither the old state nor the new one, which is why a narrow first pass beats a comprehensive plan nobody finishes.

Budget the work as an operated change rather than a project with an end date, because most of these need a maintenance tail. See AI total cost of ownership.

What should you do first?

Produce the map of which systems use which model versions. If that takes more than an hour, it is the first thing to fix regardless of any pending deprecation.

How FISTA Solutions helps

FISTA Solutions runs this work alongside client teams rather than around them: a model-to-system dependency map maintained so impact is known immediately, migration run through the normal process compressed rather than shortcut, evidence produced as the work proceeds, and handover that leaves your people able to continue without us. Delivery runs through AI agents, AI enablement, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries, with 47% average efficiency gains where measured.

To run this with support, message FISTA on WhatsApp, or read how to run a model migration.