# Migrieren Ihres Repositorys mit Enterprise Live-Migrationen Migrieren Sie von GitHub Enterprise Server zu GHE.com mit minimalem Ausfall. > \[!NOTE] > Enterprise Live Migrations ist in Öffentliche Vorschau und kann geändert werden. > \[!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). ## Voraussetzungen Stellen 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). ## 1. Erstellen von Zugriffstoken Sie 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). **Notieren Sie sich beide Token**, da Sie sie im nächsten Schritt benötigen. 1. Erstellen Sie ein personal access token (classic) auf **GitHub Enterprise Server** mit folgenden Bereichen. * `repo` * `admin:org` * `admin:repo_hook` * `admin:org_hook` 2. Erstellen Sie ein personal access token (classic) auf **GHE.com** mit folgenden Bereichen. * `repo` * `workflow` * `admin:org` * `admin:repo_hook` * `admin:enterprise` 3. Wenn einmaliges Anmelden für die Zielorganisation GHE.comerzwungen wird, autorisieren Sie das GHE.com Token. ## 2. Konfigurieren GitHub Enterprise Server Sie 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. 1. 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). 2. Legen Sie die folgenden Konfigurationsvariablen mit `ghe-config` fest. Beispiel: `ghe-config app.elm-exporter.enabled true` | Variable | Legen Sie dies auf... | | ---------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `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` | 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. | | `secrets.elm-exporter.migration-target-token` | Das Zugriffstoken, für GHE.comdas Sie erstellt haben. | | `secrets.elm-exporter.source-token` | Das Zugriffstoken, für GitHub Enterprise Serverdas Sie erstellt haben. | | `secrets.elm-exporter.source-user` | Der dem Token zugeordnete GitHub Enterprise Server Benutzername (z. B.: `ghe-admin`). | | `app.migrations.enabled` | Wenn für die Instanz noch keine Migrationen aktiviert sind, müssen Sie diese Option auf `true` setzen. | 3. Wende die Konfiguration an. ```shell copy ghe-config-apply ``` ## 3. Festlegen erforderlicher Umgebungsvariablen Wenn die Konfiguration angewendet wurde und bevor Sie eine Migration starten, legen Sie erforderliche Umgebungsvariablen fest. Beispiel: ```shell export API_URL='http://localhost:1738' ``` > \[!IMPORTANT] Kopieren Sie die Werte für `API_URL` und `MIGRATION_MANAGER_HMAC_KEY` verbatim. Die anderen Variablen sind spezifisch für Ihre Umgebung. | Variable | Erforderlicher Wert | | ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | API\_URL | `http://localhost:1738` | | MIGRATION\_MANAGER\_HMAC\_KEY | `$(ghe-config secrets.elm-exporter.elm-exporter-hmac-keys)` | | 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. | | MIGRATION\_TARGET\_TOKEN | Die personal access token (classic) für GHE.com | Jeder 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`. ## 4. Erstellen Sie eine Migration Erstellen Sie eine neue Migration, indem Sie die Quell- und Ziel-Repositorydetails angeben. `--pat-name` muss als statischer Wert auf `system-pat` festgelegt werden. Die anderen Werte sind Platzhalter, die für Ihre Umgebung spezifisch sind. > \[!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. ```shell copy elm migration create \ --source-org EXISTING-GHES-ORG \ --source-repo EXISTING-GHES-REPO \ --target-org GHEC-ORG \ --target-repo NEW-GHEC-REPO \ --target-api GHEC-API-URL \ --pat-name system-pat ``` Beispiel: ```shell elm migration create \ --source-org my-ghes-org \ --source-repo my-ghes-repo \ --target-org my-dr-org \ --target-repo my-dr-repo \ --target-api $MIGRATION_TARGET_URL \ --pat-name system-pat ``` Optionale Kennzeichnungen: * `--start`: Wenn Sie bereit sind, die Migration sofort zu starten. * `--target-visibility`: Migrierte Repositorys werden standardmäßig mit **interner** Sichtbarkeit erstellt, aber Sie können angeben `private`. ### Speichern der Migrations-ID Es sollte eine Antwort wie folgt angezeigt werden: ```json { "migrationId": "2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9", "expiresAt": "2026-02-11T21:49:33.619162159Z" } ``` Exportieren Sie die `migrationId` Variable, da Sie sie für die nächsten Befehle benötigen. Beispiel: ```shell export MIGRATION_ID='2b5c9eae-b5da-4306-ab04-2a29cc2b7cb9' ``` ## 5. Starten der Migration Wenn Sie die Migration noch nicht gestartet haben, starten Sie sie jetzt mit der soeben gespeicherten Migrations-ID. ```shell copy elm migration start --migration-id $MIGRATION_ID ``` Dadurch werden die Backfill- und Liveupdateprozesse gestartet. ELM erfasst nun Daten aus dem Quell-Repository und lauscht auf unterstützte Webhook-Ereignisse. ## 6. Überwachen der Migration Wenn 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. Fü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. ```shell copy elm migration status --migration-id $MIGRATION_ID ``` Der 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. Beispiel: ```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": [] }, ``` Tipps: * 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. * 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). ## 7. Abschließen der Migration Wenn 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. ```shell copy elm migration cutover-to-destination --migration-id $MIGRATION_ID ``` Fahren 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ächste Schritte Gewä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).