Source: [Model retirement: find the saved workflows that still call the old model — Skills for Business]() [← All articles](https://skillsforbusiness.ai/blog/) Model intelligence · Guide # Model retirement: find the saved workflows that still call the old model Build a model-retirement inventory across jobs, saved configurations and fallbacks, then verify the runtime change before the old endpoint disappears. [Skills for Business](https://skillsforbusiness.ai/blog/editorial/)2 November 20267 min read On this page 1. [Establish what the provider is actually retiring](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#establish-what-the-provider-is-actually-retiring) 2. [Do not mistake a migration commit for a production change](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#do-not-mistake-a-migration-commit-for-a-production-change) 3. [Build an inventory of consumers and reference locations](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#build-an-inventory-of-consumers-and-reference-locations) 4. [Work through a fictional report-service inventory](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#work-through-a-fictional-report-service-inventory) 5. [Decide what happens to work already in progress](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#decide-what-happens-to-work-already-in-progress) 6. [Verify the route that will run after the deadline](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#verify-the-route-that-will-run-after-the-deadline) 7. [Close the long tail instead of celebrating the default change](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#close-the-long-tail-instead-of-celebrating-the-default-change) 8. [Sources](https://skillsforbusiness.ai/blog/model-retirement-saved-workflow-inventory/#sources) What to take away - Changing a default does not establish that saved jobs and fallback routes stopped using an old model. - Link each model reference to an owner, a queued-work decision and runtime verification. - After retirement, rollback may require another approved configuration or a paused workflow. When a model provider announces retirement, find every workflow that can still request that model before changing the application’s default. Include saved configurations, scheduled jobs, queue payloads and fallback routes. Assign an owner and verify the running configuration for each affected consumer. A successful edit in one application does not establish that the migration is complete. This is a different decision from whether a new model deserves adoption. An organization may prefer its existing setup and still have to replace a dependency that will become unavailable. This guide proposes a retirement inventory and handoff method for that situation. The example is fictional; we have not inspected a company’s model usage or independently tested a provider migration. ## Establish what the provider is actually retiring Use the current notice for the exact model, endpoint and hosting platform. Record the source URL, access date, announced status, deadline wording and responsible account contact. Distinguish a firm date from an earliest possible date or an announcement that has not yet supplied one. Do not infer a precise shutdown hour or timezone from a date-only notice. [Anthropic’s lifecycle documentation](https://platform.claude.com/docs/en/about-claude/model-deprecations), inspected on 2 November 2026, distinguishes a deprecated model that remains functional from a retired model whose requests fail. It also says partner-operated platforms can have different schedules. A familiar model name alone is therefore insufficient to determine which notice applies. [Google’s Gemini deprecation page](https://ai.google.dev/gemini-api/docs/deprecations) describes shutdown as disabling the endpoint and labels its table dates as earliest possible dates. Some entries instead describe endpoints that continue routing requests to a replacement. These are provider-specific arrangements, not a universal promise of automatic migration. Our recommendation is to preserve the notice’s meaning in the migration record. “Earliest shutdown” should not become an unsupported guaranteed grace period; “recommended replacement” should not become “validated for our workflow.” Recheck the notice as the migration proceeds rather than freezing a mutable timetable into a planning document. ## Do not mistake a migration commit for a production change [Hyungjin Lukas Kim’s September 2026 preprint](https://arxiv.org/abs/2609.31288) studies open-source migration commits matched to provider retirement events. Its method examines repository evidence and validates a sample of classifications. That makes it relevant to how model dependencies appear in software maintenance. The paper also identifies limitations that matter for readers: commit-message searches miss some changes, search caps constrain collection, and catalogue cleanup can resemble application migration. A commit after a provider’s shutdown date does not by itself prove that production was broken until that commit. An application may have stopped using the model earlier and removed the reference later. This is observational preprint evidence, not a measured outage rate for your business. We use its distinction between repository changes and runtime behavior to motivate a practical question: **what evidence shows that this particular consumer no longer calls the retiring model?** No study percentages are transferred into the recommendations below. ## Build an inventory of consumers and reference locations Start with a search of repositories and deployment configuration, then expand to the systems that store operational settings. Look for exact model identifiers, configuration keys and known aliases. Record what each reference does before replacing it: an active request setting, an example, a historical log and a test fixture require different treatment. Ask application owners where a model choice becomes fixed. It might be read from a shared configuration at execution time, copied when a job is scheduled, or embedded when a workflow is published. The inventory must describe the actual implementation; it should not assume that all consumers inherit a central default. Anthropic’s documentation describes exporting usage by API key and model from its console. Such usage evidence can help identify active callers within that service. It cannot, on its own, prove that a rarely run job or an unexercised fallback has no remaining reference. Combine available runtime evidence with configuration inspection and owner confirmation, under the organization’s access controls. For each consumer, capture its purpose, owner, hosting surface, requested model reference, reference location, activation cadence and proposed disposition. Add the replacement configuration and verification evidence when known. Mark unknown ownership or an inaccessible configuration as an unresolved item, rather than counting it as migrated. ## Work through a fictional report-service inventory Consider a fictional company with a weekly report assistant. The team has changed the web application’s shared default from **Model A** to **Model B**. These names are placeholders, not real products or a compatibility claim. The provider has separately announced that Model A will stop serving requests. The following inventory illustrates why the web edit is only one part of the change: | Consumer or stored reference | Fictional behavior | Required migration decision | | --- | --- | --- | | Interactive report page | Reads the shared default on each new request | Verify a new request uses the approved replacement configuration | | Saved weekly schedule | Stores its own Model A selection | Update the saved schedule and inspect the next execution | | Already queued report | Payload contains Model A and an instruction revision | Decide whether to finish, rebuild or hold the queued work | | Error fallback | Explicitly retries through Model A | Replace or disable that route and exercise its trigger | | Quarterly export | Uses a separate service configuration | Assign its owner and verify before its infrequent normal run | | Historical run record | Preserves Model A as provenance | Retain truthful history; do not relabel the old result as Model B | All rows are invented. They describe implementation possibilities to investigate, not behavior guaranteed by a particular scheduler or assistant. A team may discover a centralized system with fewer independent references, or a more distributed one with additional consumers. Keep the inventory’s unit clear. Six references do not necessarily mean six independent applications. One application may contain several model choices, and several applications may share one deployment setting. Track the dependency relationship so updating a common setting does not lead to an unsupported claim that every consumer was exercised. ## Decide what happens to work already in progress A new default cannot retroactively answer how an old queued request should run. Identify where the model, instructions, tools and output requirements were captured, then choose a disposition with the workflow owner. Finishing under the old configuration may be possible before retirement if that configuration remains available and approved. Rebuilding under the replacement creates a changed run and needs the relevant validation. Holding or cancelling work may be preferable when neither route is ready. Do not silently retry an action-bearing workflow under a different model merely because the old request failed. Preserve the original run identity and record the relationship to any replacement run. Check completed effects before replaying work, especially if an earlier attempt could have sent messages or updated records. Our [safe-retry guide](https://skillsforbusiness.ai/blog/ai-agent-timeouts-safe-retries/) covers that separate uncertainty: changing a model does not establish that repeating an operation is harmless. ## Verify the route that will run after the deadline Selecting a candidate replacement still requires task-level evaluation. The [model-upgrade evaluation guide](https://skillsforbusiness.ai/blog/frontier-model-upgrades-business-evaluation/) covers quality, review effort and cost comparisons. For retirement readiness, add evidence that the deployed consumer actually selects the tested configuration, including relevant endpoint, settings, instructions and tool access. Test through the real activation path in an appropriate environment: a scheduler invocation for a scheduled task and an exercised error condition for a fallback. A successful interactive request does not cover both. Record requested identifiers and any resolved-model information the service actually exposes. If the serving identity is not observable, state that limit rather than inventing proof from the answer’s writing style. Plan a fallback that remains usable after the old model’s retirement. “Switch back to Model A” ceases to be a recovery option if the endpoint is gone. An alternative may be another evaluated configuration, a supervised process or pausing the affected automation. The choice depends on the task and its consequences; there is no universal substitute model. ## Close the long tail instead of celebrating the default change Will Larson’s [2018 migration guidance](https://lethain.com/migrations/) emphasizes enabling difficult consumers, preventing new use of the legacy approach and finishing remaining cases. This is general practitioner advice, not research establishing a success rate for model migrations. It offers a useful reminder that the unusual, infrequent consumer still needs an owner. Update starter templates and shared documentation so new workflows do not recreate the retiring dependency. Preserve historical results and their original provenance. Review the inventory against observed usage, investigate unexplained calls, and state the observation window’s limits. A quiet day cannot verify a quarterly job. Close each affected consumer with a concrete disposition: migrated and verified, deliberately stopped, or still unresolved with an accountable owner. Keep configuration changes, executed checks and missing evidence distinguishable. Retirement readiness is established consumer by consumer, not by the announcement that a new default has been selected. ## Sources & further reading Sources checked for this article. Research findings and vendor claims are distinguished in the text. 1. [Model deprecations](https://platform.claude.com/docs/en/about-claude/model-deprecations)Anthropic / Claude Platform Docs · Accessed 2 November 2026 2. [Gemini deprecations](https://ai.google.dev/gemini-api/docs/deprecations)Google AI for Developers · Accessed 2 November 2026 3. [When the Model Retires: An Empirical Study of LLM Migration in Open-Source Applications](https://arxiv.org/abs/2609.31288)Hyungjin Lukas Kim; arXiv · Accessed 2 November 2026 4. [Migrations: the sole scalable fix to tech debt.](https://lethain.com/migrations/)Will Larson; Irrational Exuberance · Accessed 2 November 2026 Produced with AI-assisted research and writing. Examples and recommendations are our editorial synthesis unless attributed. This article does not claim independent product testing or human expert review. [Read our editorial policy.](https://skillsforbusiness.ai/blog/editorial/) ## Keep reading [Genie 4 for workplace training: define what the world must preserve](https://skillsforbusiness.ai/blog/genie-4-workplace-training-scenario-rules/)[Kimi 3D Make: define the business deliverable beyond the preview](https://skillsforbusiness.ai/blog/kimi-3d-make-business-deliverables/)