Microsoft’s current Foundry model retirement schedule gives Azure OpenAI customers a set of deadlines that now belong on engineering calendars, not just cloud-admin inboxes. Preview chat models in the GPT-5 family are listed for retirement on June 29, 2026, while several widely used GPT-4o and GPT-4.1 versions carry October 2026 retirement dates. For teams with production apps, agents, evaluation pipelines, or customer-facing copilots, the practical question is no longer which model is newest. It is which deployments will keep working after the next platform lifecycle change.
The schedule, published in Microsoft Learn’s Microsoft Foundry model retirement table, lists specific model versions, lifecycle stages, retirement dates, and suggested replacements. The near-term dates are easy to miss because they sit inside a broad catalog that includes OpenAI, Microsoft, Meta, Anthropic, DeepSeek, Mistral, Stability AI, and other provider models sold through Azure. But the deadlines matter most for teams that pinned model IDs months ago and have not treated model lifecycle as part of release management.
The dates that matter first
In the Azure OpenAI section of the Foundry schedule, Microsoft lists gpt-5-chat preview versions from August 7, 2025 and October 3, 2025 with a June 29, 2026 retirement date and gpt-chat-latest as the replacement. The same June 29 date also appears for gpt-5.1-chat and two gpt-5.2-chat preview versions. That is a short runway for any organization that treated preview chat models as stable production dependencies.
The October deadlines are broader. Microsoft lists gpt-4o versions from May 13, 2024, August 6, 2024, and November 20, 2024 for retirement on October 1, 2026, with gpt-5.1 as the replacement. The schedule also lists gpt-4o-mini from July 18, 2024 for October 1 retirement, with gpt-4.1-mini as the replacement. The gpt-4.1, gpt-4.1-mini, and gpt-4.1-nano versions dated April 14, 2025 are listed for retirement on October 14, 2026.
Those dates do not mean every app breaks at midnight in the same way. Microsoft’s Foundry lifecycle policy says automatic upgrades are managed for Standard, Global Standard, and Data Zone Standard deployment types on a rolling, region-by-region basis. Provisioned deployments are different: Microsoft’s policy states that they are not auto-upgraded, leaving provisioned customers responsible for manual migration.
Why auto-upgrade is not a test plan
Automatic upgrades reduce outage risk, but they do not remove product risk. A model replacement can change latency, output style, reasoning behavior, tool-call patterns, refusal behavior, token usage, and cost. In enterprise systems, those changes can leak into support workflows, compliance checks, retrieval quality, structured JSON output, escalation rules, or downstream automations that expect a narrow response format.
Microsoft’s own model documentation shows why teams should test behavior, not just availability. In the Foundry model catalog, gpt-5.1-chat is described as adding built-in reasoning capabilities and no longer supporting parameters such as temperature. That is not a cosmetic change for applications that tune response variability, run deterministic regression tests, or share one client wrapper across chat, reasoning, and agent workloads.
The same catalog notes that gpt-5.1 defaults reasoning_effort to none, meaning teams that expect reasoning behavior may need to pass an explicit reasoning level after migration. A silent replacement can therefore preserve the endpoint while changing how much reasoning the app actually gets, which is exactly the kind of issue that tends to surface after deployment rather than during a dashboard review.
What teams should audit now
The first step is an inventory. Teams should list every Azure OpenAI or Foundry deployment by model name, model version, deployment type, region, owning application, traffic level, and business owner. That sounds basic, but it is often where hidden risk appears: an internal support bot on an old gpt-4o version, a marketing image workflow tied to an older image model, a test environment promoted into production, or an agent workflow that nobody has revisited since launch.
The second step is a migration matrix. For each deployment, teams need the suggested replacement from Microsoft’s schedule, the target region, whether the replacement supports the same API surface, and whether client code needs parameter changes. If a workload uses temperature, tool calling, structured outputs, image inputs, retrieval, function schemas, or custom retry logic, the migration should include test cases for each of those behaviors.
The third step is an evaluation run. That should include golden prompts, production-like retrieval inputs, adversarial or edge-case prompts, structured-output validation, cost and latency measurement, safety-review checks, and side-by-side scoring by the product team that owns the workflow. A replacement model that looks stronger in benchmarks can still be worse for a specific support flow, coding assistant, compliance classifier, or sales-response generator.
Teams using provisioned throughput need a separate plan because Microsoft’s lifecycle policy leaves manual migration with them. That may involve capacity planning, reservation review, load testing, cutover windows, and rollback paths. For regulated environments, it may also require documentation that explains why the replacement model is acceptable, how outputs were tested, and what changed in the control environment.
OpenAI’s own deprecations add another layer
This is not only an Azure issue. OpenAI’s API deprecations page says older GPT Image models, including gpt-image-1-mini, gpt-image-1.5, and chatgpt-image-latest, are scheduled for removal from the API on December 1, 2026, with gpt-image-2 as the recommended replacement. That gives media, commerce, design, and automation teams another migration track if image generation sits inside their product pipeline.
The pattern is becoming clear across AI platforms: model IDs are not permanent infrastructure. They are versioned dependencies with retirement dates, replacement paths, and behavior changes. Teams that already manage operating-system patches, database upgrades, browser compatibility, and package deprecations need to treat AI model selection the same way.
For small prototypes, switching to a newer model may be a quick configuration change. For production systems, it is a release. The safer approach is to put the June 29, October 1, October 14, and December 1 dates into the same planning process as any other dependency deadline, then migrate while there is still time to test what users will actually experience.
