Constantin, Azure & Kubernetes Consultant bei Pexon Consulting | 7 Min. Lesezeit | 16.08.2026
TL;DR
GitHub Enterprise Importer (GEI) ist Microsofts empfohlenes Migrationswerkzeug, hat aber harte Grenzen: 40 GB pro Git- und Metadaten-Archiv, 2 GB pro Commit, maximal 5.000 Repos je Org-Migration. Git LFS, Packages, Pipelines, Secrets und Branch-Protections migriert GEI nicht. Wer das vorher weiß, plant die Lücken ein, statt sie live zu entdecken.
Warum die Grenzen entscheidend sind, bevor Sie starten
Eine GitHub-Migration scheitert selten am Kopieren der Commits. Sie scheitert an dem, was GEI still liegen lässt. Der GitHub Enterprise Importer ist das offizielle, von GitHub empfohlene Werkzeug für den Umzug ganzer Organisationen nach GitHub Enterprise Cloud. Er macht die Kern-Arbeit zuverlässig. Aber er ist kein Komplettpaket, und genau diese Lücke wird in Migrationsprojekten regelmäßig unterschätzt.
Wer glaubt, ein Kommando migriert alles, plant die Nacharbeit nicht ein und merkt erst nach dem Cutover, dass die CI-Pipelines fehlen, die Secrets weg sind und Git LFS ins Leere zeigt. Deshalb gehört die Grenzen-Analyse an den Anfang der Migrationsplanung, nicht ans Ende.
Die harten Größenlimits
Im Juni 2025 hat GitHub die Archiv-Limits verdoppelt, von 20 GB auf 40 GB, und zwar sowohl für das Git- als auch für das Metadaten-Archiv. Das gilt für GitHub-, Bitbucket-Server-, Azure-DevOps-Cloud- und GitLab-Quellen (letztere in Preview). Trotzdem bleiben es Grenzen, an die reale Repos stoßen:
Das Metadaten-Limit übersehen viele. Ein Repo mit zehn Jahren Issue-Historie, tausenden Pull Requests und großen Attachments kann beim Metadaten-Archiv schneller an die 40 GB stoßen als beim Code. Und das 2-GB-Commit-Limit trifft genau die Teams, die früher versehentlich große Binärdateien oder Build-Artefakte eingecheckt haben. Diese History müssen Sie vor der Migration ausdünnen.
Unsere klare Ansage: Bei einem Monorepo jenseits von 40 GB hilft GEI nicht weiter. Da führt kein Weg an einer History-Bereinigung vorbei (etwa mit git filter-repo), oder Sie migrieren mit einem flacheren History-Schnitt. Das ist Aufwand, den Sie vor dem Migrationsfenster einplanen müssen, nicht darin.
Was GEI migriert, und was nicht
Das ist der Teil, der Projekte kippt. GEI migriert den Kern eines Repositories, aber eine Reihe wichtiger Artefakte bleibt außen vor:
Vier Punkte, die in fast jedem Projekt zur Nacharbeit werden:
- Git LFS wird nicht automatisch mitgenommen. Große Dateien, die über LFS verwaltet werden, müssen Sie separat migrieren, sonst zeigen die Pointer nach der Migration ins Leere.
- Secrets sind weg. Actions-Secrets und Webhook-Secrets müssen Sie im Ziel neu setzen. Das ist auch sicherheitstechnisch richtig so, aber es muss eben jemand tun.
- Pipelines aus Azure DevOps kommen nicht mit. Wer von ADO migriert, baut die CI/CD im Ziel neu auf (oder auf GitHub Actions um).
- Branch-Protections und Repo-Settings hängen von Quelle und Version ab. Verlassen Sie sich nicht darauf, prüfen Sie die Migrated-Data-Matrix für genau Ihre Quelle.
Aus welchen Quellen GEI migriert
GEI ist nicht nur ein GitHub-zu-GitHub-Werkzeug. Es unterstützt mehrere Quellen, jeweils mit einer Mindest-Version:
Wichtig für die Planung: Ein GHES älter als 3.4.1 muss vor der Migration erst aktualisiert werden. Und die GitLab-Unterstützung ist noch Preview, für einen produktiven Umzug mit Zeitdruck ist das ein Risiko, das Sie bewusst bewerten sollten.
So läuft eine Repo-Migration technisch
GEI wird über die GitHub-CLI-Erweiterung gh-gei gesteuert. Installiert wird sie als Extension:
# GEI-CLI-Erweiterung installieren
gh extension install github/gh-gei
# Version prüfen (Stand August 2026 regelmäßig aktualisiert)
gh gei --versionEine einzelne Repo-Migration von GitHub nach GitHub Enterprise Cloud sieht dann so aus:
# Ein Repository migrieren
gh gei migrate-repo
--github-source-org quell-org
--source-repo mein-repo
--github-target-org ziel-org
--target-repo mein-repoGit LFS ist damit ausdrücklich nicht abgedeckt. Die LFS-Objekte holen Sie in einem separaten Schritt nach, klassisch über einen Mirror-Clone und git lfs push:
# Git-LFS-Objekte separat ins Zielrepo schieben
git clone --mirror https://github.com/quell-org/mein-repo.git
cd mein-repo.git
git lfs fetch --all
git lfs push --all https://github.com/ziel-org/mein-repo.gitDas ist kein exotischer Sonderfall, sondern der Normalfall bei jedem Repo mit LFS. Planen Sie den Schritt fest ein.
Die typischen Stolperfallen in der Praxis
Aus Migrationsprojekten sehen wir immer wieder dieselben drei Muster:
- Metadaten unterschätzt. Teams messen die Repo-Größe am Code und stoßen dann am Metadaten-Archiv an die Grenze. Prüfen Sie beides vorher.
- LFS vergessen. Nach dem Cutover sind die großen Dateien kaputt, weil niemand den separaten LFS-Schritt eingeplant hat.
- Cutover ohne Verifikation. Es wird migriert und sofort umgeschaltet, ohne zu prüfen, ob Branch-Protections, Secrets und Pipelines im Ziel überhaupt stehen. Ein sauberer Migrationsplan hat immer eine Verifikations-Phase vor dem endgültigen Umschalten.
Wer eine größere Migration plant, sollte den GitHub-Umzug nicht isoliert betrachten, sondern als Teil der Developer-Platform. Wie interne Entwickler-Plattformen aufgebaut werden, zeigt der Beitrag zur Kubernetes-Migration von VMs zu Containern, und die Frage, wer den Betrieb danach standardisiert verantwortet, gehört in die DevOps-Engineering-Praxis. Kubernetes Backup Restore als Betrieb, nicht als Hoffnung
Häufig gestellte Fragen
Welche Größenlimits hat der GitHub Enterprise Importer?
Seit Juni 2025 liegen die Limits bei 40 GB pro Git-Archiv und 40 GB pro Metadaten-Archiv, verdoppelt von zuvor 20 GB. Ein einzelner Commit darf maximal 2 GB groß sein, und eine Organisations-Migration umfasst höchstens 5.000 Repositories pro Lauf. Größere Orgs migrieren Sie in mehreren Batches.
Migriert GEI Git LFS?
Nein. Git-LFS-Objekte werden nicht automatisch migriert. Ohne einen separaten LFS-Schritt zeigen die LFS-Pointer nach der Migration ins Leere. Sie holen die Objekte über einen Mirror-Clone und git lfs push ins Zielrepo nach.
Werden GitHub Actions und Pipelines migriert?
Actions-Workflows als Dateien kommen mit dem Code mit, aber die Secrets nicht. Bei einer Migration aus Azure DevOps werden die CI/CD-Pipelines gar nicht übernommen, die bauen Sie im Ziel neu auf, meist gleich als GitHub Actions. Secrets müssen Sie in jedem Fall neu setzen.
Aus welchen Quellen kann GEI migrieren?
GEI unterstützt GitHub.com, GitHub Enterprise Server ab 3.4.1, Azure DevOps Cloud, Bitbucket Server und Data Center ab 5.14 sowie GitLab (in Preview). Ein GHES unter 3.4.1 müssen Sie vor der Migration aktualisieren.
Was kostet der GitHub Enterprise Importer?
Das Werkzeug selbst ist kostenlos. Kosten entstehen an anderer Stelle: über die GitHub-Enterprise-Cloud-Lizenzen im Ziel und über den Aufwand für die Nacharbeit, die GEI nicht abdeckt (LFS, Secrets, Pipelines, Berechtigungen). Genau dieser Aufwand ist der Posten, den Projekte am häufigsten zu niedrig ansetzen.
Nächster Schritt
Die GEI-Grenzen sind planbar, wenn man sie vor dem Migrationsfenster kennt. Wenn Sie eine GitHub-Migration vor sich haben und die Lücken sauber einplanen wollen, statt sie live zu entdecken, sprechen Sie mit uns.
Verwandte Themen
