Nota:
También puede usar ADO2GH extension of the GitHub CLI para realizar la migración. Consulta Descripción de las migraciones de Azure DevOps a GitHub.
Paso 0: Preparación para usar GraphQL API de GitHub
Para realizar consultas de GraphQL, tendrás que escribir scripts propios, o bien usar un cliente HTTP como Insomnia.
Para más información sobre cómo empezar a trabajar con GraphQL API de GitHub, incluido cómo autenticarse, consulta Formar llamados con GraphQl.
Enviarás todas las consultas de GraphQL al destino de tu migración. Si vas a migrar a Nube de GitHub Enterprise con residencia de datos, asegúrate de enviar consultas al punto de conexión del subdominio de la empresa de GHE.com.
Paso 1: Obtención de ownerId para el destino de la migración
Como propietario de la organización en GitHub Enterprise Cloud, usa la consulta GetOrgInfo para devolver ownerId, también denomino id. de organización, para la organización que quieras que posea los repositorios migrados. Necesitarás el valor ownerId para identificar el destino de la migración.
Consulta GetOrgInfo
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
| Variable de consulta | Descripción |
|---|---|
login | El nombre de la organización. |
Respuesta GetOrgInfo
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
En este ejemplo, MDEyOk9yZ2FuaXphdGlvbjU2MTA= es el id. de la organización o ownerId, que se usará en el paso siguiente.
Paso 2: Identificación del origen de la migración
Puedes configurar un origen de migración mediante la consulta createMigrationSource. Tendrás que proporcionar el valor ownerId, o id. de organización, recopilado de la consulta GetOrgInfo.
El origen de la migración es la organización de ADO.
Mutación de createMigrationSource
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
Nota:
Asegúrate de usar AZURE_DEVOPS para type.
| Variable de consulta | Descripción |
|---|---|
name | Nombre para el origen de la migración. Este nombre es para referencia propia, por lo que puedes usar cualquier cadena. |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
Respuesta de createMigrationSource
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "Azure DevOps Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
En este ejemplo, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA es el id. de origen de la migración, que se usará en el paso siguiente.
Paso 3: Inicio de la migración del repositorio
Al iniciar una migración, un único repositorio y sus datos adjuntos se migran a un repositorio nuevo de GitHub que identifiques.
Si quieres mover varios repositorios a la vez desde la misma organización de origen, puedes poner en cola varias migraciones. Puedes ejecutar hasta cinco migraciones de repositorio a la vez.
Mutación de startRepositoryMigration
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$sourceRepositoryUrl: URI!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility,
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
| Variable de consulta | Descripción |
|---|---|
sourceId | El origen de migración id devuelto por la mutación createMigrationSource. |
ownerId | El id. de la organización en GitHub Enterprise Cloud. |
repositoryName | Un nombre de repositorio único personalizado que actualmente no se use en ninguno de los repositorios propiedad de la organización en GitHub Enterprise Cloud. Se creará una incidencia de registro de errores en este repositorio cuando se complete la migración o se haya detenido. |
continueOnError | Valor de migración que permite que continúe al encontrar errores que no hacen que se produzca un error en la migración. Debe ser true o false. Se recomienda encarecidamente establecer continueOnError en true para que la migración continúe a menos que Importer no pueda mover el origen de Git o Importer haya perdido la conexión y no se pueda volver a conectar para completar la migración. |
githubPat | El valor personal access token de la organización de destino en GitHub Enterprise Cloud. |
accessToken | El valor personal access token para el origen. |
targetRepoVisibility | La visibilidad del nuevo repositorio. Debe ser private, public o internal. Si no se establece, el repositorio se migra como privado. |
sourceRepositoryUrl | URL del repositorio de origen, con el formato https://dev.azure.com/{organization}/{project}/_git/{repository}. |
Para obtener los requisitos de personal access token, consulte Administración del acceso.
En el paso siguiente, usarás el id. de migración devuelto por la mutación startRepositoryMigration para comprobar el estado de la migración.
Paso 4: Comprobación del estado de la migración
Para detectar errores de migración y asegurarse de que la migración funciona, puedes comprobar el estado de la migración mediante la consulta getMigration. También puedes comprobar el estado de varias migraciones con getMigrations.
La consulta getMigration devolverá con un estado para que sepas si la migración es queued, in progress, failed o completed. Si se ha producido un error en la migración, en Importer se proporcionará un motivo para el error.
Consulta getMigration
query (
$id: ID!
){
node( id: $id ) {
... on Migration {
id
sourceUrl
migrationSource {
name
}
state
failureReason
}
}
}
| Variable de consulta | Descripción |
|---|---|
id | El valor id de la migración que ha devuelto la mutación startRepositoryMigration. |
Paso 5: Validación de la migración y comprobación del registro de errores
Para finalizar la migración, se recomienda comprobar la incidencia "Registro de migración". Esta incidencia se crea en GitHub en el repositorio de destino.

Por último, se recomienda revisar los repositorios migrados para obtener una comprobación de solidez.