GitHub Enterprise ImporterによるGitLabからGitHubへの移行が一般提供開始Migrate from GitLab to GitHub with GitHub Enterprise Importer

GitHub has announced that migrations from GitLab to GitHub Enterprise Cloud using the GitHub Enterprise Importer (GEI) are now generally available. According to the company's changelog, this covers both gitlab.com, the hosted service, and GitLab Self-Managed, the version organizations run on their own infrastructure. The change matters because it gives teams a supported, self-service path to move repositories between two of the most widely used code-hosting platforms, reducing reliance on manual scripting or hands-on assistance from GitHub during a transition.

At the core of the announcement is the shift from a preview or limited-availability status to general availability. General availability typically signals that a feature is considered stable enough for production use and is backed by standard support commitments, which is an important consideration for enterprises planning migrations that involve large volumes of source code and history. The changelog emphasizes that customers can now self-serve these migrations, meaning administrators can initiate and manage the process themselves rather than coordinating a bespoke engagement.

The GitHub Enterprise Importer is GitHub's tooling for moving work into GitHub Enterprise Cloud, and it is generally driven through the GitHub CLI, referred to as gh, using a dedicated migration extension. In practice, that means a team preparing to move from GitLab would authenticate against both the source and destination, configure the appropriate credentials, and run migration commands to transfer repositories into their GitHub Enterprise Cloud organization. This command-line approach is designed to make migrations repeatable and scriptable, which is useful when an organization needs to move many repositories in batches rather than one at a time.

It is worth being precise about scope. The announcement specifically describes repository migrations from GitLab sources into GitHub Enterprise Cloud. GitLab and GitHub differ in how they model certain features, so organizations evaluating a move should verify which artifacts transfer automatically and which may require additional planning. Historically, GEI migrations focus on Git repository content and history, and the mapping of surrounding metadata, permissions, and CI configuration can vary by source platform. Teams that rely heavily on GitLab CI/CD pipelines, for example, would likely need to plan separately for translating that automation into GitHub Actions, since pipeline definitions and runner configurations do not have a one-to-one equivalent across the two systems.

This GitLab support fits into a broader pattern for GEI, which already serves as the migration entry point for several other origins. GitHub has offered GEI-based paths from Azure DevOps and from other GitHub environments, and it maintains separate tooling for on-premises scenarios. By adding GitLab as a generally available source, GitHub extends the importer's reach to a competitor's user base, which appears aimed at customers who are consolidating tooling or standardizing on GitHub Enterprise Cloud. The move also aligns with the destination being the cloud-hosted enterprise offering rather than GitHub Enterprise Server, the self-hosted product, so organizations targeting on-premises GitHub would need to confirm the supported migration routes for that setup.

For context, migrations of this kind are often part of larger platform decisions rather than isolated technical tasks. Enterprises weighing a change frequently consider identity and access management, integration with existing DevOps toolchains, security and compliance features, and the cost implications of licensing across platforms. GitHub Enterprise Cloud brings its own ecosystem, including GitHub Actions for automation, Advanced Security features, and integration with Microsoft's broader developer and cloud services following GitHub's ownership by Microsoft. A self-service GitLab importer lowers one of the practical barriers to switching by making the repository transfer step more predictable.

Organizations planning to use the newly generally available path should still approach a migration methodically. Common prerequisites include ensuring administrators have the necessary roles on both platforms, checking repository sizes and any storage limits, and running trial migrations against a subset of repositories before committing to a full cutover. Because the process is now self-serve and driven through the gh CLI, teams can validate their approach in stages and adjust before moving production workloads.

In summary, the general availability of GitLab-to-GitHub Enterprise Cloud migrations through GitHub Enterprise Importer gives customers a documented, self-directed way to relocate repositories from both gitlab.com and GitLab Self-Managed. While the tooling streamlines the transfer itself, a complete transition is likely to involve additional planning around automation, permissions, and workflow parity, and organizations should consult GitHub's migration documentation to confirm exactly what is supported for their configuration.