Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
A newer model isn't automatically a better model. In an orchestration platform, instruction following, tool selection, and latency matter more than raw capability. A model that leads public benchmarks might still perform poorly on those measures.
Two events put a model change on the table, and they demand different responses:
| Model lifecycle event | What it means |
|---|---|
| New model release | New models can become available in preview or generally available. Evaluate relevant models as they become available to understand their quality, instruction following, latency, reliability, and consumption characteristics before a migration is required. |
| Model retirement | Retirements occur less frequently, but they are more disruptive because affected agents must move to a supported replacement within a defined timeline. Teams need to identify affected agents, contact owners, complete testing, remediate regressions, and deploy the replacement. |
Important
Don't wait for a retirement announcement to begin model lifecycle planning. Teams that maintain an inventory, a reusable evaluation baseline, and current test results can begin a retirement migration with evidence about the replacement model, instead of starting their analysis after the retirement is announced.
Confirm the prerequisites
Check the following prerequisites before you invest in evaluating a candidate model. Most apply to every model. Two are conditional and only need checking when the candidate falls into the relevant class. If a prerequisite that applies to your candidate fails, don't upgrade to it. Learn more in Understand the AI model landscape.
| Prerequisite | Applies to | How to check it |
|---|---|---|
| The model is generally available or the default | All models | Check the model's release tag. |
| The model is available in your region | All models | Check your region's entry, not just the model name. Some models are limited to early access environments. |
| The use category fits the agent's purpose | All models | Match the deep, auto, or general tag to what the agent does, not to which model scores highest. |
| The safety posture is acceptable | All models | Review the published safety and responsible AI evaluation findings for the model. A model flagged as less aligned isn't a production candidate regardless of capability. |
| The cross-geo posture is acceptable | Conditional: any model tagged cross-geo in your region, including generally available models | Obtain compliance approval before migrating. Enabling Move data across regions can't be reversed retroactively for data already processed, and regulated workloads might not permit it at all. |
| The administrator has enabled the model class | Conditional: preview, experimental, and external models | Confirm the required setting is on in the target environment. An internal generally available model that isn't tagged cross-geo in your region needs no extra enablement. |
Good reasons to upgrade
- The current model is retiring. This reason is mandatory and timeline-driven.
- The default model changes and the agent uses the default. The model changes whether you plan for it or not, so validate the result.
- A documented production gap evidenced by monitoring, such as instruction-following failures, poor tool selection, weak grounding, unacceptable latency, or high consumption.
- A capability the agent needs becomes available, such as stronger multistep tool orchestration for an agent that chains several tools.
- A faster or less expensive model now meets your quality bar at lower credit consumption.
- A regional or compliance improvement, such as a model becoming available in-region and removing a cross-geo dependency.
Poor reasons to upgrade
- The model is the newest one available. Public benchmarks don't measure your instructions, your tools, or your knowledge sources.
- The model scored higher on a leaderboard. Aggregate benchmark scores say nothing about instruction adherence or tool restraint inside your agent.
- Another team's agent improved with it. Different instructions and different tools produce a different result.
- The team wants a reasoning model. Deep models add latency and cost that most conversational agents don't need.
- To fix a problem that is actually an instruction, knowledge, or tool description problem. Diagnose first. A model swap doesn't fix a poorly scoped knowledge source or a vague tool description, and it adds new risk on top of the existing one.
Review model-specific upgrade guidance
When a new model behaves materially differently from the model it replaces, the model provider usually publishes model-specific upgrade guidance. This guidance describes the behavior changes that most often affect existing applications and the prompt changes that address them. Review it before you evaluate a new model in Copilot Studio, and use it to plan the changes an agent needs.
Model upgrade guidance commonly covers:
- Instruction following: Newer models often follow instructions more literally. Instructions that relied on a previous model inferring intent might need to state the required behavior explicitly.
- Tool and action selection: Changes in how a model decides to call tools, how many tools it calls, and how it uses tool descriptions and parameter definitions.
- Response formatting and length: Differences in default verbosity, structure, and formatting that affect the user experience and downstream processing.
- Reasoning and planning behavior: Differences in how the model decomposes multistep tasks, which affect agents that orchestrate several tools or knowledge sources.
- Prompt patterns to remove: Workarounds added for a previous model's limitations can degrade results on a newer model.
Translate the applicable recommendations into the agent artifacts you control in Copilot Studio. Learn more in Update the agent artifacts a model change affects.
The following examples show the kind of guidance model providers publish. Not all recommendations apply to Copilot Studio, because Copilot Studio manages the model invocation and doesn't expose every model parameter. Focus on the instruction, tool-description, and behavior guidance.
| Example guidance | Learnings |
|---|---|
| Claude prompting best practices | Be explicit about the required behavior and output, add context that explains why a behavior matters, and remove prompt workarounds written for earlier models. |
| GPT-5 prompting guide | Resolve conflicting or ambiguous instructions, calibrate how much independent action the model should take, and tune tool descriptions and response verbosity. |
Respond to a model retirement
A retirement is the one lifecycle event with a deadline attached, so the work that's specific to it happens before the migration itself starts:
- Confirm the affected model, replacement, regional scope, and retirement timeline in the list of publicly available models.
- Identify the affected agents and environments.
- Contact the business and technical owners, and explain the retirement deadline, the replacement model, and the evaluation work required.
- Prioritize agents by business criticality, user impact, and time remaining before retirement.
From there, each affected agent follows the same migration path as a proactive upgrade. Learn more in Run and validate a model migration.
Track each affected agent through evaluation, remediation, approval, deployment, and post-migration monitoring, so that migration status is visible across the estate rather than tracked by individual owners.
Use the retired-model window as temporary migration time
Copilot Studio can let an agent continue using a retired primary model for 30 days after an automatic upgrade. Go to the agent's Settings page and turn on Continue using retired models in the Model section when the additional compatibility period is required.
After the setting is on, you can switch between the retired model and the upgraded model at any time during the 30-day period, and the preference applies to future model upgrades until you turn the setting off.
Important
The 30-day retired-model option is a temporary compatibility window, not a long-term migration strategy. Complete evaluation and migration before the window ends.
Track use of the setting in the migration plan, including which agents use it, who approved it, when the extension ends, and the remaining actions. The setting is configured individually on each agent, so organizations with many affected agents should account for the time and ownership required to apply and track it.
Next step
When you're ready to upgrade, follow the migration process to evaluate the candidate model, fix regressions, and deploy the change.