GitHub migra repositorios casi sin pausa, pero solo hacia GHE.com con residencia
Enterprise Live Migrations (ELM) pasó a disponibilidad general el 1 de septiembre de 2026 para trasladar repositorios desde GitHub Enterprise Server (GHES) mientras siguen recibiendo contribuciones durante la mayor parte del proceso. El registro de releases.sh fecha ese cambio de estado y recoge tanto la sincronización continua como el destino: GitHub Enterprise Cloud con residencia de datos, alojado en GHE.com.
La respuesta para una organización que busca reducir el tiempo de corte es, por tanto, condicional: ELM permite mantener activo el origen hasta la fase final, pero no migra hacia una organización ordinaria de GitHub.com. El anuncio de disponibilidad general de GitHub describe un corte de minutos en lugar de días y presenta ELM como complemento de GitHub Enterprise Importer (GEI), especialmente para repositorios críticos y monorepos grandes.
ELM o GitHub Enterprise Importer: la decisión es por repositorio
ELM no sustituye a GEI. Ambos pueden mover repositorios desde GHES a GHE.com, pero responden a perfiles operativos distintos. La ventaja de ELM es reducir la pérdida de acceso durante la migración; a cambio, introduce sincronización continua, más supervisión y un corte que debe iniciarse de forma controlada.
- Si el origen no es GitHub Enterprise Server, esta ruta de ELM no es aplicable.
- Si el destino no es GitHub Enterprise Cloud con residencia de datos en GHE.com, hay que elegir otra herramienta, incluida GEI cuando la ruta sea compatible.
- Si una interrupción convencional es aceptable y el repositorio no plantea problemas de tamaño o complejidad, GEI ofrece la vía más directa.
- Si el repositorio debe continuar recibiendo trabajo durante la copia inicial, o se trata de un monorepositorio que lleva las herramientas convencionales a sus límites, ELM es el candidato específico.
- Si una plataforma combina repositorios críticos y repositorios sencillos, las dos herramientas pueden emplearse en la misma estrategia, asignándolas caso por caso.
Cada ejecución de ELM abarca un solo repositorio. Los equipos, proyectos, políticas y demás configuración de la organización no forman parte de esa unidad de traslado, de modo que deberán reconstruirse o ajustarse en el destino. La reducción del corte no equivale a una migración completa de la empresa.
La sincronización mantiene abierto el origen hasta el corte
ELM comienza con comprobaciones de parámetros, credenciales, conectividad y configuración. Después realiza una carga inicial del repositorio y utiliza webhooks para detectar e incorporar cambios compatibles mientras los desarrolladores continúan trabajando en GHES.
Cuando la carga inicial está lista y el operador decide completar el traslado, comienza el cutover. El repositorio de origen se archiva y queda en modo de solo lectura, se aplican las actualizaciones pendientes y la copia de GHE.com pasa a ser el repositorio activo. Esa fase final concentra la indisponibilidad que el producto reduce; “casi sin pausa” no significa ausencia total de corte.
La sincronización tampoco reproduce cualquier modificación posible. Un cambio que ELM no pueda conciliar o un recurso individual que falle puede dejar diferencias que deben revisarse antes de continuar. El estado general de la migración puede estar preparado para el corte aunque existan fallos concretos, por lo que la decisión de finalizar requiere comprobar el detalle del repositorio y no solo el estado global.
Versiones y preparación que condicionan la migración
La disponibilidad general se publicó para GHES 3.17.18 o posterior dentro de esa rama, 3.18.12+, 3.19.9+, 3.20.3+, 3.21.3+ y 3.22.0+. Hay una cautela operativa: la guía vigente de preparación de ELM asume como mínimos de trabajo 3.17.18, 3.18.12, 3.19.9, 3.20.5 y 3.21.3, y advierte que sus instrucciones pueden no funcionar con parches anteriores.
Para la rama 3.20, esto separa el mínimo anunciado para disponer de ELM del parche que presupone la documentación operativa. Una organización que aún esté en 3.20.3 o 3.20.4 debe tratar la actualización a 3.20.5 como parte de la preparación antes de basar su ejecución en esas instrucciones.
- La instancia de GHES debe utilizar HTTPS, permitir tráfico saliente hacia el destino y tener habilitadas las migraciones en Management Console.
- El operador necesita acceso de administrador del sitio en GHES y debe ser propietario de la empresa de destino en GHE.com.
- La autenticación requiere tokens de acceso personal clásicos en ambos extremos; los tokens de granularidad fina no sirven para esta ruta.
- Los repositorios públicos deben cambiar de visibilidad antes del traslado porque GHE.com no admite repositorios públicos.
- Los activos individuales asociados a versiones no pueden superar 2 GB.
La capacidad paralela también es menor que con GEI debido al tráfico de las actualizaciones en vivo: ELM admite hasta diez migraciones simultáneas desde una instancia de GHES y veinte por empresa de destino. Si varias ejecuciones parten de la misma instancia, todos los comandos deben ejecutarse con el mismo operador y los mismos tokens.
El menor corte desplaza el riesgo hacia la supervisión
Los puntos de fallo más previsibles están en las credenciales, los límites de API, la conectividad y la configuración de las URL. Un token caducado puede pausar la operación; si la instancia pierde contacto con GHE.com, el servicio puede seguir trabajando en el origen sin conocer temporalmente el estado del destino.
El caso más disruptivo es un force push sobre la rama predeterminada mientras la migración está activa. Al reescribir el historial, rompe una sincronización incremental que ELM no puede conciliar; la ejecución debe cancelarse y comenzar de nuevo. Esta restricción exige coordinar a los equipos incluso cuando el repositorio permanece disponible para el trabajo cotidiano.
También hace falta prever la recuperación del corte. Si este falla después de archivar el origen, ELM intenta desarchivarlo; si no lo logra, debe intervenir un administrador del repositorio. Tras recuperar el acceso, el operador puede volver a intentar el corte o cancelar la migración.
Una migración completada todavía deja tareas en GHE.com: verificar los datos, devolver acceso a los usuarios, reasignar la actividad vinculada a identidades provisionales y reconstruir la configuración organizativa excluida. A 4 de septiembre de 2026, la ruta disponible sigue limitada a GHES como origen y GHE.com con residencia de datos como destino; existen planes de ampliarla, pero no se han concretado los siguientes recorridos ni sus fechas.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.