GitLab to GitHub Migrations Go GA: gh gl2gh, What Moves and What Doesn't

What shipped#

On August 3, GitHub moved GitLab migrations in GitHub Enterprise Importer (GEI, formerly Octoshift) from preview to generally available. Teams can now self-serve a migration from gitlab.com or GitLab Self-Managed into GitHub Enterprise Cloud using the gh gl2gh CLI extension, with no professional-services engagement required.

The flow is a four-step pipeline, per the GitHub docs:

1. gh gl2gh exports the GitLab project to a .tar.gz archive containing the Git repository plus project metadata (issues, merge requests, labels, milestones, releases)
2. The archive is staged on the machine running the command
3. It is uploaded to blob storage GitHub can read: either GitHub-owned storage (--use-github-storage) or a storage account you own in AWS S3 or Azure Blob Storage
4. The import transforms GitLab entities into their GitHub equivalents

Setup is two environment variables and one command. Create a GitLab personal access token with api and read_repository scopes, a GitHub PAT, set GITLAB_PAT and GH_PAT, then:

gh extension install github/gh-gl2gh
gh gl2gh generate-script --gitlab-server-url https://gitlab.com \
  --github-org DESTINATION \
  --output filename.ps1

The generated script handles single repositories or scripted bulk migrations. Targets are organizations on GitHub Enterprise Cloud, both github.com and ghe.com. GitLab to GitHub Enterprise Server is not supported.

What moves and what does not#

The data fidelity map is the heart of any migration story, and the docs are unusually precise about it.

What migrates: full Git history and the repository wiki, commit comments, issues and issue comments (threaded discussions become flat comments with thread context preserved), milestones, timeline events, emoji reactions, uploads, and releases with assets. Merge requests convert to pull requests, including reviewers, approvers, and state events. Comments on merge requests migrate as review comments only when diff data is present in the export, and the export carries only the latest diff. Project members arrive as mannequins: placeholder identities you reclaim to real GitHub accounts.

What does not migrate, and this is the cost side of the ledger:

• CI/CD pipelines and pipeline schedules. The docs are blunt: .gitlab-ci.yml has no automatic GitHub Actions equivalent
• Git LFS objects (pointer files travel with history; binaries must be pushed separately after)
• Repository policies: merge trains, pipeline gates, required approvals, topics, avatars, mirroring
• Group settings and group membership, snippets, issue boards, time tracking, design management
• Webhooks, CI/CD variables, job traces and artifacts, child-pipeline history, pipeline triggers

Limits worth knowing before you plan: a 40 GiB source-code ceiling for the repository (public preview), 2 GiB per commit and per push, a 400 MiB per-file ceiling during migration dropping to 100 MiB after, and a 40 GB cap on GitLab's own project export archive. Code search re-indexes over a few hours after import, and org rulesets can fail a migration if existing commits do not comply.

Why it matters#

This is GitHub closing the loop on its platform consolidation story. GEI already covers Azure DevOps and GitHub-to-GitHub in GA, with Bitbucket Server and Data Center in public beta. GitLab was the big missing self-serve path, and the gap mattered because GitLab shops tend to be all-in: projects, CI, issues, and container registry in one place. The export pipeline and the MR-to-PR transform are what make this a real migration rather than a re-import of Git history plus a spreadsheet of issues.

The transformation semantics deserve attention before you commit to the move. Merge request approvals and reviewers survive, which is the part most teams cannot afford to lose. But the docs' note that threaded discussions flatten, and that only the latest diff rides in the export, means review history reads differently after migration. Budget for that when you communicate the move to the team.

My read: the CI/CD gap is the actual price of the move, and it is a big one. GitLab's pipeline config, variables, artifacts, and schedules are the machinery most teams have tuned for years, and none of it converts. GitHub Actions gets you to parity on pipeline runs, but rebuilding .gitlab-ci.yml as workflows, migrating secrets, and re-doing environment gates is a project in its own right. The right framing is: this GA makes the repository and issue migration turnkey, and the CI rebuild is the remaining manual work.

The storage model is also distinctive. Staging archives in your own S3 or Azure bucket, or in GitHub-owned storage, means the migration runs from a machine with network reach to both sides and to the staging bucket. For air-gapped or heavily governed self-managed installs, the access story (PATs with api and read_repository scopes) is simpler than it has been, but the archive route is still a bulk data movement, not a streamed one.

Who this is for#

Teams that already run GitHub for most of their work and have GitLab standing as a single-tenant island. For them, the cost of the move just dropped from a paid migration engagement to a scripted CLI run plus a CI rebuild. The same is true for teams whose GitLab self-managed instance is approaching end-of-life: supported-version coverage means you need a maintained instance to migrate from, and the importer only targets Enterprise Cloud, so this does not help the GitLab-on-GitHub-Enterprise-Server crowd.

If you are weighing the move, the practical next step is a trial run on one representative repository: gh gl2gh supports it, and the docs explicitly recommend it. Check the mannequin reclaim flow, diff your CI surface against the not-migrated list, and validate that your merge trains and approval policies have Actions-based replacements before you script the fleet.

Continue Reading#

• GitHub Stacked PRs Hit Public Preview - the other recent change to how GitHub-native review works in the agent era
• GitHub Actions: Reference Same-Repository Actions with Self-Repository Syntax - an Actions feature that matters when you rebuild CI after a move
• GitHub Copilot Enterprise Team Model Policy Targeting - what GitHub looks like as a managed enterprise platform once you arrive
• Convex to Neon Playbook: Migrating 4 Apps - a worked migration from this site's own history, with the same what-moves-what discipline
• How Cloudflare Migrated cdnjs to Its Developer Platform - another large-scale platform migration, dogfooding the tools being shipped

Sources#

• GitHub Changelog: Migrate from GitLab to GitHub with GitHub Enterprise Importer (August 3, 2026)
• GitHub Docs: Migrating from GitLab to GitHub
• GitHub Docs: Understand migrations from GitLab to GitHub
• github/gh-gl2gh extension (GitHub Enterprise Importer CLI)