Microsoft Foundry details six-phase process for migrating LLM models

Microsoft Foundry has published a six-phase process for moving LLM-powered applications from one model generation to another, aimed at model retirements built into the platform's lifecycle. Generally available models typically ship with a retirement date about 18 months out. The model lifecycle schedule lists gpt-4o (2024-05-13) for retirement on October 1, 2026, with gpt-5.1 as its suggested replacement.

A model swap is deceptively small. Changing the model name in code is one line; everything underneath is not. A replacement can shift response formatting, make summaries longer and more hedged, drop JSON fields, or reorder tool calls while nothing crashes and error rates stay flat. Users notice before the systems do.

The six phases

The process runs Discover → Assess → Adapt → Validate → Roll out → Retire, with Foundry tools mapped onto each stage:

• Discover: retirement schedule and Models API
• Assess: leaderboards and side-by-side comparison
• Adapt: Prompt Optimizer, agent optimization, simulator
• Validate: Azure AI Evaluation SDK's 30-plus evaluators
• Roll out: automatic upgrade controls and continuous evaluation
• Retire: Models API check for 410 Gone plus observability dashboards

Deployment mechanics

Capacity choice determines migration mechanics. Standard, Global Standard, and Data Zone Standard deployments auto-upgrade on a rolling regional schedule unless NoAutoUpgrade is set, in which case the deployment stops working at retirement. Provisioned deployments migrate manually, either in place over a 20-to-30-minute traffic transition or side by side.

Replacement models typically arrive in Global Standard about 90 days before retirement, in provisioned regions about 30 days out, and in standard regions roughly two weeks out. Fine-tuned deployments get no automatic upgrade and are out of scope: the Adapt phase becomes a retraining or distillation exercise rather than prompt work.

Tooling limits

Prompt Optimizer rewrites instruction text but does not tune tool definitions or output schemas, and it has no version history. There is no "optimize for target model X" flow; moving between model families still requires deliberate manual translation. Most teams do not have an evaluation suite, and regulated workloads can stall in Validate under mandatory human review.

Worked example

The worked example uses a fictional retailer, Zava, whose shopping assistant runs two LLM stages. Against gpt-5.4 nano, the team found hedged summaries that could contradict review evidence, fluctuating attribute counts in its insight extraction, and variable latency on the synchronous product-page path. A canary rollout exposed latency regressions that offline evaluation had missed, so Zava rolled the synchronous path back to gpt-4o mini while keeping the offline pregeneration path on the new model. The migration ends in a split state, with the old deployment still warm for rollback and the synchronous path back in Adapt.

Retire can lag

Model migration is not a binary switch. The Retire phase can lag Roll out by weeks or months, and teams should design for workloads that run on two models at once rather than assume a clean cutover.