Migrar repositórios do Azure DevOps para o GitHub exige conferir o fluxo de trabalho completo. Código acessível no destino não basta como aceite: permissões, validações de pull request e integrações também precisam funcionar.

O caso relatado pela Microsoft

Em 3 de junho de 2026, a Microsoft relatou que sua organização Copilot, Agents, and Platforms (CAP) havia migrado mais de 1.600 repositórios e 3.100 desenvolvedores nos seis meses anteriores. A migração era parcial: repositórios complexos ainda permaneciam no Azure DevOps.

O relato descreve um modelo híbrido, com repositórios no GitHub e uso continuado de Azure Boards e Azure Pipelines. Ele cita a integração pelo aplicativo Azure Pipelines e vínculos AB# com work items. Acesso a recursos de IA aparece como motivação da organização, não como medição independente de produtividade nem prazo que outra equipe deva reproduzir.

Inventário antes de escolher o lote

A documentação do GitHub Enterprise Importer recomenda levantar repositórios e pull requests. A quantidade de pull requests pesa no tempo de migração; contar apenas repositórios esconde parte do trabalho. A extensão ADO2GH do GitHub CLI oferece gh ado2gh inventory-report --ado-org YOUR_ADO_ORG, que consulta a organização e gera arquivos CSV. Esse comando requer a extensão e o acesso apropriado; não foi executado para este artigo.

A mesma documentação informa que o importer não migra as permissões de repositório do Azure DevOps. O mapeamento de acesso precisa ser tratado explicitamente; não suponha que um clone bem-sucedido confirme que todos os usuários receberam a permissão correta.

Critérios de aceite para um piloto

A proposta abaixo transforma a migração em uma decisão verificável. Escolha um repositório representativo de um fluxo real, com responsável disponível, sem começar pelo sistema mais crítico.

  • Compare branches e tags esperadas e uma amostra identificada de commits. Registre diferenças e confira arquivos grandes ou submódulos quando existirem.
  • Abra uma pull request de teste e verifique revisores, checks obrigatórios e bloqueio de merge sem aprovação. Não use apenas uma conta administradora para o teste.
  • Teste uma conta que deve ler, uma que deve contribuir e uma que não deve ter acesso. Guarde o resultado esperado de cada caso antes da mudança.
  • Execute um pipeline de homologação com credenciais próprias desse ambiente. Confira gatilhos, variáveis, artefatos e a associação com o work item, quando essa integração fizer parte do processo.
  • Combine o período de congelamento de escrita, quem decide a virada e o que acontece com alterações feitas depois dela. A origem deve ser preservada conforme a política de retenção da equipe.

Defina um responsável e uma evidência de execução para cada verificação. Enquanto houver uma falha de permissão ou de validação obrigatória sem tratamento, mantenha o próximo lote suspenso. Esses critérios são uma proposta editorial; não relatam uma migração realizada por Anderson Damasio.

O caso CAP mostra uma estratégia possível, não uma obrigação de trocar de plataforma. A decisão depende do problema que a equipe quer resolver e das capacidades efetivamente disponíveis em seu plano e ambiente. Antes de alterar as integrações de autenticação, consulte também os cuidados com a rotação de segredos OAuth no Azure DevOps.