# Migración del repositorio con Enterprise Live Migrations

Migre de GitHub Enterprise Server a GHE.com con un tiempo de inactividad mínimo.

> \[!TIP] A medida que siga esta guía, puede consultar [Referencia de la CLI de Enterprise Live Migrations](/es/enterprise-server@3.19/migrations/elm/elm-cli-reference) para obtener información de uso más detallada. Si se producen errores, consulte [Solución de problemas de migraciones en vivo de GitHub Enterprise Server a GHE.com](/es/enterprise-server@3.19/migrations/elm/troubleshooting).

## Prerequisites

Asegúrese de que los entornos y desarrolladores están listos para la migración. Consulte [Preparación para la migración en vivo desde GitHub Enterprise Server a GHE.com](/es/enterprise-server@3.19/migrations/elm/prepare-for-your-migration).

## 1. Configurar GitHub Enterprise Server

Debe establecer alguna configuración en la GitHub Enterprise Server instancia antes de crear tokens y realizar una migración. Estos valores de configuración se aplican a todas las ELM migraciones.
GitHub Enterprise Server Los desarrolladores pueden experimentar un breve tiempo de inactividad al aplicar la nueva configuración.

1. Acceda al GitHub Enterprise Server shell administrativo mediante SSH. Consulte [Acceder al shell administrativo (SSH)](/es/enterprise-server@3.19/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).
2. Establezca las siguientes variables de configuración con `ghe-config`.

   Por ejemplo: `ghe-config app.elm-exporter.enabled true`

   | Variable                                             | Establézcalo en...                                                                              |
   | ---------------------------------------------------- | ----------------------------------------------------------------------------------------------- |
   | `app.elm-exporter.enabled`                           | `true`                                                                                          |
   | `app.elm.internal-webhooks-enabled`                  | `true`                                                                                          |
   | `app.elm-exporter.webhooks-loopback-address-enabled` | `true`                                                                                          |
   | `secrets.elm-exporter.migration-target-url`          | La dirección URL de API de la empresa de destino (por ejemplo: `https://api.octocorp.ghe.com`). |

**No** incluya una barra diagonal final al final de la dirección URL. |
\| `secrets.elm-exporter.source-user` | Nombre de usuario asociado al token del GitHub Enterprise Server operador. Debe ser su nombre de usuario en GitHub Enterprise Server; si otra persona va a crear este token, el valor aquí debe establecerse en su nombre de usuario. Recomendamos al `ghe-admin` usuario. |

1. Aplique la configuración.

   ```shell copy
   ghe-config-apply
   ```

2. Deje la sesión SSH. Ejecutará el resto de los comandos en una sesión de terminal local.

## 2. Creación de tokens de operador con acceso empresarial

El operador debe autenticarse tanto en la empresa de origen como en la de destino con un personal access token (classic). Para obtener instrucciones sobre cómo crear tokens, consulte [Administración de tokens de acceso personal](/es/enterprise-server@3.19/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).

**Asegúrese de anotar ambos tokens**, ya que los necesitará en el paso siguiente.

1. En **GitHub Enterprise Server**, cree un personal access token (classic) y seleccione el ámbito requerido:

   * `admin:enterprise`

   Usará este token como el **token de origen** al configurar el ELM CLI.

2. En **GHE.com**, cree personal access token (classic) y seleccione los alcances necesarios:

   * `admin:enterprise`
   * `admin:org`

   Utilizará este token como **token de destino** al configurar el ELM CLI.

## 3. Configurar la herramienta ELM de línea de comandos

Ejecutarás la migración desde un terminal local, mediante una extensión del GitHub CLI.

1. Instale el [GitHub CLI](https://cli.github.com/) en su equipo local. Debe usar la versión 2.0 o posterior.

2. Instale la extensión ELM.

   ```shell copy
   gh extension install github/gh-elm
   ```

3. Inicie el Asistente para la instalación para configurar la extensión.

   ```shell copy
   gh elm configure
   ```

4. Siga las instrucciones del Asistente para la instalación, proporcionando las direcciones URL de API (por ejemplo: `https://api.SUBDOMAIN.ghe.com`) para el origen y el destino y los tokens que creó en el paso anterior.

Cualquiera de estos valores también se puede proporcionar como marcas de la CLI en cualquier `gh elm` comando, lo que tendrá prioridad sobre la configuración. Por ejemplo: `--target-url https://api.SUBDOMAIN.ghe.com`.

Este proceso de configuración almacenará las direcciones URL en un archivo de configuración específico de la plataforma en el directorio de configuración del sistema operativo, en `gh-elm/config.json`. Los tokens de acceso se almacenarán de forma segura en el almacenamiento secreto del equipo.

## 4. Configuración de los secretos de migración en vivo

Además de los tokens de operador con acceso empresarial, debe crear un personal access token (classic) para las organizaciones de origen y de destino. Debe repetir estos pasos para cada organización desde la que va a migrar.

### Creación de tokens de acceso

ELM debe autenticarse con un/a personal access token (classic) tanto para el origen como para el destino de la migración. Para obtener instrucciones sobre cómo crear tokens, consulte [Administración de tokens de acceso personal](/es/enterprise-server@3.19/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).

**Asegúrese de anotar estos tokens**, ya que los necesitará en el paso siguiente.

1. Cree un personal access token (classic) en **GitHub Enterprise Server** con los siguientes alcances:

   * `repo`
   * `admin:org`
   * `admin:repo_hook`
   * `admin:org_hook`

   Este es el token de origen.

2. Cree un personal access token (classic) en **GHE.com** con los siguientes alcances:

   * `repo`
   * `workflow`
   * `admin:org`
   * `admin:repo_hook`
   * `admin:enterprise`

   Este es el token de destino.

   > \[!IMPORTANT]
   > Si se aplica el inicio de sesión único en la organización de destino en GHE.com, debe autorizar el GHE.com token para el inicio de sesión único.

### Configure los secretos de su organización ELM

Use los `gh elm config` comandos para establecer los tokens de acceso de origen y de destino:

1. Establezca el token de origen.

   ```shell copy
   gh elm config set-source-pat EXISTING-GHES-ORG
   ```

   Pegue el token de origen en el terminal cuando se le solicite.

2. Establezca el token de destino.

   ```shell copy
   gh elm config set-target-pat EXISTING-GHES-ORG
   ```

   Pegue el token de destino en el terminal cuando se le solicite.

También puede establecer los tokens de forma interactiva, mediante `gh elm config org-tokens EXISTING-GHES-ORG`o en la configuración de la organización en `https://GHES_HOSTNAME/organizations/EXISTING-GHES-ORG/settings/secrets/elm-exporter/`.

## 5. Cree una migración

Cree una nueva migración especificando los detalles del repositorio de origen y de destino.

> \[!NOTE]
> `target-org` puede ser nuevo o existente. Si la organización de destino aún no existe, se creará durante la migración. Sin embargo, no se migrará ninguna configuración de la organización de origen.

```shell copy
gh elm migration create \
  --source-org EXISTING-GHES-ORG \
  --source-repo EXISTING-GHES-REPO \
  --target-org GHEC-ORG \
  --target-repo NEW-GHEC-REPO
```

Por ejemplo:

```shell
gh elm migration create \
  --source-org my-ghes-org \
  --source-repo my-ghes-repo \
  --target-org my-dr-org \
  --target-repo my-dr-repo
```

Marcas opcionales:

* `--start`: si está listo para iniciar la migración de inmediato.
* `--target-visibility`: los repositorios migrados se crean con visibilidad **interna** de forma predeterminada, pero puede especificar `private`.

### Guardar el identificador de migración

Debería ver una respuesta similar a la siguiente:

```json
{
  "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9",
  "expiresAt": "2026-02-11T21:49:33.619162159Z"
}
```

Exporte como `migrationId` una variable, ya que la necesitará para los siguientes comandos. Por ejemplo:

```shell
export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'
```

## 6. Iniciar la migración

Si aún no inició la migración, iníciela ahora con el identificador de migración que acaba de guardar.

```shell copy
gh elm migration start --migration-id $MIGRATION_ID
```

Esto inicia los procesos de reposición y actualización dinámica.
ELM está recopilando ahora datos del repositorio de origen y escuchando los eventos de webhook que se admiten.

## 7. Supervisión de la migración

Cuando se haya iniciado la migración, debería ver un nuevo repositorio en GHE.com. Durante la migración, verá que el repositorio se rellena con una carga inicial de datos y recibe actualizaciones a medida que los desarrolladores siguen trabajando en el repositorio de origen.

Puede supervisar el progreso de la migración de forma interactiva mediante el `watch` comando :

```shell
gh elm migration watch $MIGRATION_ID
```

Esto consultará la API del estado de la migración y mostrará una interfaz de texto que se actualiza automáticamente y refleja el progreso actual.

### Supervisión programática mediante `migration status`

Si desea un estado de migración adecuado para la automatización, use el `status` comando :

```shell copy
gh elm migration status --migration-id $MIGRATION_ID
```

El indicador más importante de la respuesta es el estado del objeto **combinedState** . Cuando el estado alcance `COMBINED_STATUS_READY_FOR_CUTOVER`, debe estar listo para continuar con el paso siguiente. Sin embargo, se le avisará en `displayMessage` si algún recurso individual no se pudo migrar, lo que puede que tenga que investigar.

Por ejemplo:

```json
  "combinedState":  {
    "status":  "COMBINED_STATUS_READY_FOR_CUTOVER",
    "displayMessage":  "Ready for cutover (1 resources failed)",
    "repositories":  [
      {
        "repositoryNwo":  "new-test-org/my-new-repo",
        "phase":  "REPOSITORY_PHASE_READY_FOR_CUTOVER",
        "displayStatus":  "Ready for cutover (1 failed)"
      }
    ],
    "readyForCutover":  true,
    "cutoverBlockers":  []
  },
```

Sugerencias:

* Si ejecuta varias migraciones, puede comprobar el estado de todas ellas con `gh elm migration list`. Este comando muestra las migraciones en curso de forma predeterminada, pero también puede filtrar por `--status`.
* Si encuentra estados de error que requieren atención, consulte [Solución de problemas de migraciones en vivo de GitHub Enterprise Server a GHE.com](/es/enterprise-server@3.19/migrations/elm/troubleshooting#statuses-and-recommended-actions).

## 8. Completar la migración

Cuando una migración esté lista para el cambio final, puede completarla. El proceso de transición archivará el repositorio de origen, lo que lo convierte **en de solo lectura permanentemente** a menos que un administrador del repositorio lo desarchive.

```shell copy
gh elm migration cutover --migration-id $MIGRATION_ID
```

Continúe supervisando la migración. Cuando vea el `MIGRATION_STATUS_COMPLETED` estado en la parte superior de la respuesta, la migración se ha completado, aunque hay algunas tareas de seguimiento para conceder acceso a los usuarios desde GitHub Enterprise Server.

## Pasos siguientes

Proporcione a los usuarios acceso al nuevo repositorio y concilie la actividad con las cuentas de usuario. Consulte [Finalización de la migración en vivo desde GitHub Enterprise Server a GHE.com](/es/enterprise-server@3.19/migrations/elm/complete-your-migration).