Introducción a una migración entre productos de GitHub

Información general

Con GitHub Enterprise Importer, puedes realizar migraciones a GitHub Enterprise Cloud. Para más información, consulta "Acerca de GitHub Enterprise Importer".

Si vas a migrar entre entre productos de GitHub (por ejemplo, de GitHub Enterprise Server a GitHub Enterprise Cloud), puedes usar esta guía para planear e implementar la migración y completar tareas de seguimiento. Para obtener una lista completa de las rutas de migración admitidas, consulta "Acerca de GitHub Enterprise Importer".

Planificación de la migración

Para planear la migración, hazte las siguientes preguntas.

• ¿Queremos migrar por organización o por repositorio?
• ¿En qué momento es necesario completar la migración?
• ¿Se sabe qué se va a migrar?
• ¿Quién ejecutará la migración?
• ¿Queremos mantener una estructura de la organización similar después de la migración?

¿Queremos migrar por organización o por repositorio?

En primer lugar, si el origen y el destino de la migración son ambos GitHub.com, decide si quieres migrar por organización o por repositorio.

Si te decantas por una migración por repositorio, solo se migran los datos de nivel de repositorio. Si eliges la estrategia de migración por organización, también se migrarán los datos de nivel de organización seleccionados, incluidos los equipos y su acceso a los repositorios.

Sin embargo, al migrar una organización, todos los repositorios que pertenecen a esa organización de origen se migran al mismo tiempo. Los repositorios no se pueden dividir en lotes ni omitir la migración de ninguno de los repositorios de la organización. Si tienes un gran número de repositorios, o si no puedes permitirte ningún tiempo de inactividad en todos los repositorios al mismo tiempo, posiblemente debas realizar una migración por repositorio en su lugar.

Además, una migración de la organización crea una nueva organización en la cuenta empresarial de destino. Si quieres migrar repositorios a una organización existente, deberás realizar una migración por repositorio en su lugar.

Por último, para migrar organizaciones, debes ser propietario de la empresa de la cuenta empresarial de destino. Si quieres encomendar esta tarea a alguien que no sea propietario de la empresa, la persona designada deberá realizar una migración de repositorios.

¿En qué momento es necesario completar la migración?

Determina la escala de tiempo, que en gran medida determinará el enfoque. El primer paso para determinar la escala de tiempo consiste en obtener un inventario de lo que necesitas migrar. Para recopilar estos datos, usa la gh-repo-stats extensión para GitHub CLI. Esta herramienta de código abierto genera un informe que detalla la cantidad de datos que hay que migrar para una organización.

• Número de repositorios
• Número de solicitudes de incorporación de cambios
• Número de problemas
• Número de usuarios
• Uso de proyectos y wikis

El tiempo de migración se basa en gran medida en el número de problemas y solicitudes de incorporación de cambios de un repositorio. Si quieres migrar 1000 repositorios y cada uno tiene 100 problemas y solicitudes de incorporación de cambios de media y solo 50 usuarios han contribuido a los repositorios, es probable que la migración sea muy rápida. Si solo quieres migrar 100 repositorios, pero cada uno tiene 75 000 cambios y solicitudes de incorporación de cambios de media y 5 000 usuarios, la migración tardará más y requerirá mucha más planificación y pruebas.

Después de usar el analizador, puedes pesar los datos de inventario en la escala de tiempo deseada. Si la organización puede soportar un mayor grado de cambio, es posible que puedas migrar todos los repositorios a la vez, y completar los esfuerzos de migración en unos días. Pero es posible que tengas varios equipos que no se puedan migrar al mismo tiempo. En este caso, es posible que quieras procesar por lotes y escalonar las migraciones para ajustarse a las escalas de tiempo de los equipos, lo que amplía el esfuerzo de migración.

1. Usa la gh-repo-stats extensión para los GitHub CLI y luego revisa el inventario de migración.
2. Para comprender cuándo los equipos pueden estar listos para la migración, entrevista a las partes interesadas.
3. Revisa todo el resto de esta guía y, después, decide una escala de tiempo de migración.

¿Se sabe qué se va a migrar?

Asegúrate de que tú y las partes interesadas entendéis qué datos se pueden migrar mediante GitHub Enterprise Importer.

1. Revisa los datos del origen de migración que se van a migrar. Para obtener más información, vea «Acerca de las migraciones entre productos de GitHub».
2. Haz una lista de los datos que necesitarás migrar o volver a crear manualmente.

¿Quién ejecutará la migración?

Decide quién va a realizar las migraciones y asegúrate de que esta persona tiene el acceso necesario. Las opciones dependerán de si vas a migrar por organización o por repositorio.

Decidir quién va a realizar las migraciones de organización

Para migrar una organización, debes ser propietario de la organización de origen, o bien un propietario de la organización debe concederte el rol de migrador en esa organización.

Asimismo, debes ser propietario de la empresa en la cuenta empresarial de destino. El rol de migrador de las cuentas empresariales no se puede conceder.

1. Confirma que la persona que va a realizar las migraciones es propietario de la empresa de la cuenta empresarial de destino.
2. Si esa persona no es propietaria de la organización de organización de origen, concédele el rol de migrador de la organización. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub». % data reusables.enterprise-migration-tool.confirm-migrator-has-correct-pats %} Para obtener más información, consulta "Administración del acceso para una migración entre productos de GitHub".

Decidir quién va a realizar las migraciones de repositorio

Para migrar un repositorio, debes ser propietario de la organización tanto en la organización de origen como en la de destino. Si no, el propietario de la organización debe concederte el rol de migrador en cada organización en la que no seas propietario.

1. Decide si quieres que un propietario de la organización realice las migraciones, o bien si necesitas conceder el rol de migrador a otra persona.

2. Si decides conceder el rol de migración, decide a qué persona o equipo vas a conceder el rol.

3. Concede el rol de migración a la persona o al equipo. Para obtener más información, consulta "Administración del acceso para una migración entre productos de GitHub."

   Nota: Recuerda conceder el rol de migrador tanto en la organización de origen como en la de destino.

4. Confirma que la persona ha configurado correctamente personal access token para cumplir todos los requisitos de acceso. Para obtener más información, consulta "Administración del acceso para una migración entre productos de GitHub".

¿Queremos mantener una estructura de la organización similar después de la migración?

A continuación, analiza si quieres mantener una estructura organizativa similar después de la migración. Si quieres dividir el esfuerzo de migración en lotes, esto te ayudará a determinar los lotes. Si tienes previsto mantener una correspondencia unívoca entre la organización de origen y la de destino, te recomendamos realizar migraciones por lotes de cada organización. Este es el método más sencillo, especialmente si vas a migrar desde GitHub.com, ya que podrás migrar una organización entera con un solo comando. Si vas a migrar desde otro origen, la GitHub CLI puede generar un script para migrar todos los repositorios de una misma organización.

Si tienes previsto cambiar la estructura organizativa, deberás tener en cuenta otros factores de procesamiento por lotes. Puedes procesar por lotes los repositorios que sean propiedad de equipos similares o de una división empresarial; también puedes procesar por lotes según la organización de destino. Nuestra recomendación es procesar por lotes por equipos siempre que sea posible. Si procesas por lotes por división empresarial u organización de destino, el número de partes interesadas implicadas será mayor, lo que puede dar lugar a plazos de tiempo más breves para las migraciones.

Incluso cambiando la estructura organizativa, puede seguir preparando un script para la migración. Usa el comando de la GitHub CLI y, a continuación, mueve las líneas de cada repositorio a scripts diferentes, según sea necesario.

1. Decide cuál será la nueva organización estructural.
2. Decida si necesitas dividir el esfuerzo de migración en lotes más pequeños.
3. Si es así, decide cómo quieres dividir las migraciones.

Ejecución de las migraciones

Una vez que completes la planificación, puedes iniciar las migraciones reales. Para ayudar a descubrir problemas que podrían ser únicos para la empresa durante y después de la migración, se recomienda encarecidamente realizar ejecuciones de prueba de todas las migraciones. Después de resolver las incidencias detectadas por las ejecuciones de prueba, puedes ejecutar las migraciones de producción.

Las migraciones de prueba ayudan a determinar varios fragmentos críticos de información.

• Si la migración de un repositorio determinado se puede completar correctamente
• Si puedes devolver al repositorio a un estado en el que los usuarios puedan empezar a trabajar correctamente
• Cuánto tiempo tardará una migración en ejecutarse, lo que resulta útil para planear las programaciones de migración y establecer las expectativas de las partes interesadas

Las ejecuciones de prueba no necesitan mucha coordinación del tiempo. GitHub Enterprise Importer nunca necesita tiempo de inactividad para los usuarios de un repositorio que se va a migrar. Pero se recomienda detener el trabajo durante las migraciones de producción para asegurarse de que no se creen datos durante la migración, que después faltarían en el repositorio migrado. Esto no es un problema para las migraciones de prueba, por lo que las ejecuciones de prueba se pueden realizar en cualquier momento. A fin de reducir el tiempo necesario para completar las migraciones de prueba, puedes programar los lotes de las ejecuciones de prueba de manera consecutiva. Después, los usuarios de esos repositorios pueden validar los resultados por su cuenta.

En las migraciones de repositorio, recomendamos crear una organización de prueba para usarla como destino de las migraciones de prueba. Puedes usar una sola organización para todas las ejecuciones de prueba, o bien puedes crear una organización de prueba para cada organización de destino prevista. Considera la posibilidad de incluir -sandbox al final de los nombres de la organización, para aclarar que las organizaciones solo están pensadas para la validación de la migración y no para producción. Puedes eliminar las organizaciones de prueba cuando hayas terminado.

1. Si realizas una migración de repositorio, crea una organización de prueba para las migraciones de prueba.
2. Si la organización de origen usa listas de direcciones IP permitidas, configura la lista para permitir el acceso mediante GitHub Enterprise Importer. Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».
3. Ejecuta las migraciones de prueba.
4. Completa las tareas de seguimiento que se describen a continuación para las migraciones de prueba.
5. Pide a los usuarios que validen los resultados de las migraciones.
6. Resuelve las incidencias detectadas por las migraciones de prueba.
7. Si el destino usa listas de direcciones IP permitidas, configura la lista para permitir el acceso por parte de GitHub Enterprise Importer. Para obtener más información, consulta "Administración del acceso para una migración entre productos de GitHub".
8. Si vas a realizar una migración de repositorio y quieres migrar la configuración de GitHub Advanced Security, habilita GitHub Advanced Security en la organización de destino. Para obtener más información, vea «Administrar la configuración de seguridad y análisis de su organización».
9. Ejecuta las migraciones de producción. Para más información, consulta "Acerca de GitHub Enterprise Importer" o "Migración de organizaciones desde GitHub.com a GitHub Enterprise Cloud".
10. Opcionalmente, elimina la organización de prueba.

Realización de tareas de seguimiento

Después de que finalice cada migración, tendrás que completar algunas tareas adicionales antes de que el repositorio esté listo para funcionar.

• Comprobación del estado de la migración
• Revisión del registro de migración
• Migración de objetos de Git LFS
• Configurar la visibilidad de un repositorio
• Configuración de GitHub Actions
• Configuración de listas de direcciones IP permitidas
• Admnistrar la GitHub Advanced Security
• Activación de webhooks
• Reinstalación de GitHub Apps
• Creación de nuevo de los equipos
• Reclamación de maniquíes

Comprobación del estado de la migración

En primer lugar, compruebe si la migración se realizó correctamente o si fue errónea.

La forma de comprobar el estado de la migración depende de cómo ejecutó la migración.

• Si ejecutó la migración con GitHub CLI, de manera predeterminada, el proceso mostrará si la migración se realizó correctamente o si fue errónea una vez completada la migración. Si la migración fue errónea, se le indicará el motivo para la ejecución errónea.

  Migration completed (ID: RM_123)! State: SUCCEEDED
  

• Si ejecutó la migración con GitHub CLI con el argumento --queue-only opcional, el proceso se cerrará inmediatamente después de poner en cola la migración y no se le indicará si la migración se realizó correctamente o si fue errónea. Puede comprobar el estado de una migración mediante el comando wait-for-migration o revisando el registro de migración.

• Si ejecutó la migración mediante la API de GraphQL, puede consultar los campos state y failureReason en el objeto RepositoryMigration.

Si se la migración fue errónea, el registro de migración puede contener información adicional sobre la causa del error. Para más información, véase Revisión del registro de migración.

Revisión del registro de migración

En primer lugar, revise el registro de migración para cada repositorio migrado. Para obtener más información, vea «Acceso a los registros de migración para GitHub Enterprise Importer».

Si se la migración fue errónea, el registro puede contener información adicional sobre la causa del error.

Si la migración se realizó correctamente, puede haber advertencias en el registro de migración que representan fragmentos específicos de datos (por ejemplo, solicitudes de cambios, problemas o comentarios) que no se migraron o se migraron con notas de precaución.

Para obtener más información sobre cómo reconocer las advertencias de migración, véase "Solución de problemas de la migración con GitHub Enterprise Importer". Después de revisar las advertencias de migración, deberá tomar una decisión sobre si puede aceptar esas advertencias y avanzar.

Migración de objetos de Git LFS

GitHub Enterprise Importer no migra objetos de Git LFS. Si en el repositorio de origen se usan objetos de Git LFS, puedes enviar esos objetos de Git LFS manualmente al repositorio migrado de manera local. Para obtener más información, vea «Duplicar un repositorio».

Configurar la visibilidad de un repositorio

Todos los repositorios se migran como privados y solo el usuario que ha ejecutado la migración y los propietarios de la organización tendrán acceso al repositorio. Si no quieres que el repositorio sea privado, cambia la visibilidad.

• Puedes cambiar la visibilidad de un repositorio en el explorador. Para obtener más información, vea «Configurar la visibilidad de un repositorio».
• Como alternativa, puedes usar GitHub CLI para cambiar la visibilidad del repositorio desde la línea de comandos. Incluso puedse agregar este comando al script que se ha generado para ejecutar las migraciones. Para más información, vea gh repo edit en la documentación de GitHub CLI.

Configuración de GitHub Actions

Si usas GitHub Actions en un repositorio, los flujos de trabajo se migran automáticamente como parte del repositorio de Git.

Durante el proceso de migración, GitHub Actions se deshabilita en todos los repositorios migrados para evitar que los flujos de trabajo se desencadenen por error, pero GitHub Actions se volverá a habilitar cuando la migración finalice.

Si estabas usando ejecutor más grande, ejecutores autohospedados o secretos cifrados, deberás volver a configurarlos.

1. Si usas ejecutores autohospedados, vuelve a configurarlos.

   • Agrega los ejecutores al repositorio, organización o empresa que corresponda. Para obtener más información, vea «Agrega ejecutores auto-hospedados».
   • Para usar ejecutores en el nivel de organización o empresa, actualiza los flujos de trabajo. Para obtener más información, vea «Uso de ejecutores autohospedados en un flujo de trabajo».

2. Si usas ejecutor más grande, vuelve a configurar los ejecutores.

   • Configura grupos de ejecutores para controlar el acceso a los ejecutores. Para obtener más información, vea «Control del acceso a los ejecutores más grandes».
   • Configura tus ejecutor más grande. Para obtener más información, vea «Administración de ejecutores más grandes».
   • Actualiza los flujos de trabajo para que apunten a los ejecutores. Para obtener más información, vea «Ejecución de trabajos en ejecutores más grandes».

3. Vuelve a agregar los secretos cifrados.

   • Para usar el explorador, consulta "Uso de secretos en Acciones de GitHub".
   • Para usar la GitHub CLI, consulta gh secret en la documentación de la GitHub CLI.

4. Vuelve a configurar los entornos. Para obtener más información, vea «Utilizar ambientes para el despliegue».

Configuración de listas de direcciones IP permitidas

Si agregaste los intervalos IP de GitHub Enterprise Importer a la lista de direcciones IP permitidas de la organización de origen o de destino, puedes quitar esas entradas. Si has deshabilitado las restricciones de lista de direcciones IP permitidas del proveedor de identidades para la empresa de destino, ahora puedes volver a habilitarlas.

Para obtener más información, vea «Administración del acceso para una migración entre productos de GitHub».

Admnistrar la GitHub Advanced Security

Si habilitaste GitHub Advanced Security en la organización de destino antes de migrar los repositorios, se habrá migrado la configuración de características individuales. Si no es así, deberás volver a habilitar las características individuales después de la migración. Para obtener más información, vea «Administración de la configuración de seguridad y análisis para el repositorio».

Por cada característica hay que realizar algunos pasos más tras la migración.

Secret scanning

Si se habilita el examen de secretos en el repositorio de destino, se hará un examen de todo el repositorio. Una vez completado el examen, se rellenarán todas las alertas, pero sin estados de corrección.

Puedes usar la API de REST para actualizar las alertas para reflejar las correcciones en el repositorio de origen. Para obtener más información, vea «Puntos de conexión de la API REST para el examen de secretos».

El usuario asociado a estas correcciones actualizadas será el usuario que posee el personal access token que se usó en las llamadas API (y no el usuario que corrigió la alerta en el repositorio de origen), y la fecha asociada a la corrección será la fecha de la llamada API (y no la fecha en que se corrigió la alerta en el repositorio de origen).

Code scanning

GitHub Enterprise Importer no migra alertas de Code scanning. Sin embargo, estas alertas estarán disponibles como datos SARIF en el repositorio de origen, así que puedes usar la API de REST para cargar estos datos en el repositorio de destino. Para obtener más información, vea «Puntos de conexión de la API de REST para el análisis de código».

Las alertas de Code scanning que se rellenan de esta manera diferirán de las alertas originales en el repositorio de origen.

• Las alertas solo incluirán la detección y el estado más reciente de la alerta, no toda la escala de tiempo del repositorio de origen.
• Las alertas solo se identificarán como open o como fixed. Otros estados de corrección (como dismissed y reopened) se perderán.
• La fecha de todos los eventos de la alerta será la fecha de la llamada API, no la fecha en la que cada evento se produjo originalmente en el repositorio de origen.
• Todos los actores, como el creador de alertas, cambiarán al propietario del personal access token usado en la llamada API.

Dependabot alerts

Cuando se habilitan Dependabot alerts y el gráfico de dependencias, las Dependabot alerts se volverán a generar a partir del estado actual de la rama predeterminada. Los estados de corrección de estas alertas no se migran, ni tampoco las alertas anteriores.

Deberás volver a agregar los secretos cifrados de Dependabot. Para obtener más información, vea «Configuración del acceso a registros privados para Dependabot».

Activación de webhooks

Todos los webhooks activos del repositorio de origen se migran, pero estos webhooks migrados estarán deshabilitados de forma predeterminada. Puedes volver a habilitarlos en la configuración del repositorio.

1. Ve a la configuración del repositorio migrado.
2. En la sección "Código y automatización" de la barra lateral, haz clic en Webhooks.
3. A la derecha del webhook que quieras editar, haz clic en Editar.
4. Si estabas usando un token secreto para proteger el webhook, vuelve a agregar el secreto en "Secreto".
5. Al final de la página, selecciona Aplicar.
6. Haga clic en Update Webhook.

Reinstalación de GitHub Apps

Si tienes alguna GitHub Apps instalada en el repositorio de origen, deberás volver a instalarla en el repositorio migrado. Para obtener más información, vea «Instalación de tu propia instancia de GitHub App».

Creación de nuevo de los equipos

Si has migrado por organización, solo tendrás que restablecer la pertenencia a equipos. Si has migrado por repositorio, deberás volver a crear los equipos, conceder a esos equipos acceso a los repositorios y, tras ello, restablecer la pertenencia a equipos.

Creación de nuevo de los equipos en migraciones por organización

Los equipos y su acceso al repositorio se migran como parte de una migración por organización, pero no la pertenencia a equipos. Tras la migración, debes agregar usuarios a los equipos migrados.

Recomendamos encarecidamente usar la sincronización de equipos para administrar la pertenencia a equipos a través del proveedor de identidades (IdP). Para obtener más información, consulta "Configurar el aprovisionamiento de SCIM para los Usuarios Administrados Empresariales" o, si es una empresa que no usa Enterprise Managed Users, "Administración de la sincronización de equipos para organizaciones de su empresa".

Si no, puedes agregar los miembros manualmente a la organización y, luego, agregar miembros de la organización a los equipos. Para obtener más información, vea «Agregar miembros de la organización a un equipo».

Creación de nuevo de los equipos para migraciones por repositorio

Los equipos no se migran como parte de una migración por repositorio. Tendrás que volver a crear los equipos manualmente y conceder acceso al repositorio a cada uno de ellos.

1. Vuelve a crear los equipos. Para obtener más información, vea «Crear un equipo».
2. Agrega miembros de la organización a equipos. Para obtener más información, vea «Agregar miembros de la organización a un equipo».
3. Concede a cada equipo acceso al repositorio. Para obtener más información, vea «Administrar el acceso de equipo a un repositorio de la organización».

Reclamación de maniquíes

Después de ejecutar una migración con GitHub Enterprise Importer, toda la actividad del usuario en el repositorio migrado (excepto las confirmaciones de Git) se atribuye a identidades de marcador de posición denominadas maniquíes.

Puedes reasignar el historial de cada maniquí a un miembro de la organización con la GitHub CLI o en el explorador. Si usas la datos GitHub CLI, puedes reclamar maniquíes de forma masiva. Para más información, consulta "Reclamación de maniquíes para GitHub Enterprise Importer".

1. Decide si quieres reclamar maniquíes.
2. Planifica cuándo completarás las reclamaciones.
3. Reclama los maniquíes.
4. Si alguno de los miembros aún no tiene el acceso adecuado al repositorio por medio de la pertenencia al equipo, concede a los miembros acceso al repositorio. Para obtener más información, vea «Administrar el acceso de una persona a un repositorio de una organización».