Technik

App-Code bis 31. August sichern: Was bei GitHub Spark zusätzlich umziehen muss

GitHub Spark endet: So sichern Sie App-Code bis 31. August und prüfen Daten, Anmeldung, KI-Funktionen und Hosting für den Umzug.

Von Wolfgang

06. Aug. 20268 Min. Lesezeit

GitHub Spark endet: So sichern Sie App-Code bis 31. August und prüfen Daten, Anmeldung, KI-Funktionen und Hosting für den Umzug.

Wer eine GitHub-Spark-App nur als Repository sichert, hat zunächst den Quellcode gerettet – nicht automatisch die laufende Anwendung. Bis zum 31. August 2026 bleibt Zeit, den Code zu sichern und die Abhängigkeiten der App sauber zu sortieren.

Das Wichtigste in 30 Sekunden

GitHub Spark nimmt seit dem 4. August 2026 keine neuen Nutzer und keine neuen Apps mehr an.
Bestehende Nutzer können vorhandene Apps bis zum 31. August über … und Create repository in ein privates Repository übernehmen.
Übernommen werden laut GitHub Code sowie bisherige Änderungen und Commits. Daten, Anmeldung, Secrets, KI-Aufrufe und Hosting müssen je App separat geprüft werden.
Ein Repository ist erst der Anfang: Entscheidend ist ein Test des vollständigen Kernablaufs in einer eigenen Zielumgebung.

Entwicklerin ordnet an einem neutralen Laptop Projektunterlagen und eine Aufgabenliste für die Sicherung einer Anwendung. — Der Repository-Export ist der Anfang der Bestandsaufnahme, nicht der Nachweis eines vollständigen Umzugs – durch KI erzeugt

Ein Repository ersetzt keine laufende App

Der entscheidende Punkt ist nicht der Klick auf Create repository. Er liegt danach: Eine Spark-App kann Daten speichern, Nutzer über GitHub anmelden, KI-Funktionen aufrufen und über eine von Spark verwaltete Laufzeit bereitgestellt werden. Wenn ein Team diese Bausteine nicht einzeln erfasst, fällt der fehlende Teil oft erst auf, wenn die exportierte App außerhalb von Spark starten soll.

GitHub hat die aktuelle Spark-Erfahrung auf github.com zur Einstellung angekündigt. Seit dem 4. August sind keine neuen Nutzer und keine neuen Spark-Apps mehr möglich. Bestehende Nutzer können ihre vorhandenen Apps nach GitHubs Angaben bis zum 31. August aufrufen und den Code sichern. Bereits bereitgestellte Apps sollen weiter funktionieren. Das ist ein Grund, ohne Panik zu handeln – aber keine Zusage, dass jede App später unverändert bearbeitbar oder ohne Anpassung in einer neuen Umgebung lauffähig bleibt.

Dieser Ablauf richtet sich an Teams mit einer bestehenden Spark-App: vom kleinen Prototyp bis zum internen Werkzeug oder einer bereits genutzten Anwendung. Er verspricht keinen Ein-Klick-Umzug. Er trennt bewusst zwischen einer belegten Codesicherung und den Teilen, für die GitHubs Unterlagen keinen allgemeinen Migrationsweg nennen.

Voraussetzungen: Zugriff, Überblick und ein Testfenster

Für die Codesicherung braucht es Zugriff auf das betreffende Spark-Projekt und die Möglichkeit, im persönlichen GitHub-Konto ein privates Repository anzulegen. Vor dem Start lohnt eine kurze Liste: Welche App ist betroffen, wer nutzt sie, welche Daten verarbeitet sie und welcher Kernablauf darf nicht ausfallen?

Der Repository-Schritt selbst ist überschaubar. GitHub dokumentiert ihn als klaren Workbench-Vorgang. Für den gesamten Umzug gibt es dagegen keine belastbare Standarddauer. Sie hängt davon ab, ob die App nur Oberflächenlogik enthält oder zusätzlich Speicher, Anmeldung, Rollen, Secrets, KI-Funktionen und Hosting nutzt. Reservieren Sie deshalb nicht nur Zeit für den Export, sondern auch für Inventur und Test.

GitHub-Spark-App sichern: der Ablauf in acht Schritten

Betroffene App und Kernablauf festhalten. Notieren Sie Nutzergruppen, kritische Seiten, Eingaben und Ergebnisse. Bei einem internen Freigabe-Tool kann das etwa Anmeldung, Dateneingabe, Rollenprüfung und Speichern sein.
Die Spark-Workbench öffnen. Arbeiten Sie in der vorhandenen App und prüfen Sie, ob Sie die aktuelle Fassung vor sich haben.
Repository erstellen. Wählen Sie in der Workbench das Drei-Punkte-Menü und anschließend Create repository. GitHub beschreibt dafür ein privates Repository im persönlichen Konto.
Dateien und Historie kontrollieren. Öffnen Sie das neue Repository. Prüfen Sie, ob die erwarteten Dateien vorhanden sind und ob Änderungen sowie Commits vor der Repository-Erstellung übernommen wurden.
Spark-Abhängigkeiten inventarisieren. Halten Sie getrennt fest, ob die App Datenspeicherung, GitHub-Authentifizierung, Rollen oder Sichtbarkeitsregeln, Secrets, llm()-Aufrufe und Hosting nutzt.
Daten und Konfiguration app-spezifisch sichern. GitHub dokumentiert keinen allgemeinen Komplett-Export für Laufzeitdaten, Authentifizierung, Secrets oder Hosting-Konfiguration. Folgen Sie deshalb nur den für Ihre konkrete App und Zielumgebung verfügbaren, geprüften Export- oder Sicherungswegen.
Zielumgebung aufbauen. Wählen Sie keine Plattform nach einem allgemeinen Rezept. Entscheidend sind die tatsächlichen Anforderungen der App: Datenzugriff, Anmeldung, Berechtigungen, Betrieb und gegebenenfalls KI-Inferenz.
Kernablauf mit Testkonten prüfen. Bauen und starten Sie die exportierte Fassung in einer getrennten Testumgebung. Testen Sie Anmeldung, Lesen und Schreiben, Rollen, Fehlerfälle und – falls genutzt – die KI-Funktion.

Sachillustration mit einem Ordner für Code und Historie sowie getrennten Karten für Daten, Anmeldung, Rollen, Secrets, KI-Aufrufe und Hosting. — Die Systemkarte trennt gesicherten Code von den Diensten, die jede App einzeln prüfen muss – durch KI erzeugt

Im Repository – und was trotzdem offen bleibt

Bereich	Was die Quellen tragen	Was das Team prüfen muss
Code und Commit-Historie	GitHub beschreibt ein privates Repository; vorherige Änderungen und Commits werden übernommen.	Dateien, Branches und Historie im neuen Repository kontrollieren.
Daten	Spark kann einen auf Azure Cosmos DB gestützten Key-Value-Store verwenden.	Vorhandene Daten und einen app-spezifischen Sicherungs- oder Exportweg prüfen; ein Universalexport ist nicht dokumentiert.
Anmeldung und Rollen	Spark bietet GitHub-Authentifizierung und Einstellungen für Sichtbarkeit sowie Datenzugriff.	Konten, Sessions, Rollen und Zugriffsregeln in der Zielumgebung neu prüfen.
KI-Funktionen	Nur Apps mit `llm()`-Aufrufen benötigen laut GitHub für diese Funktion einen eigenen Inferenzanbieter, API-Schlüssel und eigene Abrechnung.	Aufrufe identifizieren und die neue Anbindung mit sicheren Testschlüsseln testen.
Hosting	GitHub beschreibt Spark-Bereitstellungen über Azure Container Apps.	URL, Bereitstellung, Protokollierung und die konkrete Betriebsumgebung separat konfigurieren und testen.

Ein häufiger Irrtum ist, die in der Spark-Dokumentation erwähnte Data-Ansicht als allgemeinen Exportbeleg zu lesen. Sie zeigt, dass gespeicherte Werte einsehbar und bearbeitbar sein können. Daraus folgt kein allgemeiner Weg, sämtliche Daten einer beliebigen App vollständig mitzunehmen.

Wann KI tatsächlich zur Migrationsaufgabe wird

GitHub Models ist laut GitHub seit dem 30. Juli 2026 eingestellt. Für Spark ist die Folge enger, als sie zunächst klingt: Nur eine App, die wirklich llm()-Aufrufe verwendet, braucht für diese Funktion eine neue Inferenzanbindung. Für diese Apps nennt GitHub einen eigenen Anbieter, eigene API-Schlüssel und künftig selbst verwaltete Abrechnung.

Eine App ohne solche Aufrufe muss deshalb nicht künstlich mit einer KI-Migration belastet werden. Umgekehrt reicht es bei einer KI-gestützten App nicht, nur den Code zu sichern. Testen Sie nach der neuen Anbindung mindestens die Eingaben, Antwortfehler, Berechtigungen und das Verhalten bei fehlenden oder ungültigen Schlüsseln.

Der stärkste Einwand: Läuft die veröffentlichte App nicht weiter?

GitHub schreibt, dass bereits bereitgestellte Spark-Apps nach der Einstellung weiter funktionieren sollen. Ein sofortiger Komplettwechsel ohne Test ist deshalb nicht automatisch sinnvoll. Die Frist bis zum 31. August bleibt trotzdem praktisch relevant: Sie betrifft den dokumentierten Zugriff auf bestehende Apps und den Repository-Schritt. Außerdem ist ein fortlaufender Betrieb keine allgemeine Garantie für spätere Bearbeitung, Synchronisierung oder die Übertragbarkeit der verwalteten Dienste.

Für einfache Prototypen kann es reichen, Code und Verlauf zügig zu sichern und danach in Ruhe zu planen. Bei Werkzeugen mit Nutzerkonten oder Daten ist es klüger, die Testumgebung vor der Umstellung aufzubauen. Öffentlich genutzte Apps brauchen zusätzlich einen kontrollierten Übergang: Änderungen erst nach einem vollständigen Test freigeben und den bisherigen Betrieb bis zum Fristende beobachten.

Zwei Personen prüfen gemeinsam an Laptop und Smartphone den Kernablauf einer Anwendung mit Testnotizen auf dem Tisch. — Erst ein Test von Anmeldung, Datenzugriff und Kernablauf zeigt, was außerhalb von Spark noch fehlt – durch KI erzeugt

Für Teams in Deutschland und Europa bleibt der technische Ablauf derselbe: Code vor der Frist sichern, die tatsächlich verwendeten Spark-Dienste erfassen und die Zielumgebung mit eigenen Testkonten prüfen.

Ergebnisprüfung: Woran ein echter Umzug zu erkennen ist

Ist die App außerhalb von Spark betriebsfähig?

Das Repository enthält die erwarteten Dateien und die bisherige Commit-Historie.
Die App baut und startet in der vorgesehenen Testumgebung.
Testkonten können sich anmelden; Rollen und Zugriffsregeln verhalten sich wie erwartet.
Lesen und Schreiben mit repräsentativen Testdaten funktionieren nachvollziehbar.
Secrets liegen nicht versehentlich im Repository und sind in der Zielumgebung korrekt hinterlegt.
Falls vorhanden, sind llm()-Aufrufe mit dem neuen Anbieter getestet; Fehlerfälle sind sichtbar.
Der vollständige Kernablauf funktioniert, nicht nur eine einzelne Seite oder ein erfolgreicher Build.

Erst diese Prüfung beantwortet die wichtige Frage: Ist die App nur archiviert, oder kann sie tatsächlich weiterbetrieben werden? Das Ergebnis darf je nach App unterschiedlich ausfallen. Genau deshalb ist der getrennte Blick auf Code, Daten, Anmeldung, KI und Hosting hilfreicher als eine pauschale Migrationszusage.

Typische Fehler vermeiden

Verwechseln Sie die Spark-Einstellung nicht mit einer Abschaltung des GitHub-Kontos, gewöhnlicher Repositories oder von GitHub Copilot. Betroffen ist die aktuelle Spark-Erfahrung auf github.com. Ebenso riskant ist der umgekehrte Fehlschluss: Ein erfolgreicher Commit oder Build beweist noch nicht, dass Datenzugriff, Anmeldung oder Berechtigungen funktionieren.

Auch die frühere Zwei-Wege-Synchronisierung zwischen Spark und dem Hauptbranch ist kein Plan für die Zeit nach dem 31. August. GitHub beschreibt sie für den laufenden Spark-Betrieb. Für den weiteren Weg ist das neue Repository daher ein sauberer Ausgangspunkt, nicht eine Zusage für fortlaufende Synchronisierung.

Fazit: Erst sichern, dann gezielt migrieren

Der sinnvolle nächste Schritt ist klar: Sichern Sie jede betroffene Spark-App vor dem 31. August als Repository und kontrollieren Sie Code sowie Commit-Historie. Danach folgt die eigentliche technische Arbeit in überschaubaren Teilen: Abhängigkeiten erfassen, die Zielumgebung passend zur App aufbauen und den gesamten Kernablauf testen. So wird aus einer Frist kein hektischer Plattformwechsel, sondern ein nachvollziehbarer Übergang.