Azure OpenAI and Foundry November 2026 Retirement List: Migration Guide for o1, Claude Haiku 4.5, and More

Microsoft's Azure OpenAI and Foundry services are set for a concentrated round of retirements in November 2026, affecting multiple models including o1, o1-pro, codex-mini, and Claude Haiku 4.5. For teams that depend on these models to build production applications, this is more than just a version update—it's an architectural migration that requires advance planning.

Retirement Timeline: Three Waves of Coordinated Shutdowns

According to Microsoft's official announcement, retirements will occur at three points in time, each corresponding to different model categories and impact scopes.

November 15: codex-mini and Claude Haiku 4.5 Retire First

The first wave of retirements occurs on November 15, involving two models: codex-mini and Claude Haiku 4.5. codex-mini is a lightweight model designed for code generation scenarios, while Claude Haiku 4.5 is a fast-response model provided by Anthropic on the Azure platform. The simultaneous retirement of both means teams relying on both code completion and low-latency conversation need to complete their switchover before this date.

Interestingly, the retirement of Claude Haiku 4.5 demonstrates that third-party models on Azure are subject to the same lifecycle management rules—it's not just OpenAI's own models that get phased out.

November 17: Two gpt-chat-latest Preview Versions Go Offline

The second wave occurs on November 17, when two gpt-chat-latest preview models will be retired. Preview models are inherently positioned as temporary and experimental, and Microsoft typically sets shorter lifespans for them. If production environments are still calling endpoints with the preview identifier, these should be prioritized for investigation.

November 19: Large-Scale Retirement of the o Series

The third and most impactful wave comes on November 19, when o1, o1-pro, and five other o-series models will be retired together. The o1 series is the core product line of OpenAI's reasoning models, with o1-pro being the enhanced version for high-complexity reasoning tasks. Retiring seven o-series models at once will have the most direct impact on applications using reasoning models for agents, complex analysis, or mathematical reasoning.

Auto-Upgrade Rules: Not All Deployments Will Be "Migrated"

Microsoft's approach to model retirement is not one-size-fits-all. Some deployments have auto-upgrade rules configured, which will automatically route traffic to the recommended replacement model after the retirement date. However, other deployments—especially those with pinned versions—will not be automatically migrated and will fail on calls after retirement.

This means teams need to proactively check the upgrade strategy for each deployment. If a pinned version was selected during deployment to ensure output stability, then this time you must manually specify a replacement model and redeploy. While auto-upgrade saves effort, it may also introduce changes in output behavior that need to be validated in a test environment first.

Auto-upgrade is a lifecycle management option in Azure OpenAI deployment configuration. When the base model is marked for retirement, if the deployment has auto-upgrade enabled, the platform will automatically point the deployment to Microsoft's recommended replacement model after the retirement takes effect, without requiring users to manually rebuild the deployment. In contrast, pinned version deployments explicitly lock a specific model version to ensure stable output behavior; these deployments receive no automatic migration after model retirement, and call requests will directly return a model-unavailable error. While auto-upgrade reduces the risk of operational disruption, because replacement models may differ in training data, alignment strategies, and inference characteristics, output style, format compliance, and even token consumption may change. Therefore, for production environments, it's generally recommended to validate in a pre-release deployment first before deciding whether to enable auto-upgrade.

Replacement Models and Pricing Considerations

Microsoft provides recommended replacements for each retired model. Replacements for the o1 series typically point to newer versions of reasoning models, while the replacement for codex-mini may fall on other code-specialized models. When migrating, don't just look at the name correspondence between models—also pay attention to three practical factors:

Input/output price differences. Different generations of models have different pricing structures, especially reasoning models. The high inference cost of o1-pro may change with replacement models, requiring recalculation of per-call costs.

Context window and output limits. The context length and maximum output tokens of replacement models may differ from the original, affecting long document processing and prompt design for complex agents.

Latency and throughput characteristics. The latency profiles of reasoning models and fast-response models differ significantly. After replacement, you need to re-evaluate whether end-to-end response times meet your SLAs.

Azure OpenAI model deployments are typically bound to API version numbers, with call endpoints in the form /openai/deployments/{deployment-name}/chat/completions?api-version=.... When migrating to a replacement model, you not only need to replace the deployment name but may also need to upgrade the API version to support the new model's parameter features (such as new reasoning parameters or structured output formats). Additionally, deployment names and model names are decoupled in Azure: a deployment name can point to a different base model when rebuilt, which makes it possible to "keep application-side identifiers unchanged while only switching the backend model"—provided the team hasn't hardcoded model names into business logic at the application layer.

Deployment Changes: Practical Migration Considerations

From an engineering perspective, this retirement involves more than just changing a model name. Deployment changes typically include: updating model deployment configurations, adjusting API version numbers, modifying model identifiers in applications, and re-running regression tests. If the application uses model routing or fallback logic, the model mappings in the routing table also need updating.

For systems with multi-model orchestration, it's recommended to centralize model identifiers in configuration rather than scattering them throughout the code. This way, the scope of changes is manageable when the next model lifecycle change occurs.

What Teams Should Do Now

There's still some time before November, but the migration window isn't generous. It's recommended to proceed in the following priority order: first, inventory all Azure OpenAI and Foundry deployments and flag endpoints using retired models; then conduct compatibility testing against official replacement recommendations; finally, after validating output quality and cost changes in a test environment, schedule production switchover. For pinned-version deployments, be sure to complete manual migration before the retirement date to avoid service disruption.

Model retirement is a normal part of cloud platform AI services. Incorporating model version management into daily operations processes is more cost-effective than reacting passively each time.

Background Supplement

Reasoning models differ fundamentally from traditional chat completion models in their invocation mechanisms. The o1 series first generates a segment of hidden "reasoning tokens" before producing the final answer; the model completes problem decomposition and self-verification through chain-of-thought, resulting in higher latency per call and more billed tokens. These models are suitable for tasks requiring deep reasoning, such as mathematical proofs, complex code refactoring, and multi-step agent planning, but are not economical for low-latency chat scenarios. When migrating to next-generation reasoning models, beyond checking whether reasoning token billing methods have changed, also note that some new models may introduce adjustable parameters such as reasoning effort, and whether they support streaming output of the reasoning process—all of which affect the design of existing prompts and timeout settings.