GitHub libera migração oficial do GitLab com o Enterprise Importer

O GitHub anunciou, em changelog de 3 de agosto de 2026, que as migrações de gitlab.com e do GitLab Self-Managed para o GitHub Enterprise Cloud usando o GitHub Enterprise Importer (GEI) entraram em disponibilidade geral (GA). Na prática, isso significa que times que hoje vivem no GitLab e querem centralizar no GitHub agora têm um caminho oficial e self-service, sem depender de scripts caseiros ou de exportar/importar .git na unha.

O que dá pra fazer agora

Segundo a fonte, o GEI passa a permitir três coisas concretas:

• Migrar repositórios do gitlab.com e das versões atualmente mantidas do GitLab Self-Managed.
• Migração de repositório único ou em lote (bulk), via a extensão de CLI gh gl2gh, que roda em cima do gh (o CLI oficial do GitHub).
• Escolher onde ficam os arquivos de migração (staging): no blob storage do próprio GitHub, com a flag --use-github-storage, ou na sua conta de AWS S3 ou Azure Blob Storage.

A opção de storage é um detalhe que importa mais do que parece. Migração de repositório grande gera arquivos intermediários pesados; poder apontar para o seu próprio bucket S3 ou container Azure ajuda em cenários de compliance (dado que não transita por storage de terceiro) e evita surpresas com times que já têm política fechada sobre onde artefato pode repousar.

O limite que muda a decisão

A restrição mais importante do anúncio: a migração vale para organizações no GitHub Enterprise Cloud (tanto em github.com quanto em ghe.com). Migração para GitHub Enterprise Server (a versão self-hosted) não é suportada.

Isso define bem o público. Se a empresa roda GitHub Enterprise Server on-premises, o GEI nesse fluxo GitLab→GitHub não resolve, e o planejamento precisa considerar outro caminho. Para quem já está ou pretende ir para o modelo cloud (github.com ou o ghe.com, o data residency do GitHub), o GEI é a rota indicada.

Trade-offs de quem vai migrar

Ferramenta oficial não é sinônimo de migração indolor. Alguns pontos que valem entrar no planejamento antes de rodar o primeiro gh gl2gh:

• O que o GEI migra e o que não migra. Migração de código é a parte fácil. O que costuma doer é o entorno: pipelines de CI (o .gitlab-ci.yml não vira GitHub Actions sozinho), merge requests que viram pull requests, permissões, webhooks, integrações e variáveis de ambiente de CI/CD. Vale conferir na documentação exatamente quais metadados o GEI carrega para não descobrir buraco depois do corte.
• Bulk exige ensaio. A migração scriptada é ótima para dezenas ou centenas de repositórios, mas justamente por ser em lote merece um dry-run com um subconjunto representativo antes de disparar tudo. Repositório com histórico gigante, LFS ou submódulos tende a expor limites de tempo e de storage.
• Janela de corte e congelamento. Como qualquer migração de VCS, o ponto sensível é o momento de virada: definir quando o GitLab vira somente-leitura, comunicar os times e garantir que ninguém continue commitando na origem depois do arquivo gerado.

Para quem faz sentido

O cenário mais claro é o de times brasileiros que estão consolidando ferramentas, seja por custo, seja por já terem apostado no GitHub Copilot e no ecossistema de Actions, e querem trazer o que ficou no GitLab. Para migração pontual de poucos repositórios, o comando de repositório único resolve. Para consolidação de uma org inteira, o fluxo de bulk com storage próprio é o desenho pensado para isso.

O GitHub aponta a documentação de "migrating from GitLab to GitHub" como ponto de partida e menciona que a equipe de Expert Services pode ajudar no planejamento, um recado de que, para migrações grandes, o roteiro não é só técnico: é também organizacional. A recomendação pragmática é a de sempre: comece pequeno, valide o que chegou do outro lado, e só então escale para o lote.

Fonte: GitHub Changelog