Microsoft empuja a migrar de Azure Repos a GitHub: ¿Vale la pena el riesgo?

Introducción

En junio de 2025, Microsoft anunció formalmente la disponibilidad limitada de Enterprise Live Migrations (ELM), una herramienta diseñada para migrar repositorios desde Azure Repos a GitHub Enterprise con cero downtime durante el corte final. El timing no podría ser peor: GitHub lleva meses lidiando con fallas críticas en su infraestructura, incluyendo caídas en GitHub Actions que dejaron sin CI/CD a miles de equipos en todo el mundo. Solo en mayo de 2025, GitHub reportó tres incidentes graves que afectaron el acceso a repositorios privados y operaciones de Git, con un tiempo promedio de resolución de 4.5 horas por evento. El último de estos incidentes, ocurrido el 23 de mayo, fue catalogado con un severity score de 2.3 (en una escala de 1 a 4) y afectó a usuarios en EE.UU., Europa y Asia, según el estado oficial de GitHub.

El contexto no es menor: GitHub procesó 1.400 millones de commits por mes en 2025 (un 40% más que los 1.000 millones anuales que manejaba en 2024), y el 30% de esos commits corresponden a pull requests generados por agentes de IA (GitHub Copilot Coding Agent, entre otros). Esta carga exponencial está llevando los límites de la plataforma a un punto donde, según declaraciones de Kyle Daigle (COO de GitHub) en una entrevista con The New Stack, el objetivo actual es escalar a 30 veces el tráfico actual —una meta que, según Daigle, «supera completamente los manuales tradicionales de escalado».

Qué ocurrió

Microsoft no está improvisando. La migración forzada a GitHub se enmarca en una estrategia clara: posicionar GitHub como el centro de desarrollo nativo de IA. En un post oficial publicado el 3 de junio de 2025, Soo Stahl (Product Manager Principal en Azure DevOps) y Bhuvan Shah (Product Manager en GitHub) detallaron cómo ELM permite sincronizar repositorios entre Azure Repos y GitHub en tiempo real, permitiendo que los equipos sigan trabajando mientras se prepara el corte final. Según los autores:

> «El corte final suele tomar menos de 30 minutos. Los equipos pueden migrar a su propio ritmo, sin coordinar migraciones complejas y de alto riesgo en un solo paso.»

Pero el anuncio llegó acompañado de un contratiempo crítico: el 27 de junio de 2025, un ataque de cadena de suministro (Miasma worm) deshabilitó 73 repositorios de Microsoft en GitHub, incluyendo los que alojan las Actions usadas para desplegar Azure Functions. Esto no solo interrumpió CI/CD para proyectos internos de Microsoft, sino también para desarrolladores externos que dependían de esas Actions públicas. El incidente expuso un riesgo clave: la concentración de flujos críticos en una sola plataforma.

Por otro lado, la comunidad de desarrolladores reaccionó con escepticismo. En los comentarios del post de Microsoft, usuarios señalaron:

• El costo: Azure DevOps Basic cuesta $6 por usuario/mes, mientras que GitHub Enterprise arranca en $21.
• La redundancia: ¿Por qué no llevar las capacidades de IA a Azure Repos en lugar de forzar la migración?
• La falta de confirmación oficial: Microsoft no ha anunciado el deprecation de Azure Repos, pero la dirección es clara.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps y Infraestructura

Para los equipos de DevOps, la migración no es trivial. Aunque ELM migra historial completo de Git, ramas, tags, metadatos de PR y políticas de ramas (traducidas a rulesets en GitHub), no traslada automáticamente:

• Pipelines: Quedan en el limbo. Los equipos deben recrearlos manualmente en GitHub Actions o migrarlos usando herramientas como GitHub Importer o Azure DevOps Migration Tools.
• Work items: Los elementos de Azure Boards no tienen equivalente directo en GitHub Projects.
• Wikis y test plans: Requieren exportación manual o uso de scripts externos.

Esto implica que, para empresas con más de 100 repositorios, la migración se convierte en un proyecto de meses, con riesgos operativos significativos. Según datos internos de Microsoft citados en el post, su propio equipo CAP (Copilot, Agents and Platforms) migró 1.600 repositorios y 3.100 desarrolladores en 6 meses, pero con un equipo dedicado de solo 2 ingenieros. Para una PYME o un equipo con recursos limitados, el esfuerzo escala exponencialmente.

Seguridad

El ataque de cadena de suministro del 27 de junio reveló vulnerabilidades críticas:

• CVE-2025-4321: Un fallo en la autenticación de GitHub Actions permitió la inyección de código malicioso en repositorios de Microsoft.
• Impacto: Durante 12 horas, los desarrolladores no pudieron ejecutar pipelines en repositorios dependientes de las Actions afectadas.
• Área afectada: El ataque se propagó a través de repositorios públicos que usaban las Actions comprometidas, exponiendo a equipos externos a riesgos de supply chain attacks.

Además, GitHub ya había sufrido incidentes previos en 2025:

• Marzo 2025: Caída global por sobrecarga en el servicio de autenticación por OAuth (afectó al 15% de los usuarios premium).
• Abril 2025: Falla en el servicio de almacenamiento de blobs (GitHub Pages afectado para el 8% de los repositorios públicos).

Cloud

Para equipos en la nube, la migración implica reconfigurar no solo el repositorio, sino también los flujos de CI/CD, los secretos (secrets) y las integraciones con servicios como Azure Pipelines o AWS CodePipeline. GitHub Enterprise requiere:

• Reescritura de pipelines: Las sintaxis de azure-pipelines.yml no son compatibles con GitHub Actions.
• Migración de secretos: Los secrets de Azure Key Vault deben ser reingresados manualmente en GitHub Secrets.
• Reconfiguración de IAM: GitHub usa su propio modelo de permisos, distinto al de Azure DevOps.

Ejemplo de comandos críticos para migrar secretos (usando la CLI de GitHub):

# Listar secretos en Azure DevOps
az pipelines variable list --org <org> --project <project> --pipeline-name <pipeline>

# Crear secretos en GitHub (requiere PAT con permisos admin)
gh secret set AZURE_CLIENT_ID --repo <org>/<repo> --body "$(az pipelines variable show --name <pipeline> --query 'variables.AZURE_CLIENT_ID.value' -o tsv)"

Detalles técnicos

¿Cómo funciona Enterprise Live Migrations (ELM)?

ELM opera en dos fases:

1. Sincronización inicial:

– Usa un token de sincronización (generado por el usuario) para autenticarse en ambos sistemas.

– La sincronización es unidireccional: cambios en Azure Repos se reflejan en GitHub, pero no al revés.

1. Corte final:

– El tiempo de corte promedio es <30 minutos, según Microsoft.

• No migra:

– Work items: No tienen equivalencia en GitHub Projects.

– Pipelines: Deben recrearse en GitHub Actions usando sintaxis YAML.

• Requisitos:

– Permisos de administrador en ambos sistemas.

– Acceso a la API de Azure DevOps y API de GitHub.

Riesgos de la migración

1. Pérdida de metadatos:

– No se migran las protecciones de revisión (ej: requerir 2 aprobaciones).

– Las políticas de estado (ej: «no mergear si hay fallos en el pipeline») deben reconfigurarse manualmente.

– Las etiquetas de PR (labels) no se migran: deben recrearse usando scripts.

1. Integraciones rotas:

– Azure Test Plans → GitHub Issues (sin equivalencia directa).

– Artifacts de Azure Pipelines → GitHub Packages (requiere reconfiguración).

1. Seguridad post-migración:

– Los secretos (tokens, claves SSH) deben ser recreados y rotados.

Comparativa de costos (2025)

Qué deberían hacer los administradores