{"meta":{"title":"Migration de votre référentiel avec Enterprise Live Migrations","intro":"Migrez de GitHub Enterprise Server vers GHE.com avec un temps d’arrêt minimal.","product":"Migrations","breadcrumbs":[{"href":"/fr/enterprise-server@3.21/migrations","title":"Migrations"},{"href":"/fr/enterprise-server@3.21/migrations/elm","title":"Migrations dynamiques (GHES vers GHE.com)"},{"href":"/fr/enterprise-server@3.21/migrations/elm/migrate-your-repository","title":"Migrer votre référentiel"}],"documentType":"article"},"body":"# Migration de votre référentiel avec Enterprise Live Migrations\n\nMigrez de GitHub Enterprise Server vers GHE.com avec un temps d’arrêt minimal.\n\n> \\[!NOTE]\n> Enterprise Live Migrations est préversion publique et sujet à changement.\n\n> \\[!TIP] À mesure que vous suivez ce guide, vous pouvez vous référer à [Référence CLI pour les migrations en direct Enterprise](/fr/enterprise-server@3.21/migrations/elm/elm-cli-reference) pour obtenir des informations d’utilisation plus détaillées. Si vous rencontrez des erreurs, consultez [Résolution des problèmes de migrations dynamiques de GitHub Enterprise Server vers GHE.com](/fr/enterprise-server@3.21/migrations/elm/troubleshooting).\n\n## Prerequisites\n\nAssurez-vous que vous êtes prêt pour votre migration. Consultez « [Préparation de votre migration dynamique de GitHub Enterprise Server vers GHE.com](/fr/enterprise-server@3.21/migrations/elm/prepare-for-your-migration) ».\n\n## 1. Créer des jetons d’accès\n\nVous devez vous authentifier avec un personal access token (classic) pour la source et la destination de la migration. Pour obtenir des instructions détaillées, consultez [Gestion de vos jetons d’accès personnels](/fr/enterprise-server@3.21/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).\n\n**Notez les deux jetons**, car vous en aurez besoin à l’étape suivante.\n\n1. Créez un personal access token (classic) sur **GitHub Enterprise Server** avec les périmètres suivants.\n\n   * `repo`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:org_hook`\n\n2. Créez un personal access token (classic) sur **GHE.com** avec les périmètres suivants.\n\n   * `repo`\n   * `workflow`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:enterprise`\n\n3. Si l’authentification unique est appliquée à l’organisation GHE.com cible, autorisez le jeton GHE.com.\n\n## 2. Configurer GitHub Enterprise Server\n\nVous devez définir une configuration sur l’instance avant d’effectuer GitHub Enterprise Server une migration. Ces valeurs de configuration s’appliquent à toutes les ELM migrations. Les développeurs sur GitHub Enterprise Server pourraient connaître un court temps d'arrêt lorsque vous appliquez la nouvelle configuration.\n\n1. Accédez à l’interpréteur de commandes d’administration GitHub Enterprise Server via SSH. Consultez « [Accès à l’interpréteur de commandes d’administration (SSH)](/fr/enterprise-server@3.21/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh) ».\n\n2. Définissez les variables de configuration suivantes avec `ghe-config`.\n\n   Par exemple : `ghe-config app.elm-exporter.enabled true`\n\n   | Variable                                             | Définissez cette valeur sur...                                                                                                                          |\n   | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |\n   | `app.elm-exporter.enabled`                           | `true`                                                                                                                                                  |\n   | `app.elm.internal-webhooks-enabled`                  | `true`                                                                                                                                                  |\n   | `app.elm-exporter.webhooks-loopback-address-enabled` | `true`                                                                                                                                                  |\n   | `secrets.elm-exporter.migration-target-url`          | URL de l’API pour votre entreprise de destination (par exemple : `https://api.octocorp.ghe.com`). N’incluez **pas** de barre oblique finale dans l’URL. |\n   | `secrets.elm-exporter.migration-target-token`        | Jeton d’accès que vous avez créé pour GHE.com.                                                                                                          |\n   | `secrets.elm-exporter.source-token`                  | Jeton d’accès que vous avez créé pour GitHub Enterprise Server.                                                                                         |\n   | `secrets.elm-exporter.source-user`                   | Nom d’utilisateur associé au GitHub Enterprise Server jeton (par exemple : `ghe-admin`).                                                                |\n   | `app.migrations.enabled`                             | Si vous n’avez pas encore activé les migrations sur l’instance, vous devez définir cette valeur `true`sur .                                             |\n\n3. Appliquez la configuration.\n\n   ```shell copy\n   ghe-config-apply\n   ```\n\n## 3. Définir les variables d’environnement requises\n\nLorsque la configuration a été appliquée et avant de démarrer une migration, définissez les variables d’environnement requises. Par exemple:\n\n```shell\nexport API_URL='http://localhost:1738'\n```\n\n> \\[!IMPORTANT] Copiez les valeurs pour `API_URL` et `MIGRATION_MANAGER_HMAC_KEY` mot à mot. Les autres variables sont spécifiques à votre environnement.\n\n| Variable                      | Valeur requise                                                                                                                                          |\n| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| API\\_URL                      | `http://localhost:1738`                                                                                                                                 |\n| MIGRATION\\_MANAGER\\_HMAC\\_KEY | `$(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys)`                                                                                             |\n| MIGRATION\\_TARGET\\_URL        | URL de l’API pour votre entreprise de destination (par exemple : `https://api.octocorp.ghe.com`). N’incluez **pas** de barre oblique finale dans l’URL. |\n| MIGRATION\\_TARGET\\_TOKEN      | Le personal access token (classic) pour GHE.com                                                                                                         |\n\nL’une de ces valeurs peut également être fournie en tant qu’indicateurs CLI sur n’importe quelle `elm` commande, qui prend la priorité sur les variables. Par exemple : `--api-url http://localhost:1738`.\n\n## 4. Créer une migration\n\nCréez une migration en spécifiant les détails du référentiel source et cible.\n`--pat-name` doit être défini comme valeur statique `system-pat`. Les autres valeurs sont des paramètres par défaut spécifiques à votre environnement.\n\n> \\[!NOTE] Il `target-org` peut être nouveau ou existant. Si l’organisation cible n’existe pas déjà, elle est créée pendant la migration. Toutefois, aucun paramètre de l’organisation source n’est migré.\n\n```shell copy\nelm migration create \\\n  --source-org EXISTING-GHES-ORG \\\n  --source-repo EXISTING-GHES-REPO \\\n  --target-org GHEC-ORG \\\n  --target-repo NEW-GHEC-REPO \\\n  --target-api GHEC-API-URL \\\n  --pat-name system-pat\n```\n\nPar exemple:\n\n```shell\nelm migration create \\\n  --source-org my-ghes-org \\\n  --source-repo my-ghes-repo \\\n  --target-org my-dr-org \\\n  --target-repo my-dr-repo \\\n  --target-api $MIGRATION_TARGET_URL \\\n  --pat-name system-pat\n```\n\nIndicateurs facultatifs :\n\n* `--start`: si vous êtes prêt à démarrer la migration immédiatement.\n* `--target-visibility`: les référentiels migrés sont créés avec une visibilité **interne** par défaut, mais vous pouvez spécifier `private`.\n\n### Enregistrer l’ID de migration\n\nVous devez voir une réponse semblable à ce qui suit :\n\n```json\n{\n  \"migrationId\": \"2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9\",\n  \"expiresAt\": \"2026-02-11T21:49:33.619162159Z\"\n}\n```\n\nExportez la `migrationId` variable en tant que variable, car vous en aurez besoin pour les commandes suivantes. Par exemple:\n\n```shell\nexport MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'\n```\n\n## 5. Démarrer la migration\n\nSi vous n’avez pas déjà démarré la migration, démarrez-la maintenant à l’aide de l’ID de migration que vous venez d’enregistrer.\n\n```shell copy\nelm migration start --migration-id $MIGRATION_ID\n```\n\nCela lance les processus de remplissage et de mise à jour dynamique.\nELM collecte désormais des données à partir du référentiel source et surveille les événements webhook pris en charge.\n\n## 6. Surveiller la migration\n\nUne fois la migration démarrée, vous devez voir un nouveau référentiel sur GHE.com. Pendant la migration, vous verrez le dépôt remplir avec une charge initiale de données et recevoir des mises à jour lorsque les développeurs continuent à travailler dans le référentiel source.\n\nExécutez régulièrement la commande suivante pour surveiller l’état de la migration. Vous verrez une répartition des états de la source et de la cible, ainsi que des informations sur les données dynamiques migrées.\n\n```shell copy\nelm migration status --migration-id $MIGRATION_ID\n```\n\nL’indicateur le plus important dans la réponse est l’état de l’objet **combinedState** . Lorsque l’état atteint `COMBINED_STATUS_READY_FOR_CUTOVER`, vous devez être prêt à passer à l’étape suivante. Toutefois, vous serez averti dans le `displayMessage` si des ressources individuelles n'ont pas pu migrer, que vous devrez peut-être examiner.\n\nPar exemple:\n\n```json\n  \"combinedState\":  {\n    \"status\":  \"COMBINED_STATUS_READY_FOR_CUTOVER\",\n    \"displayMessage\":  \"Ready for cutover (1 resources failed)\",\n    \"repositories\":  [\n      {\n        \"repositoryNwo\":  \"new-test-org/my-new-repo\",\n        \"phase\":  \"REPOSITORY_PHASE_READY_FOR_CUTOVER\",\n        \"displayStatus\":  \"Ready for cutover (1 failed)\"\n      }\n    ],\n    \"readyForCutover\":  true,\n    \"cutoverBlockers\":  []\n  },\n```\n\nConseils :\n\n* Si vous exécutez plusieurs migrations, vous pouvez vérifier l’état de toutes ces dernières `elm migration list`. Cette commande affiche les migrations en cours par défaut, mais vous pouvez également filtrer par `--status`.\n* Si vous rencontrez des statuts d'erreur qui nécessitent une attention particulière, consultez [Résolution des problèmes de migrations dynamiques de GitHub Enterprise Server vers GHE.com](/fr/enterprise-server@3.21/migrations/elm/troubleshooting#statuses-and-recommended-actions).\n\n## 7. Terminer la migration\n\nQuand une migration est prête pour la transition, vous pouvez effectuer la migration. Le processus de basculement archivera le référentiel source, le rendant **définitivement en lecture seule**, sauf si un administrateur du référentiel le désarchive.\n\n```shell copy\nelm migration cutover-to-destination --migration-id $MIGRATION_ID\n```\n\nContinuez à surveiller la migration. Lorsque vous voyez l’état `MIGRATION_STATUS_COMPLETED` en haut de la réponse, la migration est terminée, bien qu’il existe des tâches de suivi permettant d’accorder l’accès aux utilisateurs à partir de GitHub Enterprise Server.\n\n## Étapes suivantes\n\nDonnez aux utilisateurs l’accès au nouveau référentiel et rapprochez l’activité avec les comptes d’utilisateur. Consultez « [Fin de votre migration dynamique de GitHub Enterprise Server vers GHE.com](/fr/enterprise-server@3.21/migrations/elm/complete-your-migration) »."}