{"meta":{"title":"Migrieren Ihres Repositorys mit Enterprise Live-Migrationen","intro":"Migrieren Sie von GitHub Enterprise Server zu GHE.com mit minimalem Ausfall.","product":"Migrationen","breadcrumbs":[{"href":"/de/enterprise-server@3.22/migrations","title":"Migrationen"},{"href":"/de/enterprise-server@3.22/migrations/elm","title":"Livemigrationen (GHES zu GHE.com)"},{"href":"/de/enterprise-server@3.22/migrations/elm/migrate-your-repository","title":"Migrieren Ihres Repositorys"}],"documentType":"article"},"body":"# Migrieren Ihres Repositorys mit Enterprise Live-Migrationen\n\nMigrieren Sie von GitHub Enterprise Server zu GHE.com mit minimalem Ausfall.\n\n> \\[!NOTE]\n> Enterprise Live Migrations ist in Öffentliche Vorschau und kann geändert werden.\n\n> \\[!TIP] Wenn Sie diesem Leitfaden folgen, können Sie sich auf die [CLI-Referenz für Enterprise-Live-Migrationen](/de/enterprise-server@3.22/migrations/elm/elm-cli-reference) beziehen, um detailliertere Nutzungsinformationen zu erhalten. Wenn Fehler auftreten, lesen Sie [Problembehandlung bei Livemigrationen von GitHub Enterprise Server zu GHE.com](/de/enterprise-server@3.22/migrations/elm/troubleshooting).\n\n## Voraussetzungen\n\nStellen Sie sicher, dass Sie für Ihre Migration bereit sind. Siehe [Vorbereiten der Livemigration von GitHub Enterprise Server zu GHE.com](/de/enterprise-server@3.22/migrations/elm/prepare-for-your-migration).\n\n## 1. Erstellen von Zugriffstoken\n\nSie müssen sich mit einem personal access token (classic) sowohl für die Quelle als auch für das Ziel der Migration authentifizieren. Ausführliche Anweisungen findest du unter [Verwalten deiner persönlichen Zugriffstoken](/de/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens#creating-a-personal-access-token-classic).\n\n**Notieren Sie sich beide Token**, da Sie sie im nächsten Schritt benötigen.\n\n1. Erstellen Sie ein personal access token (classic) auf **GitHub Enterprise Server** mit folgenden Bereichen.\n\n   * `repo`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:org_hook`\n\n2. Erstellen Sie ein personal access token (classic) auf **GHE.com** mit folgenden Bereichen.\n\n   * `repo`\n   * `workflow`\n   * `admin:org`\n   * `admin:repo_hook`\n   * `admin:enterprise`\n\n3. Wenn einmaliges Anmelden für die Zielorganisation GHE.comerzwungen wird, autorisieren Sie das GHE.com Token.\n\n## 2. Konfigurieren GitHub Enterprise Server\n\nSie müssen eine Konfiguration für die GitHub Enterprise Server Instanz festlegen, bevor Sie eine Migration durchführen. Diese Konfigurationswerte gelten für alle ELM Migrationen. Entwickler auf GitHub Enterprise Server können eine kurze Ausfallzeit feststellen, wenn Sie die neue Konfiguration anwenden.\n\n1. Greifen Sie über SSH auf die GitHub Enterprise Server Verwaltungsshell zu. Siehe [Auf die Verwaltungsshell (SSH) zugreifen](/de/enterprise-server@3.22/admin/administering-your-instance/administering-your-instance-from-the-command-line/accessing-the-administrative-shell-ssh).\n\n2. Legen Sie die folgenden Konfigurationsvariablen mit `ghe-config` fest.\n\n   Beispiel: `ghe-config app.elm-exporter.enabled true`\n\n   | Variable                                             | Legen Sie dies auf...                                                                                                                 |\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`          | Die API-URL für Ihr Zielunternehmen (z. B.: `https://api.octocorp.ghe.com`). Fügen Sie am Ende der URL **keinen** Schrägstrich hinzu. |\n   | `secrets.elm-exporter.migration-target-token`        | Das Zugriffstoken, für GHE.comdas Sie erstellt haben.                                                                                 |\n   | `secrets.elm-exporter.source-token`                  | Das Zugriffstoken, für GitHub Enterprise Serverdas Sie erstellt haben.                                                                |\n   | `secrets.elm-exporter.source-user`                   | Der dem Token zugeordnete GitHub Enterprise Server Benutzername (z. B.: `ghe-admin`).                                                 |\n   | `app.migrations.enabled`                             | Wenn für die Instanz noch keine Migrationen aktiviert sind, müssen Sie diese Option auf `true` setzen.                                |\n\n3. Wende die Konfiguration an.\n\n   ```shell copy\n   ghe-config-apply\n   ```\n\n## 3. Festlegen erforderlicher Umgebungsvariablen\n\nWenn die Konfiguration angewendet wurde und bevor Sie eine Migration starten, legen Sie erforderliche Umgebungsvariablen fest. Beispiel:\n\n```shell\nexport API_URL='http://localhost:1738'\n```\n\n> \\[!IMPORTANT] Kopieren Sie die Werte für `API_URL` und `MIGRATION_MANAGER_HMAC_KEY` verbatim. Die anderen Variablen sind spezifisch für Ihre Umgebung.\n\n| Variable                      | Erforderlicher Wert                                                                                                                   |\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        | Die API-URL für Ihr Zielunternehmen (z. B.: `https://api.octocorp.ghe.com`). Fügen Sie am Ende der URL **keinen** Schrägstrich hinzu. |\n| MIGRATION\\_TARGET\\_TOKEN      | Die personal access token (classic) für GHE.com                                                                                       |\n\nJeder dieser Werte kann auch als CLI-Flags für jeden `elm` Befehl bereitgestellt werden, der Vorrang vor den Variablen hat. Beispiel: `--api-url http://localhost:1738`.\n\n## 4. Erstellen Sie eine Migration\n\nErstellen Sie eine neue Migration, indem Sie die Quell- und Ziel-Repositorydetails angeben.\n`--pat-name` muss als statischer Wert auf `system-pat` festgelegt werden. Die anderen Werte sind Platzhalter, die für Ihre Umgebung spezifisch sind.\n\n> \\[!NOTE] Dies `target-org` kann neu oder vorhanden sein. Wenn die Zielorganisation noch nicht vorhanden ist, wird sie während der Migration erstellt. Es werden jedoch keine Einstellungen aus der Quellorganisation migriert.\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\nBeispiel:\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\nOptionale Kennzeichnungen:\n\n* `--start`: Wenn Sie bereit sind, die Migration sofort zu starten.\n* `--target-visibility`: Migrierte Repositorys werden standardmäßig mit **interner** Sichtbarkeit erstellt, aber Sie können angeben `private`.\n\n### Speichern der Migrations-ID\n\nEs sollte eine Antwort wie folgt angezeigt werden:\n\n```json\n{\n  \"migrationId\": \"2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9\",\n  \"expiresAt\": \"2026-02-11T21:49:33.619162159Z\"\n}\n```\n\nExportieren Sie die `migrationId` Variable, da Sie sie für die nächsten Befehle benötigen. Beispiel:\n\n```shell\nexport MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9'\n```\n\n## 5. Starten der Migration\n\nWenn Sie die Migration noch nicht gestartet haben, starten Sie sie jetzt mit der soeben gespeicherten Migrations-ID.\n\n```shell copy\nelm migration start --migration-id $MIGRATION_ID\n```\n\nDadurch werden die Backfill- und Liveupdateprozesse gestartet.\nELM erfasst nun Daten aus dem Quell-Repository und lauscht auf unterstützte Webhook-Ereignisse.\n\n## 6. Überwachen der Migration\n\nWenn die Migration gestartet wurde, sollte ein neues Repository GHE.com angezeigt werden. Während der Migration sehen Sie, dass das Repository mit einer anfänglichen Auslastung von Daten gefüllt wird und Updates empfängt, während Entwickler weiterhin im Quell-Repository arbeiten.\n\nFühren Sie den folgenden Befehl regelmäßig aus, um den Migrationsstatus zu überwachen. Es wird eine Aufschlüsselung der Status der Quelle und des Ziels sowie Informationen zu den zu migrierenden Livedaten angezeigt.\n\n```shell copy\nelm migration status --migration-id $MIGRATION_ID\n```\n\nDer wichtigste Indikator in der Antwort ist der Status im **combinedState-Objekt** . Wenn der Status erreicht ist `COMBINED_STATUS_READY_FOR_CUTOVER`, sollten Sie bereit sein, mit dem nächsten Schritt fortzufahren. Sie werden jedoch benachrichtigt`displayMessage`, wenn einzelne Ressourcen nicht migriert werden konnten, die möglicherweise einer Untersuchung bedürfen.\n\nBeispiel:\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\nTipps:\n\n* Wenn Sie mehrere Migrationen ausführen, können Sie den Status aller Migrationen überprüfen.`elm migration list` Dieser Befehl zeigt standardmäßig laufende Migrationen an, Sie können aber auch nach `--status`filtern.\n* Wenn Fehlerstatus auftreten, die Aufmerksamkeit erfordern, siehe [Problembehandlung bei Livemigrationen von GitHub Enterprise Server zu GHE.com](/de/enterprise-server@3.22/migrations/elm/troubleshooting#statuses-and-recommended-actions).\n\n## 7. Abschließen der Migration\n\nWenn eine Migration für die Umstellung bereit ist, können Sie die Migration abschließen. Der Übernahmevorgang archiviert das Quell-Repository und macht es **dauerhaft schreibgeschützt** , es sei denn, ein Repositoryadministrator hebt die Archivierung auf.\n\n```shell copy\nelm migration cutover-to-destination --migration-id $MIGRATION_ID\n```\n\nFahren Sie mit der Überwachung der Migration fort. Wenn der `MIGRATION_STATUS_COMPLETED` Status oben in der Antwort angezeigt wird, ist die Migration abgeschlossen, obwohl es einige Folgeaufgaben gibt, um Benutzern Zugriff von GitHub Enterprise Server zu gewähren.\n\n## Nächste Schritte\n\nGewähren Sie Benutzern Zugriff auf das neue Repository und stimmen Sie Aktivitäten mit Benutzerkonten ab. Siehe [Abschließen der Livemigration von GitHub Enterprise Server zu GHE.com](/de/enterprise-server@3.22/migrations/elm/complete-your-migration)."}