GitHub Now Migrates GitLab Repositories in One Command

What Changed

On August 3, 2026, GitHub moved GitLab migrations out of preview. GitHub Enterprise Importer and its gh gl2gh CLI extension are now generally available for self-service use. Until now a GitLab migration went through an Expert Services engagement, so this is the difference between a consulting project and a command you run yourself.

General availability is the useful part of the announcement. It means the feature carries a support commitment and a proper deprecation process, so you can put a migration on a calendar with a date and a budget behind it. A public preview offers neither, which is worth remembering next to stacked pull requests, released a few days earlier and explicitly subject to change.

Sources supported are gitlab.com and any currently maintained, non end-of-life version of GitLab Self-Managed. Older versions are, in GitHub's wording, untested and unevaluated.

The mechanics are straightforward. For each repository the extension exports the GitLab project to a .tar.gz archive, stages it on the machine running the command, uploads it to blob storage GitHub can read, then imports it into the destination organization while translating GitLab entities into their GitHub equivalents. Storage is either GitHub-owned with --use-github-storage or your own S3 or Azure Blob account.

What Moves

The list is genuinely broad, and this is the part the announcement leads with:

• Git source with full commit history, plus the repository wiki
• Commit comments
• Issues and issue comments, including issue state and milestone events
• Merge requests converted into pull requests, carrying comments, reviewers and approvers, state events, milestones, timeline events and emoji reactions
• Releases and release assets
• Uploads and attachments
• Project members, imported as mannequins you reclaim afterwards

Two conversions are lossy in ways worth knowing before someone notices in a review. Threaded discussions become flat comments with the original thread as context. And merge request comments only become proper review comments when diff data is present in the export, otherwise they land as ordinary issue comments. The export carries only the latest diff, so review history against older revisions does not survive as review history.

Pipelines Are a Separate Piece of Work

The documentation is refreshingly direct about this, in the list of data that is not migrated:

CI/CD pipelines and pipeline schedules (.gitlab-ci.yml has no automatic GitHub Actions equivalent)

Pipelines do not come across. Not the definitions, not the schedules, and per the same list, not the CI/CD variables, job traces, artifacts, child pipeline history or pipeline triggers, since GitLab leaves several of those out of the export entirely. Webhooks are in the same group.

This is good to know early rather than late, because it changes the shape of the plan. The repositories move quickly. The pipelines are a translation project with its own scope, and it is much easier to run it in parallel, on a branch, before the code moves, than to start it afterwards. Teams that budget the Actions work as the main line item rather than as a follow-up task tend to have calm migrations.

The rest of the list is shorter and mostly quick to rebuild:

• Git LFS objects. The pointer files travel with the history, so the repository looks complete and is not. The binaries have to be pushed separately afterwards.
• Repository policies, including merge trains, pipeline gates, required approvals, topics, avatars and mirroring. Your branch protection posture is re-created by hand.
• Group settings and group membership. Structure and access are rebuilt on the other side.
• Snippets, issue boards, time tracking and design management data.
• Vulnerability reports.

One Requirement to Check First

Worth confirming before anything else, because it is a yes or no rather than a workaround:

Migrations from GitLab to GitHub Enterprise Server are not supported.

The destination has to be GitHub Enterprise Cloud, on github.com or ghe.com. Self-hosted to self-hosted is not a supported path today.

For most teams that is fine, since GitHub Enterprise Cloud is where they were heading anyway. It is the one thing to check early if you run GitLab Self-Managed for a reason someone wrote into a policy, such as data residency or an air gap, because those same reasons usually point away from a cloud destination. Sixty seconds of checking saves planning a migration this tool cannot perform.

Size the Job Before You Quote It

The documentation is unusually direct about what drives the clock, and it is not what most people estimate on:

Migration timing is largely based on the number of merge requests in a repository. If you want to migrate 1,000 repositories, and each repository has 100 merge requests on average, your migration will likely be very quick. If you want to migrate only 100 repositories, but the repositories each have 75,000 merge requests on average, the migration will take much longer.

Repository count is the number most people estimate on, and merge request count is the one that sets the clock. There is a command that gives you it, connecting to the GitLab API and writing groups.csv and projects.csv with per-project merge request counts:

gh gl2gh inventory-report --gitlab-server-url https://gitlab.example.com

Run that before you commit to a window. The hard ceilings to check against while you are there:

The 255 byte reference limit is the one worth checking by hand, since non-ASCII characters such as emoji in a branch name consume more than one byte each.

When It Makes Sense

If you have been putting off a move to GitHub because the migration looked like a project, that objection is largely gone. The path is supported, self-service and free of a consulting engagement, and the history that makes code review useful comes with it. Plan the Actions work as its own piece and the rest is straightforward.

If the motivation is cost rather than tooling, price GitHub Enterprise Cloud first. Forge moves made to save money can end up costing more in migration effort than the licence they replace, and that is worth knowing before rather than after.

We plan and run forge migrations and build the CI/CD pipelines on the other side, as part of DevOps as a service. If you want a realistic estimate of what your .gitlab-ci.yml becomes in GitHub Actions before you commit to a timeline, get in touch.

Sources: GitHub Changelog, August 3 2026, Understand migrations from GitLab to GitHub, Plan your migration from GitLab to GitHub, Follow-up tasks