Phi Model Deprecation and Version History on Azure AI

Azure AI Foundry retires models on a published schedule, and the Phi family is in it. This page tells you where that schedule is and how to read your own deployment’s date off the platform — and deliberately does not reprint the dates.

Why the dates are not on this page

Microsoft maintains retirement dates for Foundry models in a live documentation table, and that table is revised: dates are extended, models are added, and the deprecation of one version is announced months before it takes effect. A copy of it in a third-party article is accurate on the day it is written and misleading afterwards, in a way the reader cannot detect — the page looks just as authoritative when it is wrong.

So the authoritative source is Microsoft Learn’s model lifecycle and retirement page for Azure AI Foundry, which carries the current table for every model family including Phi. Check it there, and check it again before each release rather than trusting a number you wrote down. What this page can usefully give you is the mechanism behind that table, which does not move.

The lifecycle states

A model on Foundry moves through a documented sequence, and each transition means something different for you:

• Preview. Available, not covered by the same service-level commitments, and able to change or be withdrawn with shorter notice. Do not build a production dependency on a preview version without a plan for it disappearing.
• Generally available. The normal state. New deployments allowed, full support.
• Legacy or deprecated. The model still serves existing traffic, but new deployments are restricted or blocked and a retirement date has been announced. This is the window in which you migrate, and it is the state most teams discover only when they try to deploy the model in a new environment and cannot.
• Retired. The endpoint stops serving. Requests to it fail. There is no grace period after this point.

The state that catches people is the third one, because nothing about it is visible from a running application. Traffic continues to work perfectly while the clock runs down, and the first symptom is a failed deployment in a new region or a new subscription — often at exactly the moment you are least able to absorb a model change.

Reading the date for a deployment you own

Do not rely on inventory kept by hand. Both the portal and the API expose the lifecycle status of a deployed model, so this can be a scheduled check rather than a habit:

• The Foundry portal. The model catalogue entry and the deployment’s own detail pane show the version, its status and the retirement date where one is set.
• The management API. Listing deployments for an account returns each deployment’s model name, version and lifecycle metadata. That is the form to automate — a job that lists every deployment across every subscription weekly and alerts on anything not generally available.
• The version string itself. A pinned version is what gets retired. A deployment configured to auto-update to the default version will move underneath you instead, which avoids the outage and replaces it with a silent behaviour change. Neither is free; choose which failure you prefer per workload rather than by default.

What a Phi version string is telling you

Retirement notices are written against version strings, so it is worth being able to read one. A Phi deployment name carries several independent pieces of information that people routinely collapse into “we use Phi”:

• The generation. Phi-3, Phi-3.5, Phi-4. Different training runs, different chat templates in some cases, and different tokenizers between Phi-3-mini and Phi-4. Not a drop-in swap.
• The size. mini, small, medium, or a parameter count. This changes the base context length and, across the Phi-3 line, the vocabulary.
• The context configuration. Where a name carries 4k, 8k or 128k, it is naming a distinct checkpoint rather than a setting. See the Phi-3 context window table.
• The tuning. instruct, vision, multimodal, reasoning. A retirement of one does not imply retirement of the others.

Each combination is a separately deployable, separately retirable thing. That is why an inventory of “which models do we use” that stops at the family name cannot answer the question a retirement notice asks. Store the full string, including the version suffix, per deployment and per environment.

What retirement means for open weights

This is where Phi differs from a closed model, and it is the single most useful thing on this page. Phi checkpoints are published under MIT on Hugging Face — see what the MIT terms permit. An Azure retirement withdraws a managed endpoint. It does not and cannot withdraw the licence you already have to the weights.

So your migration options are wider than they are for a proprietary model. You can move to a newer Phi version on Foundry, or you can keep the exact model by serving the same checkpoint yourself and changing only the base URL. The behaviour of your application does not change at all in the second case, which turns a forced upgrade into a scheduling decision.

It changes the shape of the deadline as well. For a proprietary model, the retirement date is the date your application must have been migrated and revalidated — every prompt re-tested against different weights, every eval re-run, every regression found and fixed. For an open-weight model you can decouple the two: move the serving before the deadline, keeping the model identical, and do the upgrade to a newer Phi on your own schedule as an ordinary piece of work rather than under a countdown.

The caveat is that this only works if you still have the weights. Microsoft is under no obligation to keep a Hugging Face repository published, and repositories across the ecosystem have been renamed, gated and removed. If a specific Phi checkpoint is load-bearing, mirror it to storage you control now, while it is still there.

Surviving a retirement you did not plan for

1. Inventory what you call. Every model name and version string that appears in a request, across every environment. If this is not in one place, that is the first bug.
2. Watch the table on a schedule. A quarterly calendar entry to reread the Microsoft Learn retirement page beats an alert you will not have configured.
3. Mirror the checkpoints. Pull the exact commit of anything you depend on into your own storage. The procedure is in pinning a Phi checkpoint on Hugging Face.
4. Keep the model name out of your code. Configuration rather than a literal, so that switching version or provider is a deployment and not a release.
5. Have a tested fallback route. Untested fallback is not fallback. Exercise it deliberately, on a schedule, before you need it.