GitHub Copilot stellt sechs Modelle ab: So migrieren Unternehmen ihre Workflows

Seit dem 1. September 2026 sind sechs bisher verfügbare Modelle in den meisten GitHub-Copilot-Erlebnissen abgekündigt. Betroffen sind nicht nur manuelle Chats: GitHub nennt ausdrücklich Copilot Chat, Inline Edits, Ask- und Agent-Modi sowie Code Completions. Für Unternehmen ist das daher keine reine Aufräumaktion im Modellmenü. Feste Modellnamen können in Teamvorgaben, gespeicherten Arbeitsabläufen, Agentenkonfigurationen und Schulungsunterlagen stecken. Wer lediglich ein neues Standardmodell freischaltet, riskiert stille Verhaltensänderungen, blockierte Abläufe oder unerwartete Kosten.

Welche Modelle betroffen sind und welche Alternativen GitHub nennt

Bestätigt ist folgende Zuordnung aus der offiziellen GitHub-Mitteilung. Sie dokumentiert die von GitHub vorgeschlagenen Ziele, beweist aber nicht, dass ein Ersatzmodell bei Qualität, Geschwindigkeit, Preis oder Datenverarbeitung identisch arbeitet. Diese Eigenschaften müssen Unternehmen mit ihren eigenen Aufgaben überprüfen.

• Gemini 3.1 Pro → Gemini 3.7 Flash
• Claude Opus 4.5 → Claude Opus 4.7, Claude Opus 4.8 oder Claude Opus 5
• Claude Opus 4.6 → Claude Opus 4.7, Claude Opus 4.8 oder Claude Opus 5
• Claude Sonnet 4.5 → Claude Sonnet 5
• Claude Sonnet 4.6 → Claude Sonnet 5
• Raptor Mini → MAI-Code-1.1-Flash

GitHub erklärt außerdem, dass Claude Sonnet 4.6 für einzelne Copilot-Abonnenten mit Jahresplan vorerst verfügbar bleibt. Das ist keine allgemeine Ausnahme für Unternehmensumgebungen. Ebenfalls bestätigt: Zum Entfernen der abgekündigten Modelle ist keine Aktion nötig. Handlungsbedarf besteht bei den Workflows und Integrationen, die ein betroffenes Modell voraussetzen, sowie gegebenenfalls bei den Richtlinien für das Ersatzmodell.

Wo die eigentlichen Migrationsrisiken liegen

Aus den Produktangaben folgt eine praktische Risikoeinschätzung: Je stärker ein Ablauf auf reproduzierbares Modellverhalten angewiesen ist, desto höher ist sein Migrationsaufwand. Ein Entwickler kann im Chat sichtbar ein anderes Modell wählen. Ein Hintergrundagent, ein standardisierter Review-Prompt oder ein dokumentierter Supportprozess kann dagegen unbemerkt mit falschen Annahmen weiterlaufen. Besonders kritisch sind schreibende Agenten, sicherheitsrelevante Prüfungen und Prozesse, deren Ergebnis ohne unabhängige Kontrolle in einen Pull Request oder ein Ticket übernommen wird.

• Feste Referenzen: gespeicherte Konfigurationen, IDE-Vorgaben, Agentenprofile und interne Anleitungen nach den sechs Modellnamen durchsuchen.
• Berechtigungen: prüfen, ob das vorgeschlagene Ersatzmodell in den Copilot-Modellrichtlinien tatsächlich aktiviert ist.
• Verhalten: repräsentative Aufgaben für Codegenerierung, Refactoring, Tests, Recherche und Reviews mit dem Zielmodell wiederholen.
• Schnittstellen: kontrollieren, ob Integrationen bei fehlender Modellverfügbarkeit sichtbar fehlschlagen oder unbemerkt auf einen Standard zurückfallen.
• Wirtschaftlichkeit: Nutzungskosten und Nacharbeit gemeinsam erfassen; ein schnelleres Modell ist nicht automatisch der günstigere Gesamtprozess.
• Datenregeln: für jedes Ersatzmodell die geltenden Vertrags-, Aufbewahrungs- und Zugriffsvorgaben separat bestätigen.

Migrationsplan: In fünf Schritten zum kontrollierten Ersatzmodell

1. Abhängigkeiten inventarisieren: Teams, Copilot-Oberflächen, Agenten, Prompts und Dokumente erfassen, die ein abgekündigtes Modell nennen oder voraussetzen.
2. Zielmodell festlegen: GitHubs Vorschlag als Ausgangspunkt verwenden und je Aufgabentyp genau ein primäres Ziel sowie eine Rückfalloption bestimmen.
3. Richtlinie vorbereiten: Enterprise-Administratoren prüfen die Modellfreigabe in den Copilot-Einstellungen und verifizieren die Sichtbarkeit im Modellselektor von VS Code und github.com.
4. Parallel testen: alte Referenzergebnisse und neue Ausgaben anhand derselben Akzeptanzkriterien für Korrektheit, Sicherheit, Laufzeit, Kosten und Nacharbeit vergleichen.
5. Gestuft umstellen: zuerst ein begrenztes Team migrieren, Fehler und Abweichungen dokumentieren und erst nach bestandenem Gate die Standardvorgaben und Schulungsunterlagen aktualisieren.

Ein sinnvoller Rollback besteht nicht darin, auf ein bereits abgekündigtes Modell zurückzuschalten. Die Rückfalloption muss ein zweites unterstütztes Modell oder ein manueller Prozess sein. Abbruchkriterien sollten vor dem Pilot feststehen: etwa wiederholt fehlerhafte Änderungen, nicht eingehaltene Review-Regeln, fehlende Modellfreigabe oder wirtschaftlich nicht vertretbare Nacharbeit. So bleibt der Betrieb handlungsfähig, auch wenn der bevorzugte Ersatz in einer Aufgabe nicht überzeugt.

Was Geschäftsführung und IT jetzt entscheiden sollten

Die technische Umstellung gehört in die Engineering-Verantwortung; die Regeln für Risiko, Daten und Budget sind eine Managemententscheidung. Die Geschäftsführung muss nicht jedes Modell bewerten, sollte aber verlangen, dass produktive KI-Workflows einen benannten Eigentümer, ein unterstütztes Zielmodell, eine messbare Qualitätskontrolle und eine belastbare Rückfalloption besitzen. Copilot-Administratoren wiederum sollten die Richtlinie erst aktivieren, wenn die verantwortlichen Teams den vorgesehenen Einsatz und die Prüfgates dokumentiert haben.

Für die Erfolgsmessung genügt es nicht, dass das Ersatzmodell wieder auswählbar ist. Der Prozesseigner sollte pro Aufgabentyp festhalten, ob Ergebnisse die vorhandenen Tests bestehen, wie viel menschliche Nacharbeit anfällt, welche Laufzeit entsteht und ob Richtlinienverstöße auftreten. Diese Werte werden mit der bisherigen Referenz verglichen. Erst wenn Qualität und Kontrollaufwand akzeptabel sind, wird das Zielmodell zum neuen Standard; andernfalls greift die vorher definierte Rückfalloption.

Der eigenständige Winkel gegenüber einer allgemeinen Copilot-Bestandsaufnahme liegt damit in der konkreten Migration: Welche sechs Abhängigkeiten sind betroffen, welches Ziel nennt GitHub, und wie wird die Funktionsfähigkeit pro Workflow erneut bewiesen? Unternehmen, die diese Fragen systematisch beantworten, behandeln Modellabkündigungen nicht mehr als überraschende Störung. Sie etablieren einen wiederholbaren Lebenszyklus für kommende Wechsel – von der Inventur über den Test bis zum kontrollierten Rückfall.