Acho que quase todo mundo que já mexeu com repositório corporativo já ouviu a pergunta: “por que vocês ainda estão no Azure DevOps?”. Eu ouvi isso mais vezes do que gostaria, principalmente em migrar times grandes, cheios de pipelines e histórico, pra GitHub. Só quem já ficou de madrugada rezando pra export de repositório dar certo entende o drama — e o frio na barriga quando alguém pergunta se os pipelines vão quebrar.

Foi por isso que, quando li a notícia do Enterprise Live Migrations entrando em public preview (anunciada no blog oficial do Azure DevOps), parei o que tava fazendo pra entender o que muda de verdade. O papo da vez é migração quase transparente de repositórios do Azure DevOps pro GitHub Enterprise Cloud, com direito a manter data residency (pra quem tem paranoia — ou obrigação! — de compliance). Se você já ficou preso naquele limbo de “como migrar tudo sem parar a empresa”, sabe o alívio que um negócio desses pode trazer.

O que aconteceu

A Microsoft liberou em public preview a funcionalidade chamada Enterprise Live Migrations. O objetivo é permitir que grandes organizações movam seus repositórios do Azure DevOps direto pro GitHub Enterprise Cloud, sem precisar passar por processos manuais cheios de scripts, exportações e aquela bagunça de sincronizar alterações em repositórios que ainda estão ativos.

A novidade aqui não é só migrar o código, mas também migrar tudo de forma minimamente disruptiva. Eles prometem zero downtime e a possibilidade de manter a localização dos dados, o famoso data residency — algo que pega muito para empresas que precisam seguir regulações de onde o código e dados ficam armazenados.

Por que isso importa

O cenário de quem gerencia código-fonte em larga escala sempre foi ingrato quando o assunto era migração entre plataformas. Azure DevOps tem muita empresa gigante antiga, com pipelines, work items, policies, um histórico todo integrado. Migrar pra GitHub, até pouco tempo atrás, era quase um projeto de reengenharia: você até conseguia copiar o repositório, mas perdia histórico de issues, branches, pipelines e — o pior — o time ficava no limbo entre duas ferramentas.

Agora, com a pressão do GitHub acelerando recursos de AI (tipo o Copilot, cada vez mais integrado) e uma experiência de colaboração mais “social” por lá, a Microsoft resolveu investir de verdade em facilitar esse pulo de plataforma. O anúncio mostra que eles entenderam: ninguém quer fazer corte seco ou arrastar a migração por meses. Live migration é a palavra que faltava há anos nesse movimento.

Outro ponto é o data residency. Não é só burocracia — já ouvi de colega que precisou manter tudo em data center europeu por causa de GDPR. Se a migração exigisse mover o código para servidores em regiões diferentes, a dor de cabeça seria enorme, aprovação de compliance então nem se fala. O Enterprise Live Migrations parece desenhado pra aliviar exatamente esse calcanhar de aquiles.

E, claro, tem o lado técnico: sincronização de alterações durante o processo, mapeamento de usuários (Azure AD pra GitHub, alguém se identificando aí?), e integridade dos dados. Esses detalhes, que pra diretoria são invisíveis, pra quem executa o projeto de migração podem ser o que separa sucesso de fiasco. Se a ferramenta realmente lida com tudo isso, já é um salto.

Na prática

Com o Enterprise Live Migrations, o processo fica menos artesanal. Em vez de rodar scripts e torcer para não perder um commit, agora existe um fluxo guiado oficialmente pela própria Microsoft, que permite migrar o repositório de forma incremental e síncrona. Você ativa a funcionalidade, configura o destino no GitHub Enterprise Cloud, e a ferramenta cuida de fazer a primeira cópia — depois vai mantendo as alterações sincronizadas até a virada final.

Pra quem nunca passou pelo pesadelo de “cortar” um repositório ativo, explico: normalmente, você tem que combinar uma janela de downtime, avisar o time todo pra parar de fazer push, rodar scripts de export/import e torcer pra ninguém descobrir um bug só depois. Agora, a ideia é funcionar com algo como:

az devops migration start \
  --source-org "minha-orga-azure" \
  --target-org "minha-orga-github" \
  --repo "superprojeto" \
  --keep-data-residency true

Com esse tipo de comando, a ferramenta inicia a migração sem pedir downtime. Enquanto isso, o time pode continuar trabalhando normalmente no Azure DevOps, e as alterações vão sendo replicadas pro GitHub até você decidir o momento da ativação definitiva. Isso alivia aquele medo clássico de “mas e se alguém fizer um push no meio do processo?”.

Outra coisa interessante é o suporte à manutenção do data residency. Se a empresa tem regra de manter código em determinada região, a migração respeita isso — não joga tudo de qualquer jeito pro data center americano e depois pede desculpa. Pra times de compliance, parece um alívio. Só que, claro, até testar em ambiente real, sempre fico com um pé atrás.

O que eu acho disso

Olha, é uma evolução que demorou. Sempre senti que a Microsoft jogava os clientes de DevOps pra GitHub meio no “se vira aí com o script da comunidade”. Só quem já fez migração em ambiente grande entende o pesadelo que era sincronizar branch, permissionamento e ainda explicar pro time que pipeline teria que ser refeito na unha.

Minha ressalva é: será que a ferramenta realmente cobre todos os casos? No papel, parece lindo, mas na prática, sempre tem aquele workflow customizado, aquele hook ou integração esquisita que não migra direito. Já vi pipeline que rodava trigger de sistema legado e ninguém sabia até dar ruim na sexta-feira 18h.

Outro ponto: quem precisa migrar não quer só código, mas histórico de issues, comentários, reviews, settings. Se a ferramenta só cobre o básico, vai aliviar, mas não elimina todo o retrabalho. Vou esperar relatos do mundo real antes de recomendar como bala de prata, mas é um passo grande.

E aí, alguém já testou o Enterprise Live Migrations? Quero saber se o fluxo realmente aguenta ambiente grande ou se ainda tem pegadinha. Divide sua experiência aí nos comentários.