# Migración de datos a GitHub Enterprise Server

Después de generar un archivo de migración, puede importar los datos a la instancia de destino GitHub Enterprise Server . Podrás revisar los cambios para detectar posibles conflictos antes de aplicar de manera permanente los cambios a tu instancia de destino.

## Preparación de los datos migrados

1. Con el comando [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp), copie el archivo de migración generado de su instancia u organización de origen en su GitHub Enterprise Server destino:

   ```shell
   scp -P 122 PATH-TO-MIGRATION-GUID.tar.gz admin@HOSTNAME:/home/admin/
   ```

2. SSH en la instancia de destino GitHub Enterprise Server . Para más información, consulta [Acceder al shell administrativo (SSH)](/es/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

3. Asegúrate de que el archivo de migración tiene suficientes permisos de lectura.

   ```shell
   chmod 644 /home/admin/MIGRATION-GUID.tar.gz
   ```

4. Usa el comando `ghe-migrator prepare` a fin de preparar el archivo para importar en la instancia de destino y generar un nuevo GUID de migración para usarlo en los pasos siguientes:

   ```shell
   ghe-migrator prepare /home/admin/MIGRATION-GUID.tar.gz
   ```

   * Para comenzar un nuevo intento de importación, vuelva a ejecutar `ghe-migrator prepare` y obtenga un GUID de migración nuevo.
   * Para especificar dónde se deben almacenar provisionalmente los archivos de migración, anexe `--staging-path=/full/staging/path` al comando. Tiene como valor predeterminado `/data/user/tmp`.

## Generar una lista de conflictos de migración

1. Mediante el comando `ghe-migrator conflicts` con el GUID de migración, genere un archivo *conflicts.csv*:

   ```shell
   ghe-migrator conflicts -g MIGRATION-GUID > conflicts.csv
   ```

   * Si no se notifica ningún conflicto, puede importar los datos de forma segura.

2. Si hay conflictos, con el comando [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp), copie *conflicts.csv* en el equipo local:

   ```shell
   scp -P 122 admin@HOSTNAME:conflicts.csv ~/Desktop
   ```

3. Continúe a [Resolución de conflictos de migración o configuración de asignaciones personalizadas](#resolving-migration-conflicts-or-setting-up-custom-mappings).

## Revisar conflictos de migración

1. Con un editor de texto o un [ software de hoja de cálculo compatible con CSV](https://en.wikipedia.org/wiki/Comma-separated_values#Application_support), abra *conflicts.csv*.
2. Con las instrucciones de los ejemplos y las tablas de referencia siguientes, revise el archivo *conflicts.csv* para asegurarse de que al realizar la importación se tomarán las medidas adecuadas.

El archivo *conflicts.csv* contiene un *mapa de migración* de conflictos y acciones recomendadas. Un mapa de migración enumera tanto los datos que se migran desde el origen como la forma en que los datos se aplicarán al destino.

| `model_name`   | `source_url`                                           | `target_url`                                           | `recommended_action` |
| -------------- | ------------------------------------------------------ | ------------------------------------------------------ | -------------------- |
| `user`         | `https://example-gh.source/octocat`                    | `https://example-gh.target/octocat`                    | `map`                |
| `organization` | `https://example-gh.source/octo-org`                   | `https://example-gh.target/octo-org`                   | `map`                |
| `repository`   | `https://example-gh.source/octo-org/widgets`           | `https://example-gh.target/octo-org/widgets`           | `rename`             |
| `team`         | `https://example-gh.source/orgs/octo-org/teams/admins` | `https://example-gh.target/orgs/octo-org/teams/admins` | `merge`              |

Cada fila de *conflicts.csv* proporciona la información siguiente:

| Nombre               | Descripción                                                            |
| -------------------- | ---------------------------------------------------------------------- |
| `model_name`         | El tipo de datos que están siendo modificados.                         |
| `source_url`         | La URL fuente de los datos.                                            |
| `target_url`         | La URL de destino esperada de los datos.                               |
| `recommended_action` | La acción `ghe-migrator` preferida se realizará al importar los datos. |

### Posibles mapeos para cada tipo de registro

Hay varias acciones de asignación diferentes que `ghe-migrator` puede realizar al transferir datos:

| `action`        | Descripción                                                                                                                                                                                                                                                                            | Modelos aplicables                     |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
| `import`        | (predeterminado) Los datos del origen se importan al destino.                                                                                                                                                                                                                          | Todos los tipos de registro            |
| `map`           | En lugar de crear un modelo basado en los datos de origen, se usa un registro existente en el destino. Resulta útil para importar repositorios en una organización existente o asignar identidades de usuario que están en el destino a identidades de usuario que están en el origen. | Usuarios, organizaciones               |
| `rename`        | Los datos del origen se renombran y luego se copian en el destino.                                                                                                                                                                                                                     | Usuarios, organizaciones, repositorios |
| `map_or_rename` | Si el destino existe, asignar a ese destino. De lo contrario, renombrar el modelo importado.                                                                                                                                                                                           | Usuarios                               |
| `merge`         | Los datos del origen se combinan con los datos existentes en el destino.                                                                                                                                                                                                               | Teams                                  |

**Se recomienda encarecidamente que revise el archivo *conflicts.csv* y use `ghe-migrator audit` para asegurarse de que se realizan las acciones adecuadas.** Si todo parece estar bien, puede continuar.

## Resolver conflictos de migración o crear asignaciones personalizadas

Si cree que `ghe-migrator` realizará un cambio incorrecto, puede hacer correcciones y cambiar los datos en *conflicts.csv*. Puede realizar cambios en cualquiera de las filas de *conflicts.csv*.

Por ejemplo, imagine que observa que el usuario `octocat` del origen se asigna a `octocat` en el destino.

| `model_name` | `source_url`                        | `target_url`                        | `recommended_action` |
| ------------ | ----------------------------------- | ----------------------------------- | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/octocat` | `map`                |

Puedes optar por asignar el usuario a un usuario diferente en el destino. Imagine que sabe que `octocat` realmente debería ser `monalisa` en el destino. Puede cambiar la columna `target_url` de *conflicts.csv* para que haga referencia a `monalisa`.

| `model_name` | `source_url`                        | `target_url`                         | `recommended_action` |
| ------------ | ----------------------------------- | ------------------------------------ | -------------------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `map`                |

Como otro ejemplo, si quiere cambiar el nombre del repositorio `octo-org/widgets` a `octo-org/amazing-widgets` en la instancia de destino, cambie `target_url` a `octo-org/amazing-widgets` y `recommend_action` a `rename`.

| `model_name` | `source_url`                                 | `target_url`                                         | `recommended_action` |
| ------------ | -------------------------------------------- | ---------------------------------------------------- | -------------------- |
| `repository` | `https://example-gh.source/octo-org/widgets` | `https://example-gh.target/octo-org/amazing-widgets` | `rename`             |

### Añadir mapeos personalizados

Una situación común durante una migración es que los usuarios migrados tengan diferentes nombres de usuario en el destino que los que tienen en el origen.

Dada una lista de nombres de usuario en el origen y una lista de nombres de usuario en el destino, puedes crear un archivo CSV con asignaciones personalizadas y luego aplicarlo para garantizar que el nombre de usuario y el contenido de cada usuario se atribuyan correctamente al final de la migración.

Puede generar rápidamente un CSV de usuarios que se migran con el formato CSV necesario para aplicar asignaciones personalizadas mediante el comando `ghe-migrator audit`:

```shell
ghe-migrator audit -m user -g MIGRATION-GUID > users.csv
```

Ahora, puede editar ese CSV y escribir la nueva URL para cada usuario que le gustaría asignar o renombrar, y luego actualizar la cuarta columna para tener `map` o `rename` según corresponda.

Por ejemplo, para cambiar el nombre del usuario `octocat` por `monalisa` en el elemento `https://example-gh.target` de destino, tendría que crear una fila con el siguiente contenido:

| `model_name` | `source_url`                        | `target_url`                         | `state`  |
| ------------ | ----------------------------------- | ------------------------------------ | -------- |
| `user`       | `https://example-gh.source/octocat` | `https://example-gh.target/monalisa` | `rename` |

Se puede usar el mismo proceso para crear asignaciones para cada registro que admita asignaciones personalizadas. Para más información, vea [nuestra tabla sobre las posibles asignaciones de registros](#possible-mappings-for-each-record-type).

### Aplicar datos de migración modificados

1. Después de realizar cambios, use el comando [`scp`](https://acloudguru.com/blog/engineering/ssh-and-scp-howto-tips-tricks#scp) para aplicar el archivo *conflicts.csv* modificado (o cualquier otro archivo *.csv* de asignación en el formato correcto) a la instancia de destino:

   ```shell
   scp -P 122 ~/Desktop/conflicts.csv admin@HOSTNAME:/home/admin/
   ```

2. Vuelva a asignar los datos de migración con el comando `ghe-migrator map`, y pase la ruta al archivo *.csv* modificado y al GUID de migración:

   ```shell
   ghe-migrator map -i conflicts.csv -g MIGRATION-GUID
   ```

3. Si el comando `ghe-migrator map -i conflicts.csv -g MIGRATION-GUID` notifica que sigue habiendo conflictos, vuelva a ejecutar el proceso de resolución de conflictos de migración.

## Aplicación de los datos importados en GitHub Enterprise Server

1. SSH en la instancia de destino GitHub Enterprise Server . Para más información, consulta [Acceder al shell administrativo (SSH)](/es/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell
   ssh -p 122 admin@HOSTNAME
   ```

2. Con el comando `ghe-migrator import`, inicie el proceso de importación. Necesitará:

   * El GUID de migración. Para obtener más información, consulte [Preparación de los datos migrados para la importación en GitHub Enterprise Server](#preparing-the-migrated-data).
   * Su personal access token para la autenticación. El personal access token que se usa es solo para la autenticación como administrador de sitio y no requiere ningún ámbito o permisos específicos. Para más información, consulta [Administración de tokens de acceso personal](/es/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens).

   ```shell
   $ ghe-migrator import /home/admin/MIGRATION-GUID.tar.gz -g MIGRATION-GUID -u USERNAME -p TOKEN

   > Starting GitHub::Migrator
   > Import 100% complete /
   ```

   * Para especificar dónde se deben almacenar provisionalmente los archivos de migración, anexe `--staging-path=/full/staging/path` al comando. Tiene como valor predeterminado `/data/user/tmp`.

## Revisar datos de migración

De forma predeterminada, `ghe-migrator audit` devuelve todos los registros. También te permite filtrar los registros por:

* Los tipos de registros.
* El estado de los registros.

Los tipos de registro coinciden con los encontrados en los [datos migrados](/es/enterprise-server@3.22/migrations/using-ghe-migrator/about-ghe-migrator#migrated-data).

## Filtros de tipo de registro

| Tipo de registro                                                | Nombre de filtro              |
| --------------------------------------------------------------- | ----------------------------- |
| Usuarios                                                        | `user`                        |
| Las organizaciones                                              | `organization`                |
| Repositorios                                                    | `repository`                  |
| Teams                                                           | `team`                        |
| Hitos                                                           | `milestone`                   |
| Problemas                                                       | `issue`                       |
| Comentarios de propuestas                                       | `issue_comment`               |
| Solicitudes de incorporación de cambios                         | `pull_request`                |
| Revisiones de solicitudes de extracción                         | `pull_request_review`         |
| Comentarios sobre confirmación de cambios                       | `commit_comment`              |
| Comentarios sobre revisiones de solicitudes de extracción       | `pull_request_review_comment` |
| Lanzamientos                                                    | `release`                     |
| Medidas adoptadas en las solicitudes de extracción o propuestas | `issue_event`                 |
| Ramas protegidas                                                | `protected_branch`            |

## Filtros de estado de registro

| Estado del registro | Descripción                             |
| ------------------- | --------------------------------------- |
| `export`            | El registro se exportará.               |
| `import`            | El registro se importará.               |
| `map`               | El registro será mapeado.               |
| `rename`            | El registro se renombrará.              |
| `merge`             | El registro se fusionará.               |
| `exported`          | El registro se exportó con éxito.       |
| `imported`          | El registro se importó con éxito.       |
| `mapped`            | El registro se asignó con éxito.        |
| `renamed`           | El registro se renombró con éxito.      |
| `merged`            | El registro fue fusionado exitosamente. |
| `failed_export`     | El registro no se pudo exportar.        |
| `failed_import`     | El registro no se pudo importar.        |
| `failed_map`        | El registro no se pudo mapear.          |
| `failed_rename`     | El registro no se pudo renombrar.       |
| `failed_merge`      | El registro no se pudo fusionar.        |

## Filtrar registros auditados

Con el comando `ghe-migrator audit`, puede filtrar según el tipo de registro mediante la marca `-m`. Del mismo modo, puede filtrar por el estado de importación mediante la marca `-s`. El comando tiene este aspecto:

```shell
ghe-migrator audit -m RECORD_TYPE -s STATE -g MIGRATION-GUID
```

Por ejemplo, para ver cada organización y equipo importados con éxito, debes ingresar:

```shell
$ ghe-migrator audit -m organization,team -s mapped,renamed -g MIGRATION-GUID
> model_name,source_url,target_url,state
> organization,https://gh.source/octo-org/,https://ghe.target/octo-org/,renamed
```

**Se recomienda encarecidamente auditar todas las importaciones con errores.** Para hacerlo, introducirá lo siguiente:

```shell
$ ghe-migrator audit -s failed_import,failed_map,failed_rename,failed_merge -g MIGRATION-GUID
> model_name,source_url,target_url,state
> user,https://gh.source/octocat,https://gh.target/octocat,failed
> repository,https://gh.source/octo-org/octo-project,https://ghe.target/octo-org/octo-project,failed
```

Si tiene alguna duda sobre las importaciones con errores, puede ponerse en contacto con nosotros visitando [Soporte técnico para GitHub Enterprise](https://support.github.com).

## Finalización de la importación en GitHub Enterprise Server

Después de que se aplique tu migración a tu instancia destino y la hayas revisado, desbloquearás los repositorios y los borrarás del origen. Antes de eliminar los datos de origen, se recomienda esperar alrededor de dos semanas para asegurarse de que todo funciona de acuerdo con lo esperado.

## Desbloquear repositorios en la instancia de destino

1. SSH en tu instancia de GitHub Enterprise Server. Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para más información, consulta [Acceder al shell administrativo (SSH)](/es/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Desbloquee todos los repositorios importados con el comando `ghe-migrator unlock`. Nececitarás tu GUID de Migración:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```

> \[!WARNING]
> Si el repositorio contiene GitHub Actions flujos de trabajo mediante el `schedule` desencadenador, los flujos de trabajo no se ejecutarán automáticamente después de una importación. Para volver a iniciar los flujos de trabajo programados, suba una confirmación en el repositorio. Para más información, consulta [Eventos que desencadenan flujos de trabajo](/es/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).

## Desbloquear repositorios en el origen

Una vez completada la migración, debe desbloquear los repositorios en el origen.

### Desbloquear repositorios de una organización en GitHub.com

Para desbloquear los repositorios de una organización GitHub.com, enviarás una solicitud `DELETE` al [endpoint de desbloqueo de migración](/es/rest/migrations#unlock-an-organization-repository). Necesitará:

* Tu token de acceso para autenticación
* `id` único de la migración
* El nombre del repositorio a desbloquear

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  -H "Accept: application/vnd.github.wyandotte-preview+json" \
  https://api.github.com/orgs/ORG-NAME/migrations/ID/repos/REPO_NAME/lock
```

### Eliminar repositorios de una organización en GitHub.com

Después de desbloquear los repositorios de la organización GitHub.com, debería eliminar todos los repositorios que haya migrado anteriormente mediante [el endpoint de eliminación de repositorios](/es/enterprise-server@3.22/rest/repos/repos#delete-a-repository). Necesitarás tu token de acceso para la autenticación:

```shell
curl -H "Authorization: Bearer GITHUB_ACCESS_TOKEN" -X DELETE \
  https://api.github.com/repos/ORG-NAME/REPO_NAME
```

### Desbloqueo de repositorios desde una GitHub Enterprise Server instancia

1. SSH en tu instancia de GitHub Enterprise Server. Si la instancia consta de varios nodos, por ejemplo, si la alta disponibilidad o la replicación geográfica están configuradas, utiliza SSH en el nodo principal. Si usas un clúster, puedes utilizar SSH en cualquier nodo. Reemplace HOSTNAME por el nombre de host de la instancia, o el nombre de host o la dirección IP de un nodo. Para más información, consulta [Acceder al shell administrativo (SSH)](/es/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).

   ```shell copy
   ssh -p 122 admin@HOSTNAME
   ```
2. Desbloquee todos los repositorios importados con el comando `ghe-migrator unlock`. Nececitarás tu GUID de Migración:

```shell
$ ghe-migrator unlock -g MIGRATION-GUID
> Unlocked octo-org/octo-project
```