Migration von GitHub Enterprise zu Forgejo

Wenn du noch entscheidest, ob du wechseln willst, findest du die Lizenz-, Kosten- und Souveränitätsfrage auf Forgejo vs. GitHub Enterprise. Diese Seite behandelt die betriebliche Seite: was mit einem Repository, seiner Historie und seiner CI/CD beim Wechsel tatsächlich passiert.

Anders als ein Wechsel von Gitea zu Forgejo ist das kein Upgrade an Ort und Stelle. GitHub Enterprise und Forgejo sind getrennte Plattformen, also wird jedes Repository importiert statt an Ort und Stelle aktualisiert. Forgejo unterstützt GitHub als Migrationsquelle, also übernimmt der Import mehr als nur die Git-Historie.

Was der Importer übernimmt

Forgejos Migrationsfunktion verbindet sich mit dem GitHub-Remote eines Repositorys über ein Zugriffstoken und importiert:

• die vollständige Git-Historie
• Issues mit ihren Labels und Milestones
• Pull Requests
• Releases
• Git-LFS-Objekte, wenn LFS beim Import aktiviert ist

Das läuft pro Repository, mit GitHub als Quelldienst, und kann einmalig als reiner Import laufen oder als Mirror weiterlaufen, während beide Plattformen aktiv sind.

Beratung anfragen

Was nicht automatisch übernommen wird

GitHub-Actions-Workflows brauchen eine Durchsicht, nicht nur eine Kopie. Forgejo Actions verwendet dieselbe Workflow-Syntax, also laufen die meisten Jobs und Schritte unverändert weiter. Was nicht mitkommt, ist der GitHub Actions Marketplace: eine Action, die dein Workflow aus dem Marketplace bezieht, ist GitHub-exklusiv, also muss dieser Schritt gegen eine gleichwertige Forgejo-Action oder einen einfachen Shell-Schritt neu gebaut werden. Prüf das .github/workflows/-Verzeichnis jedes Repositorys auf Marketplace-Abhängigkeiten, bevor du das Team auf die neue CI umstellst.

Organisationsstruktur und Teamberechtigungen sind nicht Teil des Imports pro Repository. Teams, ihre Mitgliedschaft und ihre Repository-Berechtigungen richtest du direkt auf der Zielinstanz ein; der Importer übernimmt den Inhalt eines Repositorys, nicht das Zugriffsmodell der Organisation darum herum.

Branch-Protection-Regeln, Webhooks und Integrationen von Drittanbieter-Apps sind GitHub-seitige Konfiguration und müssen auf Forgejo neu eingerichtet werden statt automatisch übernommen zu werden.

Eine Migration für ein Unternehmen sequenzieren

Eine GitHub-Enterprise-Organisation hat typischerweise deutlich mehr Repositories als eine einzelne Gitea-Instanz, und der Import läuft ein Repository nach dem anderen. Alles in einem einzigen Schnitt zu wechseln ist selten realistisch. Ein praktikabler Ansatz:

1. Erst die Bestandsaufnahme. Liste jedes Repository, welche davon aktiv weiterentwickelt werden und welche archiviert sind, und welche Workflows Marketplace-Actions referenzieren.
2. Wähl ein Pilotteam. Migrier zuerst eine kleine, risikoarme Auswahl von Repositories und lass sie einen Sprint lang parallel zu GitHub laufen, bevor du dem Prozess etwas Kritisches anvertraust.
3. Migrier aktive Repositories in Gruppen, nach Team oder nach gemeinsamen CI-Abhängigkeiten geordnet, damit die Repositories eines Teams und die Actions, von denen sie abhängen, zusammen landen statt mitten in der Migration getrennt zu werden.
4. Migrier oder archivier den Rest, sobald der aktive Bestand bestätigt funktioniert: Repositories, die nur Historie enthalten, brauchen den Import, aber keinen CI-Umbau.

Nach jeder Gruppe prüfen

Für jedes migrierte Repository: vergleich Commit-Historie und Tags mit der GitHub-Quelle, öffne einen Pull Request von Anfang bis Ende, lass die CI-Pipeline laufen und prüf, dass sie durchläuft, und kontrollier, dass Issues mit ihren Labels und Milestones mitgekommen sind. Dieselbe Disziplin, die die Gitea-Migrationsanleitung für ein Schema-Upgrade verlangt, gilt hier für einen Import: prüf es, bevor du dich darauf verlässt, denn eine Lücke nach dem Umschalten zu finden kostet deutlich mehr als sie in der Pilotgruppe zu finden.

Wo VSHN passt

VSHN betreibt Forgejo produktiv für Unternehmen und regulierte Kundinnen und Kunden. Drei Wege, mit uns an einem Wechsel von GitHub Enterprise zu arbeiten:

Migration gemeinsam planen und durchführen. Wir machen die Bestandsaufnahme der GitHub-Organisation, sequenzieren die Gruppen, bauen die Marketplace-abhängigen CI-Schritte neu und prüfen jede Gruppe, bevor die nächste beginnt.

Betrieb übergeben, deine Infrastruktur behalten. Wir betreiben Forgejo nach dem Wechsel auf deiner eigenen Cloud- oder On-Premises-Plattform: Upgrades, Backups, Monitoring und Incident Response.

Zu Infrastruktur wechseln, die VSHN vollständig betreibt, für eine grosse Umgebung auf die Anforderung ausgelegt, mit Schweizer Datenstandort und ohne Lizenz pro Nutzer.

Nicht sicher, wie gross der Wechsel ist? Vereinbare eine kostenlose Migrationseinschätzung, und wir bilden deine GitHub-Enterprise-Organisation auf einen Gruppenplan ab.