LLM Model Deprecation: Migrate Without Changing Production by Accident

The decision: migrate, constrain, replace the workflow or retire it

For each production workload, record one outcome: migrate to a named replacement configuration; constrain the workload while evidence is incomplete; replace the LLM path with another model, provider or deterministic workflow; or retire the capability. Do not make one fleet-wide decision from a generic vendor recommendation. A replacement can be acceptable for summarization and unacceptable for tool execution under the same account.

This decision rule is AccessAllGPT guidance. The unit under review includes the exact model ID, endpoint and host, prompts, parameters, context construction, retrieval, tools, parsers, policy checks, retries, fallbacks and downstream consumers. Changing the model can alter the behavior of that configured system even when request and response schemas still parse.

What vendor lifecycle pages establish—and what they do not

OpenAI, Anthropic, Google Cloud and Amazon Bedrock all publish lifecycle or deprecation documentation, but their terms, notice periods and platform boundaries differ. OpenAI documents minimum periods by model class with exceptions; Anthropic distinguishes active through retired states and says partner-hosted schedules can differ; Google Cloud documents service-specific availability categories; AWS says Bedrock lifecycle dates may differ from provider dates. Teams therefore need the schedule for the endpoint they actually call.

These pages establish vendor-stated availability policy and migration signals. They do not establish that a recommended replacement is behaviorally compatible with a local workload, that a model ID resolves identically across hosts, or that a migration will preserve quality, safety, throughput or cost. A recommendation is the start of release qualification, not completion evidence.

Find the real dependency surface before setting a deadline

Search application code, infrastructure, environment configuration, feature flags, prompt registries, notebooks, CI jobs and vendor consoles for model IDs and aliases. Then compare that static inventory with API usage, billing records, traces and gateway logs for an agreed lookback window. Include low-frequency month-end jobs, disaster-recovery paths and tenant-specific overrides that a short traffic sample can miss.

Map each reference to owner, host, region, credentials, workload, traffic path, data classes, consequence, current fallback and deployment method. Include embeddings, graders, moderation paths, batch endpoints, fine-tuned derivatives, cached routing decisions and agent subcalls. An alias such as “latest” is still a dependency; resolve and record the concrete version observed at evaluation and release time.

Translate the retirement date into internal control dates

Set dates for inventory freeze, candidate availability, evidence-plan approval, first shadow run, exception review, canary, default cutover, rollback-window closure and credential or configuration cleanup. Put the internal default cutover comfortably before the vendor retirement so outages, quota problems and regressions can be handled without negotiating against a hard stop.

Use the date published by the platform serving the request. Anthropic explicitly notes that partner-operated platform schedules can differ, and AWS says Bedrock-specific dates apply to Bedrock usage. Preserve the dated source URL and retrieval date in the change record; lifecycle pages can change. Re-check the schedule automatically or during every release cycle, but never let a later date silently expand an already approved risk window.

Freeze a portable migration contract

Version representative cases, expected and prohibited outcomes, source evidence, tool permissions, schema requirements, evaluator rules, repetitions, missing-run handling, mandatory gates and the smallest worthwhile improvement. Stratify cases by user, language, input length, data class, consequence and known failure mode. Preserve the incumbent results before changing prompts to accommodate the candidate.

The contract must be runnable outside a vendor playground and tied to immutable configuration identifiers. A migration that changes the model, prompt, retrieval and parser simultaneously cannot attribute a regression. Start with a model-only comparison where the API permits it; document unavoidable compatibility changes separately, then test the final integrated configuration end to end.

Test compatibility as behavior, not only syntax

Verify request fields, parameter ranges, system-message handling, tool and structured-output semantics, streaming events, token limits, stop reasons, error codes, rate limits, batch behavior and response accounting. Exercise empty, malformed, oversized and adversarial inputs. A successful SDK call proves transport compatibility only.

Then compare task outcomes, unsupported claims, citation support, abstention, schema validity, tool arguments, authorization denials, retry behavior and human correction. Preserve case-level differences. Do not hide a severe failure inside an average score, and do not assume that a more capable vendor-designated replacement follows the same instruction hierarchy or produces the same output distribution.

Qualify consequential tools and agents separately

For tool-using systems, replay complete trajectories and record proposed versus executed actions, selected tools, arguments, policy decisions, approval presentation, retries and final state. Require deterministic authorization after model output. Any new unauthorized action, cross-tenant access, approval mismatch or prohibited destination is a stop condition rather than a quality trade-off.

Test loops, duplicate actions, changed parallelism, longer planning, tool-choice omissions and recovery after partial failure. A replacement that improves answer quality can still increase action risk or operating cost. Keep the candidate read-only, draft-only or approval-gated until the exact authority path clears its mandatory controls.

Measure the economic and operational delta

Measure end-to-end latency distributions, time to first useful output, accepted outcomes, retries, input and output usage, cache behavior, tool calls, reviewer time and total cost for incumbent and candidate under the same production-shaped mix. Include changed context limits, reasoning effort, output verbosity and rate-limit tiers rather than comparing list prices alone.

Load-test within approved quotas and test backpressure, timeout and provider-error behavior. Forecast the migration period when both models may run in shadow or canary modes. Do not publish or approve a universal savings claim from vendor pricing: the defensible unit is cost per accepted local outcome under a declared configuration and workload.

Shadow first without duplicating side effects

Mirror eligible requests to the candidate after applying the same data permissions and retention rules, but suppress external writes and irreversible tools. Where inputs cannot lawfully or contractually be duplicated, use an authorized replay set or a smaller controlled cohort. Label shadow output so it cannot be consumed accidentally by downstream production systems.

Monitor missing comparisons, evaluator failures and selection bias: a shadow set containing only easy, cacheable or low-risk traffic cannot authorize consequential traffic. Resolve material regressions by case family. If prompt or workflow changes are needed, create and evaluate a new candidate configuration rather than overwriting the failed run.

Canary by consequence and prove rollback

Start with bounded users, tenants, workloads and actions whose failures are detectable and reversible. Set traffic, spend, error, latency and safety ceilings plus an expiry. Increase scope only after the cohort meets predeclared gates. Keep high-consequence tools, sensitive data and difficult edge cases out of automatic execution until their own evidence clears.

Before cutover, force rollback in a production-like environment. Verify model routing, prompt and parser compatibility, queued work, idempotency, cache keys, telemetry and state written by the candidate. The old endpoint may disappear at retirement, so define a post-retirement fallback—another qualified model, constrained mode or deterministic workflow—rather than treating the retiring model as a permanent safety net.

Control aliases, fallbacks and partner-hosted divergence

Pin concrete model versions for evaluation and release where supported. If a moving alias is required, continuously record what it resolves to and make resolution changes trigger qualification. Inspect SDK defaults, gateways and orchestration libraries that may substitute a model after an error. Silent fallback can contaminate comparisons and conceal remaining retirement traffic.

Treat the same model family on different clouds or APIs as separate configured candidates until tested. Platform schedule, model revision, region, quotas, safety controls, request fields and surrounding services can differ. Cross-host portability is demonstrated by a dated replay and operational drill, not by a shared marketing name.

Close the migration with negative evidence

After default cutover, query runtime usage and billing for the retiring identifier, inspect failed and queued jobs, rescan repositories and configuration stores, and exercise emergency paths. Require zero unexplained references for a lookback long enough to cover scheduled jobs. Remove obsolete feature flags, credentials, quotas and dashboards only after the rollback window and evidence-retention requirement are satisfied.

Record exceptions with owner, exact scope, compensating control and expiry. Close the program only when the inventory, runtime evidence and deployment state agree. “The main service was changed” is not proof that a grader, batch process, tenant override or stale worker cannot still call the retiring model.

Authorize the bounded production release

Migrate a workload only when its exact candidate clears every mandatory quality, security, data and compatibility gate; the operational and economic delta is accepted; canary ceilings hold; and both pre- and post-retirement rollback paths have been exercised. Constrain the workload when useful behavior passes but a consequential path remains unresolved. Replace or retire it when a non-compensable gate fails or the migration cannot be operated safely before the deadline.

Preserve the source schedule, inventory, configured-system identifiers, case-level results, cost inputs, exceptions, canary evidence, rollback drill and final authorization. Re-evaluate on model, alias, host, prompt, tool, policy, retrieval, region or workload change. This release rule is AccessAllGPT guidance, not a requirement or compatibility promise from OpenAI, Anthropic, Google Cloud or AWS.

Disclosures

AccessAllGPT did not use, test, score or rank a model, provider or cloud platform for this article. OpenAI, Anthropic, Google and AWS documentation is included as labeled vendor evidence; none reviewed or sponsored this work. No vendor supplied data, paid for placement or received an endorsement. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI. Publication-wide relationships are listed on the disclosures page.