Migrating from GitHub Enterprise to Forgejo
If you are still deciding whether to move, the license, cost and sovereignty case is on Forgejo vs GitHub Enterprise. This page is the operational side: what actually happens to a repository, its history and its CI/CD when it moves.
Unlike a Gitea-to-Forgejo move, this is not an in-place upgrade. GitHub Enterprise and Forgejo are separate platforms, so each repository is imported rather than upgraded in place. Forgejo ships GitHub as a supported migration source, so the import carries more than just the git history.
What the importer carries over
Forgejo's migration feature connects to a repository's GitHub remote with an access token and imports:
- The full git history
- Issues, with their labels and milestones
- Pull requests
- Releases
- Git LFS objects, when LFS is enabled on the import
This runs per repository, pointed at GitHub as the source service, and can run once as a straight import or continue as a mirror while both platforms are live.
What does not carry over automatically
GitHub Actions workflows need review, not just a copy. Forgejo Actions
uses the same workflow syntax, so most jobs and steps keep working unchanged.
What does not transfer is the GitHub Actions Marketplace: an action your
workflow pulls from the Marketplace is GitHub-exclusive, so that step needs
rebuilding against an equivalent Forgejo Action or a plain shell step.
Audit each repository's .github/workflows/ directory for Marketplace
dependencies before cutting the team over to the new CI.
Organization structure and team permissions are not part of the per-repository import. Teams, their membership and their repository permissions are set up on the destination instance directly; the importer moves a repository's content, not an organization's access model around it.
Branch protection rules, webhooks and third-party app integrations are GitHub-side configuration and need to be recreated on Forgejo, not migrated automatically.
Sequencing an enterprise move
A GitHub Enterprise organization typically holds far more repositories than a single Gitea instance, and the import runs one repository at a time. Moving everything in a single cutover is rarely realistic. A workable approach:
- Inventory first. List every repository, which ones are actively developed against versus archived, and which workflows reference Marketplace actions.
- Pick a pilot team. Migrate a small, low-risk set of repositories first and run them in parallel with GitHub for a sprint before trusting the process on anything critical.
- Move active repositories in batches, grouped by team or by shared CI dependencies, so a team's repositories and the Actions they depend on land together rather than mid-migration.
- Move or archive the rest once the active estate is confirmed working: history-only repositories need the import but not the CI rebuild.
Verify after each batch
For each migrated repository: confirm the commit history and tags match the GitHub source, open a pull request end to end, run the CI pipeline and confirm it passes, and check that issues and their labels and milestones carried over. The same discipline the Gitea migration guide applies to a schema upgrade applies here to an import: verify before you rely on it, because the cost of finding a gap after cutover is much higher than finding it during the pilot batch.
Where VSHN fits
VSHN operates Forgejo in production for enterprise and regulated customers. Three ways to work with us on a GitHub Enterprise move:
Plan and run the migration with you. We inventory the GitHub organization, sequence the batches, rebuild the Marketplace-dependent CI steps, and verify each batch before the next one starts.
Hand over operations, keep your infrastructure. We run Forgejo on your own cloud or on-premises platform after the move: upgrades, backups, monitoring and incident response.
Move to infrastructure VSHN operates end to end, designed to the requirement for a large estate, with Swiss data residency and no per-seat license.
Not sure how big the move is? Book a free migration assessment and we will map your GitHub Enterprise organization to a batch plan.