Vertex AI and Azure retirements, Nov 2026 to Apr 2027: one table

Two clouds, two calendars

A model id on a cloud is not the vendor's model. Azure Foundry keeps its own lifecycle, retirement dates and replacements, and says so: the replacement column is Microsoft's recommended target and, where supported, the one used for automatic upgrades.¹ Google's lifecycle page now sits under the Gemini Enterprise Agent Platform name in its docs.² If your tracker is keyed on the vendor's announcement, it will miss the date your own deployment actually stops.

One example: the vendor-side shutdown of GPT-4o is covered in GPT-4o and GPT-4.1 shut down 14 January 2027. On Azure, the gpt-4o 2024-05-13 version retires on 2026-12-09, and later versions on 2027-04-14.¹ Same family, different dates.

The dated table

Dates below are from Microsoft's schedule page, last updated 2026-09-23. Re-check before acting. "Days left" counts from 2026-10-27.

The Gemini row is blank on purpose. The Google Cloud pages I could read returned navigation, not dates. The Gemini API's own page shows gemini-3.6-flash released 2026-07-21 with "No shutdown date announced", and says gemini-3.5-flash's endpoint routes automatically to 3.6 Flash.³ That is the Gemini API, not Vertex, so do not copy it into a Vertex row. Read the Vertex page directly and fill the cell with a date you can cite.

Other nearby dates on the same Azure page: Llama-4-Scout 2027-01-31 and gpt-4.1 2027-04-14.¹

Map cloud ids to one owner and one replacement

Key the registry on the cloud-specific id, because that is what your code sends and what the cloud retires. Add the version and deployment type, since the same id can behave differently by deployment type.

- cloud: azure
  id: o3
  version: "2025-04-16"
  deployment_type: global-standard
  retires: 2026-11-19
  owner: team-support-bot
  replacement: gpt-5.6-sol
  evaluate_by: 2026-11-05
  source: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/model-retirement-schedule
- cloud: vertex
  id: gemini-3.6-flash
  retires: unconfirmed
  owner: team-search
  replacement: unconfirmed
  evaluate_by: null

Three rules keep the table honest:

• One owner per row, a team that can approve a change, not a mailing list.
• One replacement per row, chosen by your evaluation. Microsoft says to compare quality, latency and cost on your own application and data before picking.⁴
• A source URL per row, so a stale date is visible.

Azure behaviour to plan around

Retired means every inference request returns 410 Gone.⁴ For Global Standard, Data Zone Standard and Standard deployments, Microsoft schedules automatic upgrades region by region. Provisioned deployments are not auto-upgraded and must be migrated manually.⁴ So a row with a replacement can still need work if you run provisioned throughput, and an auto-upgrade changes the model behind your id without a code change.

Notices go to subscription owners with active deployments, at least 60 days before retirement for GA models, and appear in Azure Service Health.⁴ Those owners may not be the application's owner, so route the alert to the team in your registry. You can also read lifecycleStatus, deprecation.inference and per-SKU deprecationDate from the Models API (subscription-scoped, per region) and diff them against your file nightly.⁴

Fine-tuned models retire separately. For example, fine-tuned gpt-4o 2024-08-06 deployments retire 2027-10-01.¹

Cross-checking the registry against vendor dates

INFRO sits between your application and the provider accounts you already pay.⁵ Its model retirements capability records each vendor's deprecations and shutdown dates, warns organizations still sending a retiring model, and from the shutdown date refuses it before any provider call, naming the replacement. Those are vendor dates. Keep the Azure and Vertex dates in your own registry and compare the two, so a cloud date that falls earlier than the vendor's is caught.