Your Copilot Model Migration Needs a Rehearsal, Not a New Dropdown

A developer outlines a rehearsal procedure for teams facing GitHub Copilot model deprecations scheduled for October 19, 2026 across chat, inline edits, ask and agent modes, and completions. The approach holds repository revision, committed instructions, permitted tools and required checks fixed, then runs the same small task under the old and new model choices and records acceptance conditions, diffs and pass/fail results. The author stresses that a suggested replacement in the picker does not guarantee prompts, integrations, costs or outputs behave the same, and that organization policy may block an alternative.

A model selector can show a suggested replacement while your team's pinned workflow still names the old model. The picker changed; the workflow may not have. Rerun a real task before signing off. GitHub's Copilot changelog schedules selected model deprecations for October 19, 2026, across Copilot chat, inline edits, ask and agent modes, and completions. It lists suggested alternatives and calls out model availability for Business and Enterprise organizations: default enablement can apply, but an admin or global policy can disable an alternative. This is a Copilot-specific notice, not a retirement announcement for those models everywhere. Nor is a suggested alternative a promise that your prompts, integrations, costs, or outputs will behave the same way. GitHub also argues that repository instructions, skills, and hooks can stay with a workflow even when the model changes. That's a design argument, not evidence that a particular switch is safe. For a rehearsal, hold that context fixed and see what the new choice does. Start where your team actually selects a model: individual Copilot settings, organization policy, and any workflow or integration that names one. Record the existing choice, its owner, and where it is configured. Before planning a run, check which alternative your organization allows. A teammate's model picker doesn't tell you what your own policy permits. If you don't have permission to inspect an organization setting, ask the admin to confirm it. Don't infer that a changed picker updated every pinned choice. The changelog tells you what GitHub plans to remove; it doesn't audit your setup for you. Pick a small task you know how to inspect, such as adding an error state to a form. This is a proposed test, not a report of one I ran. Write down the acceptance conditions before changing the model: the error appears on failed submission, focus reaches the error message, the success path still works, and your project's required checks run. Use the same repository revision, committed instructions, permitted tools, and required checks for both runs. Work in separate branches or clean worktrees so the first run cannot leak changes into the second. If the old option is still available under your policy, run the task once with each choice. If it is not, use a saved baseline diff and check output, and label the comparison accordingly. A historical result is not a controlled head-to-head run. A simple record is enough: Task: add form submission error state Repo revision / instructions: <record the same values for each run Model choice / policy: <record the configured choice and whether it was allowed Permissions: <record allowed tools and approvals Checks: <required checks and actual pass / fail / not-run results Review: <diff, behavior check, unresolved issues, reviewer decision Those are fields to fill in, not a sample result. Review the diff against the acceptance conditions. Run the real test and build commands your repository requires; inspect the form behavior and focus path if those are part of the task. Keep not run distinct from pass . A convincing explanation in the agent transcript does not turn an unrun check green. If policy blocks the alternative, pause the pinned workflow and ask for an authorized choice rather than routing around the setting. If the output misses the error state, changes unrelated files, or leaves a required check failing, the model's availability is beside the point. Rework the task, review the new diff, and run the checks again. If you cannot run them, keep a manual path for the work until you can verify it. This rehearsal doesn't measure general model quality. One task can expose a local incompatibility or give you enough evidence to approve that particular workflow; it cannot guarantee equivalent latency, cost, or behavior for every task. Repeat the exercise for materially different pinned workflows rather than treating one green run as a blanket approval. I'd keep the task, the fixed context, the actual check output, and the review decision together. Otherwise the team has a new model name in settings and no record of what that change did to the work.