GitHub Copilot Model Deprecations on December 14: A Migration Checklist for Engineering Teams

GitHub announced on November 13, 2026 that six model selections in Copilot will be retired on December 14. This is a compatibility change for teams that rely on a specific model in Chat, inline editing, agent workflows or code completion. It is not evidence that existing source code will stop working. The operational risk is different: developers may find a saved selection unavailable, a repeatable prompt may behave differently, or organization policy may prevent a suggested replacement from appearing. Treat the announcement as a model-configuration migration, not a general emergency patch. Record who owns your Copilot policy and which teams depend on fixed model choices before changing anything.

Map the announced replacements

GitHub lists Claude Fable 5 to Claude Fable 5.2, Claude Haiku 4.5 to Claude Haiku 5.5, Gemini 3.8 Flash to Gemini 4 Hydrogen, Gemini 4 Argon to Gemini 4 Carbon, and Grok 4.6 to Grok 4.7. Kimi K3 has no announced replacement in that notice; its suggested alternative is explicitly still to be announced. The announcement includes an exception: Claude Haiku 4.5 remains available to individual Copilot subscribers on annual plans. Do not interpret that individual-plan exception as an enterprise exemption. Record the precise model and subscription context instead of using a generic instruction to switch everyone to the newest model.

Inventory model-dependent workflows

Start with a short survey of engineering leads, security reviewers and platform administrators. Ask which Copilot client they use, whether a model is explicitly selected, whether a custom prompt or agent depends on it, and what output quality matters. Include code explanation, test generation, migrations, security reviews and support scripts. Look for internal documentation that instructs people to choose an old model. Also inspect shared onboarding guides and screenshots. A model name appearing in documentation is not proof that an API integration uses the same provider endpoint: GitHub Copilot and a direct model API are separate products with separate availability and configuration. Track them separately to avoid changing unrelated production services.

Check enterprise policies before rollout

GitHub says suggested alternatives are automatically enabled under default model enablement for Copilot Business and Enterprise unless an administrator disabled the global default or explicitly disabled a model. An organization with restrictive policies may need to enable replacement models manually. Review the relevant Copilot model settings with an authorized administrator and compare what the policy permits against what each supported client displays. The official supported-models reference cautions that model availability depends on plan and client, so do not assume every model appears in every IDE. Update your IDE and Copilot extension when the desired model is missing, then check the policy again before escalating.

Run a small acceptance test

Select representative tasks from real repositories without sharing confidential credentials or customer data. For each, save the prompt, relevant context, baseline acceptance criteria and human review notes. Run the same task with the approved replacement model and compare compilation, test results, security properties and maintainability. Do not judge solely by how fluent an answer sounds. For a refactoring task, run unit tests and a linter; for a database migration, review rollback and data integrity; for a security fix, verify the threat model. Have a reviewer inspect the diff. Model output is a suggestion until normal engineering controls accept it.

Update runbooks and communicate the cutoff

Publish an internal mapping that distinguishes officially recommended alternatives from locally approved choices. Tell developers where to select a model in their supported Copilot client and how to request a policy change. Update prompt libraries and training materials, then schedule a quick verification before December 14. Keep a fallback task route for teams whose replacement is not yet announced, especially Kimi K3 users. Avoid promising that a replacement reproduces identical output: model behavior and credit usage may vary. The goal is continued service and predictable review, not a byte-for-byte migration.

How to verify the migration succeeded

Ask a developer from each affected team to open their normal Copilot experience, select the approved replacement, run a non-sensitive test prompt and confirm the generated changes pass local checks. Administrators should verify policy visibility for both new and existing users. Record exceptions with a named owner and deadline. After December 14, check onboarding materials and recurring support tickets for references to retired selections. If a model remains unexpectedly visible, consult current GitHub documentation rather than assuming the retirement has been cancelled. A successful migration leaves teams with an approved model, a documented fallback and normal code-review safeguards.

Conclusion

The useful action today is inventory, policy verification and a small controlled comparison. GitHub has supplied a clear retirement date and most suggested alternatives, but availability is still conditional on plan, client and policy. Teams that document these dependencies now can avoid last-minute disruption without making speculative claims about model performance.