GPT-4o Retires October 1, 2026: Move Microsoft Foundry Apps to GPT-5.1

Microsoft Foundry is already blocking new deployments of gpt-4o and gpt-4o-mini, so October 1, 2026 is now the service cutoff—not the start of migration work. Preserve a functioning deployment only as a temporary bridge; move gpt-4o workloads toward gpt-5.1, and treat Microsoft’s suggested gpt-4.1-mini replacement for gpt-4o-mini with caution because it retires on October 14, just 13 days later.
Microsoft’s current retirement schedule marks gpt-4o versions 2024-05-13, 2024-08-06, and 2024-11-20 for retirement on October 1, with gpt-5.1 listed as the replacement. The same date applies to gpt-4o-mini version 2024-07-18, for which Microsoft lists gpt-4.1-mini.
The timetable understates the immediate operational risk. Microsoft Q&A reports from June 29 and June 30 document new deployment attempts failing with ServiceModelDeprecating, including attempts involving gpt-4o version 2024-11-20 and gpt-4o-mini version 2024-07-18. Existing deployments can continue serving inference during deprecation, but teams that delete one, need another region, or try to recreate an environment may discover that their apparent October runway has already disappeared.

Inventory Every Deployment Before Changing Anything​

The first job is not model selection. It is finding every deployment, including forgotten development subscriptions, disaster-recovery resources, proof-of-concept accounts, and production services whose deployment names do not contain “gpt-4o.”
Administrators can inspect an individual Azure OpenAI account with the Azure CLI:

az cognitiveservices account deployment list \
  --resource-group <resource-group> \
  --name <account-name> \
  --output table

For a subscription-wide inventory, first select the subscription and list relevant Cognitive Services accounts:

az account set --subscription <subscription-id>

az cognitiveservices account list \
  --query "[?kind=='OpenAI'].{Name:name,ResourceGroup:resourceGroup,Location:location}" \
  --output table

Then enumerate the deployments in each returned account:

az cognitiveservices account deployment list \
  --resource-group <resource-group> \
  --name <account-name> \
  --query "[].{Deployment:name,Model:properties.model.name,Version:properties.model.version}" \
  --output table

Windows administrators can turn that into a PowerShell inventory across every accessible subscription:

$subscriptions = az account list --query "[].id" -o tsv

foreach ($subscription in $subscriptions) {
    az account set --subscription $subscription

    $accounts = az cognitiveservices account list `
        --query "[?kind=='OpenAI'].[name,resourceGroup,location]" `
        -o tsv

    foreach ($account in $accounts) {
        $name, $resourceGroup, $location = $account -split "`t"

        az cognitiveservices account deployment list `
            --name $name `
            --resource-group $resourceGroup `
            --query "[?properties.model.name=='gpt-4o' || properties.model.name=='gpt-4o-mini'].{Subscription:'$subscription',Account:'$name',ResourceGroup:'$resourceGroup',Location:'$location',Deployment:name,Model:properties.model.name,Version:properties.model.version}" `
            -o table
    }
}

Export the underlying JSON or CSV if the estate is large. For each match, record the subscription, resource group, Azure OpenAI account, region, deployment name, model version, deployment type, consuming applications, authentication method, quota dependency, and business owner.
That last field matters. An orphaned deployment may still be receiving traffic through an application setting, Azure Key Vault secret, App Service configuration, Azure Functions environment variable, or CI/CD pipeline. A resource inventory without a dependency map can identify what will retire while still missing what will break.

---

Existing Deployments Are Bridges, Not Spare Capacity​

Microsoft Foundry’s lifecycle distinction now determines the available choices. A deprecated model can be unavailable for new deployments while existing deployments continue operating; once retired, it stops serving inference.
That makes a healthy existing deployment valuable, but also fragile. Do not delete it merely to clean up naming, rebuild infrastructure, change deployment topology, or test whether an Infrastructure-as-Code pipeline can reproduce it. A successful deployment created months ago does not prove that the same template will succeed today.
Preserving an existing deployment temporarily is reasonable when it supports production traffic and its replacement has not passed validation. The temporary strategy should include four controls:

• Freeze destructive deployment changes unless a tested replacement is ready.
• Confirm that applications refer to a configurable deployment name rather than embedding it throughout source code.
• Monitor errors, latency, and capacity separately from the replacement deployment.
• Establish an internal migration deadline well before October 1.

This is not a resilience plan by itself. If a team cannot create the model again, rebuilding in another account or region may not be available as an emergency response. The deployment still serving traffic is therefore a shrinking asset, not recoverable spare capacity.
Reported deployment blocks have included US-region attempts, but the supplied evidence does not establish a complete authoritative region-by-region matrix. Administrators should test availability in the exact subscriptions, deployment types, and regions they intend to use rather than treating a portal catalog entry as proof that creation will succeed.

GPT-4o Has the Cleaner Migration Path​

For all three affected gpt-4o versions—2024-05-13, 2024-08-06, and 2024-11-20—Microsoft’s current schedule points to gpt-5.1. That does not make the transition automatic or behaviorally transparent, but it provides a destination that is not facing the same October deadline described for gpt-4.1-mini.
Create the gpt-5.1 deployment alongside the existing deployment wherever quota and availability permit. Give it a new deployment name rather than replacing the old endpoint immediately, then route controlled test traffic to it.
Validation should cover the application contract, not just whether a sample prompt returns text. Compare request compatibility, response parsing, structured-output behavior, tool calls, token handling, safety behavior, latency, throughput, and failure responses. Workloads using deterministic checks, strict JSON schemas, retrieval augmentation, or chained prompts need representative end-to-end tests because a response that looks better to a human can still break automation.
Build a benchmark set from real, sanitized production cases. Record pass criteria before running it so that the team does not redefine success around whichever model happens to perform better.
A staged cutover can then move from test traffic to a limited production cohort and finally to the default route. Keep rollback simple: application configuration should be able to point back to the surviving gpt-4o deployment without rebuilding it.
Quota deserves its own checkpoint. A replacement model visible in Foundry is not useful if the target subscription and region cannot support the required deployment. Confirm deployability and sufficient capacity before scheduling the application change.

GPT-4o-Mini’s Suggested Replacement Creates a Trap​

The gpt-4o-mini decision is more complicated. Microsoft lists gpt-4.1-mini as the replacement for version 2024-07-18, but the same retirement schedule says gpt-4.1-mini retires on October 14, 2026.
A literal migration therefore buys only 13 additional days beyond the October 1 retirement of gpt-4o-mini. Worse, Microsoft Q&A reports indicate that attempts to create some replacement deployments have also encountered ServiceModelDeprecating, meaning the documented replacement may not be deployable in every intended situation.
Moving to gpt-4.1-mini can still make sense as a tactical bridge if the deployment already exists, the workload must leave gpt-4o-mini quickly, and the team has a separately approved long-term destination. It is a poor default when the organization would need to perform a full validation, production cutover, and then repeat the exercise less than two weeks later.
The better planning question is not simply, “What model does Microsoft list?” It is whether the listed model provides enough supported lifetime to justify the engineering work. If the answer is no, test the longer-term candidate directly rather than spending the remaining summer creating two successive migration projects.
This compressed lifecycle fits a wider pattern of AI platform turnover. WindowsForum has also covered the July 30 retirement of GitHub Models and the need for teams to separate short-term service continuity from durable architecture. The practical lesson is the same: model names and deployment targets must be treated as configuration, with repeatable evaluation and cutover processes, rather than permanent application assumptions.

---

A Migration Must Be Reversible Before It Is Fast​

The safest plan runs old and new deployments in parallel. Avoid an in-place change that destroys the known-good route before the replacement has handled representative production traffic.
Use four explicit gates:

1. Confirm that the replacement can actually be deployed in the required subscription, region, and deployment type.
2. Verify API and SDK compatibility, including schemas, tool integration, authentication, timeouts, and error handling.
3. Benchmark quality, latency, throughput, and operational behavior against agreed acceptance criteria.
4. Shift traffic gradually while retaining a configuration-based rollback to the existing deployment.

After cutover, leave the old deployment intact long enough to observe real workload patterns, but do not confuse rollback availability with permission to delay. The old deployment’s final boundary remains October 1.
Administrators should also rehearse the retirement failure path. Confirm that alerts will fire when inference stops, identify which applications retry indefinitely, and ensure failures do not cascade through queues, scheduled tasks, or user-facing services. Microsoft’s lifecycle documentation makes the end state clear: retirement means the model no longer serves inference.
The immediate deadline is therefore the date on which a team still has enough time to deploy, validate, and roll back—not October 1 itself. For gpt-4o, that means beginning the gpt-5.1 path now; for gpt-4o-mini, it means refusing to mistake gpt-4.1-mini for a durable destination without accounting for its October 14 retirement.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Model retirement schedule - Microsoft Foundry | Microsoft Learn

   Retirement dates and replacement models for all models available through Microsoft Foundry.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   GitHub Models Retired July 30, 2026: What Windows Teams Must Migrate Fast | Windows Forum

   GitHub announced on July 1, 2026, that GitHub Models will be fully retired for all customers on July 30, 2026, removing the playground, model catalog...

   windowsforum.com