When Your Foundation Model Gets Deprecated: The AI PM's Survival Playbook

Why Deprecations Are Different From Updates

Product teams often conflate two very different events: a model update (the provider improves the model at the same API endpoint) and a model deprecation (the provider retires an endpoint entirely). They require completely different responses.

Model Update

When it happens: Provider releases a new version of the model

Your move: Optional. You choose the timing. You can A/B test the old and new versions before committing.

Risk if ignored: Performance regression if you migrate without testing. Low urgency.

Model Deprecation

When it happens: Provider announces a hard retirement date for an endpoint

Your move: Required. You have no choice on whether to migrate, only on when within the notice window.

Risk if ignored: Production outage on the deadline. High urgency from day one of the notice.

How much notice do you get?

OpenAI's policy is a minimum of 6 months notice before deprecation. Anthropic typically provides 6 to 12 months. Google Vertex provides 12 months. In practice, major providers have sometimes extended deadlines when adoption of the successor model was slow. Do not plan around extensions. They are a historical pattern, not a commitment. The GPT-5.5 deprecation on October 14 was announced in April 2026 and stuck to the original date.

The Deprecation Timeline: What to Expect

Deprecation events follow a predictable arc. Knowing what happens at each stage lets you plan your response rather than react to it.

Announcement (Day 0)

Provider publishes the deprecation notice with a hard date and a recommended successor model. If you are not monitoring provider changelogs, you may not hear about this for days or weeks.

Action: Immediately catalog all production features using the deprecated model. Assign an owner and a priority to each. Open a tracking issue.

Assessment Window (Weeks 1 to 4)

This is the cheapest phase of the migration. You have time to evaluate the successor model carefully, run evaluations, and plan the migration. Most teams spend too little time here.

Action: Run your eval suite against the successor model. Measure accuracy, latency, and cost differences. Some successor models are faster and cheaper; some are not. Document the deltas before engineering starts.

Migration (Months 1 to 3)

Engineering updates the API calls, prompts may need adjustment (model behavior often differs from predecessor), and testing is required at each step. This phase is almost always longer than estimated.

Action: Prioritize highest-traffic and highest-stakes features first. Do not migrate everything at once. Shadow mode (running both models in parallel and comparing outputs without serving the new one) is the highest-confidence approach for critical features.

Cutover (Month 3 to 6)

Traffic moves from the deprecated model to the successor. Most features complete migration here. Some teams leave long-tail features to the last weeks.

Action: Keep rollback capability available until you have 2 to 4 weeks of stable metrics on the successor model. The deprecation deadline is not a quality guarantee on the successor.

Deadline (Final Day)

The deprecated endpoint returns errors. Any feature still calling it breaks. If you are here with unmigrated features, you have an incident.

Action: Have an on-call engineer available at the deadline. If you have been monitoring migration progress weekly, you should have nothing left to migrate on this day.

Triage: How to Assess Your Exposure Quickly

The first thing you need is a complete inventory of where the deprecated model is used. In most organizations, this takes 2 to 5 days to assemble accurately. Start immediately.

Which production features call this model endpoint?

This is your migration backlog. You cannot prioritize what you have not listed. Check API call logs, not just the codebase — models sometimes get added via third-party integrations that bypass internal code review.

What is the daily call volume on each?

High-volume features get migrated first. A feature with 10,000 calls per day failing on the deadline is an incident. A feature with 5 calls per day is a low-urgency cleanup.

Which features are user-facing vs. internal?

User-facing features failing on the deadline creates customer impact. Internal features failing create operational slowdowns. Both matter, but the customer-facing ones are your critical path.

Does each feature have an eval suite?

You cannot safely migrate a feature if you cannot verify the successor model produces equivalent output. Features with no evals need one before migration begins, not after.

Which teams own each affected feature?

Deprecation migrations cross team boundaries. You will be coordinating with engineering teams you may not normally work with. Identifying ownership early prevents the 'whose job is this?' conversation from happening on week 11 of a 12-week window.

Master AI Infrastructure Decisions in the Masterclass

The AI PM Masterclass covers model selection, migration strategy, and dependency management in the technical foundations track, taught live by a Salesforce Sr. Director PM.

The Migration Playbook

For each feature in your inventory, the migration follows the same four-step sequence. Adapt the timelines to your window, but do not skip steps.

Step 1: Establish a baseline

Before touching anything, capture the current model's behavior on your eval set. Accuracy on your key tasks, latency on representative payloads, and cost per call. This is your migration target. If the successor model cannot match these numbers within an acceptable range, you need to know that before you migrate, not after.

Step 2: Update and evaluate in shadow mode

Point the feature at the successor model endpoint, but route the new model's outputs to a logging layer rather than serving them to users. Compare outputs between the old and new model on live traffic. Look for divergence: tasks where the outputs differ significantly. These divergences are your testing focus.

Step 3: Update prompts if needed

Successor models often have different instruction-following behavior than their predecessors. System prompts that worked perfectly with GPT-5.5 may need adjustment for GPT-6 Luna. Pay particular attention to: output format instructions (JSON structure, length limits), persona and tone instructions, and few-shot examples that relied on the old model's specific response patterns.

Step 4: Staged rollout with metrics monitoring

Start at 5% of traffic on the successor model. Hold for 48 hours and compare user-facing metrics (not just model output metrics) between the control and treatment. Expand to 25%, 50%, 100% with holds at each stage. Have a rollback plan at each stage. Your rollback window closes on the deprecation deadline, so complete the 100% cutover at least 2 weeks before it.

Building Deprecation Resilience Going Forward

Every deprecation event teaches the same lesson: the migration was expensive because of decisions made before the deprecation was announced. Here is what to do now, between events, so the next one costs less.

Subscribe to provider changelogs

OpenAI, Anthropic, and Google each have changelogs and model lifecycle pages. Subscribe to them directly. Do not rely on tech news to surface deprecations: announcements are often on provider docs pages that do not get broad press coverage until weeks after publication.

Keep an internal model registry

Maintain a living document that maps every production feature to the model endpoint it calls, the owner, the call volume, and the eval coverage. When a deprecation is announced, you can assess your exposure in hours instead of days.

Abstract the model call

If your features call the OpenAI API directly with a hardcoded model string, every migration requires code changes across many files. An internal wrapper that maps a capability name ('fast-summarization') to a model endpoint makes migrations a single config change.

Build evals before you need them

Features with no eval suite are a liability during migrations. You cannot verify the successor model without one. Build evals at feature launch, not at migration time. Even a 50-example labeled set is dramatically better than nothing.

Test on successor models in advance

Provider documentation usually announces successor models months before old models are deprecated. Start testing your most critical features on the successor during the assessment window of the previous generation. You will have better data and less urgency when the deprecation arrives.

Track model release cadences per provider

Each provider has a rough release and deprecation cadence. OpenAI: major versions roughly every 12 to 18 months. Anthropic: roughly every 6 to 12 months. Knowing the cadence lets you include deprecation migrations in annual roadmap planning rather than treating them as unplanned work.