Ausführen der Testausführungsmigration

Ihr Team ist nun bereit, mit dem Prozess des Startens einer Testausführung Ihrer Migration und schließlich einer vollständigen Produktionsmigration zu beginnen. In dieser Phase besprechen wir die letzten Schritte, um eine Migration zusätzlich zu anderen Aufgaben in die Warteschlange zu stellen, die normalerweise am Ende des Migrationsprojekts stehen.

Voraussetzungen

Schließen Sie die Vorbereitungstestausführungsphase ab, bevor Sie mit einer Testausführungsmigration beginnen.

Überprüfen einer Sammlung

Überprüfen Sie jede Sammlung, die Sie zu Azure DevOps Services migrieren möchten. Der Validierungsschritt untersucht verschiedene Aspekte Ihrer Sammlung, einschließlich, aber nicht beschränkt auf, Größe, Sortierung, Identität und Prozesse.

Führen Sie die Überprüfung mithilfe des Datenmigrationstools aus.

1. Laden Sie das Datenmigrationstool herunter.

2. Kopieren Sie die ZIP-Datei auf eine Ihrer Azure DevOps Server-Anwendungsebenen.

3. Entzippen Sie die Datei. Sie können das Tool auch von einem anderen Computer ausführen, ohne Azure DevOps Server installiert zu haben, solange der Computer eine Verbindung mit der Konfigurationsdatenbank der Azure DevOps Server-Instanz herstellen kann.

4. Öffnen Sie ein Eingabeaufforderungsfenster auf dem Server, und geben Sie einen CD-Befehl ein, um in das Verzeichnis zu wechseln, in dem das Datenmigrationstool gespeichert ist. Nehmen Sie sich einen Moment Zeit, um den Hilfeinhalt für das Tool zu überprüfen.

   a. Führen Sie den folgenden Befehl aus, um die Hilfe und Anleitungen der obersten Ebene anzuzeigen.

    Migrator /help
   

   b. Zeigen Sie den Hilfetext für den Befehl an.

    Migrator validate /help 
   

5. Wenn Sie eine Sammlung zum ersten Mal überprüfen, sollte der Befehl die folgende einfache Struktur aufweisen.

    Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}
   

   Wenn {name} der Name Ihres Microsoft Entra-Mandanten bereitgestellt wird, z. B. für die DefaultCollection und den Fabrikam-Mandanten , würde der Befehl wie im folgenden Beispiel aussehen.

    Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}
   

6. Zum Ausführen des Tools auf einem anderen Computer als dem Azure DevOps Server benötigen Sie den Parameter /connectionString. Der Verbindungszeichenfolgenparameter verweist auf Ihre Azure DevOps Server Konfigurationsdatenbank. Wenn beispielsweise der überprüfte Befehl von der Fabrikam Corporation ausgeführt wird, würde der Befehl wie folgt aussehen.

    Migrator validate /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"
   

   Wichtig

   Das Datenmigrationstool bearbeitet keine Daten oder Strukturen in der Sammlung. Die Sammlung wird nur gelesen, um Probleme zu identifizieren.

7. Nach Abschluss der Überprüfung können Sie die Protokolldateien und Ergebnisse anzeigen.

   

   Während der Überprüfung erhalten Sie eine Warnung, wenn einige Ihrer Pipelines Aufbewahrungsregeln pro Pipeline enthalten. Azure DevOps Services verwendet ein projektbasiertes Aufbewahrungsmodell und unterstützt keine Aufbewahrungsrichtlinien pro Pipeline. Wenn Sie mit der Migration fortfahren, werden die Richtlinien nicht an die gehostete Version übertragen. Stattdessen gelten die standardmäßigen Aufbewahrungsrichtlinien auf Projektebene. Bewahren Sie Builds wichtig auf, um deren Verlust zu vermeiden.

Nachdem alle Überprüfungen bestanden haben, können Sie zum nächsten Schritt des Migrationsprozesses wechseln. Wenn das Datenmigrationstool Fehler kennzeichnet, korrigieren Sie sie, bevor Sie fortfahren. Anleitungen zum Beheben von Überprüfungsfehlern finden Sie unter "Behandeln von Migrations- und Migrationsfehlern".

Importieren von Protokolldateien

Wenn Sie das Protokollverzeichnis öffnen, bemerken Sie möglicherweise mehrere Protokollierungsdateien.

Die Standard Protokolldatei heißt DataMigrationTool.log. Es enthält Details zu allem, was ausgeführt wurde. Damit Sie sich leichter auf bestimmte Bereiche konzentrieren können, generiert ein Protokoll für jeden wichtigen Überprüfungsvorgang.

Wenn TfsMigrator beispielsweise einen Fehler im Schritt "Projektprozesse überprüfen" meldet, können Sie die Datei ProjectProcessMap.log öffnen, um alles anzuzeigen, was für diesen Schritt ausgeführt wurde, anstatt durch das gesamte Protokoll scrollen zu müssen.

Überprüfen Sie die TryMatchOobProcesses.log Datei nur, wenn Sie versuchen, Ihre Projektprozesse zu migrieren, um das geerbte Modell zu verwenden. Wenn Sie das geerbte Modell nicht verwenden möchten, können Sie diese Fehler ignorieren, da sie nicht daran hindern, in Azure DevOps Services zu importieren. Weitere Informationen finden Sie in der Überprüfungsphase der Migration.

Generieren von Migrationsdateien

Das Datenmigrationstool hat die Sammlung überprüft und gibt ein Ergebnis von "Alle bestandenen Sammlungsüberprüfungen" zurück. Bevor Sie eine Sammlung offline schalten, um sie zu migrieren, generieren Sie die Migrationsdateien. Wenn Sie den prepare Befehl ausführen, generieren Sie zwei Migrationsdateien:

• IdentityMapLog.csv: Beschreibt Ihre Identitätszuordnung zwischen Active Directory und Microsoft Entra ID.
• migration.json: Erfordert, dass Sie die Migrationsspezifikation ausfüllen, die Sie zum Starten der Migration verwenden möchten.

Befehl "Vorbereiten"

Der prepare Befehl unterstützt das Generieren der erforderlichen Migrationsdateien. Im Wesentlichen durchsucht dieser Befehl die Sammlung, um eine Liste aller Benutzer zu finden, um das Identitätszuordnungsprotokoll aufzufüllen, IdentityMapLog.csv, und versucht dann, eine Verbindung mit Microsoft Entra ID herzustellen, um die Übereinstimmung der einzelnen Identitäten zu finden. Dazu muss Ihr Unternehmen das Microsoft Entra Connect-Tool (früher als Verzeichnissynchronisierungstool, Verzeichnissynchronisierungstool oder DirSync.exe Tool bezeichnet) verwenden.

Wenn die Verzeichnissynchronisierung eingerichtet ist, sollte das Datenmigrationstool die übereinstimmenden Identitäten finden und sie als "Aktiv" markieren. Wenn keine Übereinstimmungen vorhanden sind, wird die Identität im Identitätszuordnungsprotokoll als "Historisch " markiert, daher müssen Sie untersuchen, warum der Benutzer nicht in der Verzeichnissynchronisierung enthalten ist. Die Migrationsspezifikationsdatei migration.json sollte vor der Migration ausgefüllt werden.

validate Im Gegensatz zum Befehl prepare ist eine Internetverbindung erforderlich, da eine Verbindung mit der Microsoft Entra-ID hergestellt werden muss, um die Identitätszuordnungsprotokolldatei aufzufüllen. Wenn Ihre Azure DevOps Server-Instanz keinen Internetzugang hat, führen Sie das Tool von einem Computer aus aus, der ausgeführt wird. Solange Sie einen Computer mit einer Intranetverbindung mit Ihrem Azure DevOps Server instance und einer Internetverbindung finden, können Sie diesen Befehl ausführen. Wenn Sie Hilfe zum prepare Befehl benötigen, führen Sie den folgenden Befehl aus:

Migrator prepare /help

In der Hilfedokumentation finden Sie Anweisungen und Beispiele für die Ausführung des Migrator Befehls über den Azure DevOps Server instance selbst und einen Remotecomputer. Wenn Sie den Befehl über eine der Anwendungsebenen der Azure DevOps Server instance ausführen, sollte Ihr Befehl die folgende Struktur aufweisen:

Migrator prepare /collection:{collection URL} /tenantDomainName:{name} /region:{region}

Migrator prepare  /collection:{collection URL} /tenantDomainName:{name} /region:{region} /connectionString:"Data Source={sqlserver};Initial Catalog=Configuration;Integrated Security=True"

Der connectionString-Parameter ist ein Zeiger auf die Konfigurationsdatenbank Ihres Azure DevOps Server instance. Wenn beispielsweise die Fabrikam Corporation den prepare Befehl ausführt, sieht der Befehl wie im folgenden Beispiel aus:

Migrator prepare /collection:http://fabrikam:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region} /connectionString:"Data Source=fabrikam;Initial Catalog=Configuration;Integrated Security=True"

Wenn das Datenmigrationstool den prepare Befehl ausführt, wird eine vollständige Überprüfung ausgeführt, um sicherzustellen, dass sich seit der letzten vollständigen Überprüfung nichts mit Ihrer Sammlung geändert hat. Wenn neue Probleme erkannt werden, werden keine Migrationsdateien generiert.

Kurz nach dem Ausführen des Befehls wird ein Microsoft Entra-Anmeldefenster angezeigt. Melden Sie sich mit einer Identität an, die zur Mandantendomäne gehört, die im Befehl angegeben ist. Stellen Sie sicher, dass der angegebene Microsoft Entra-Mandant der ist, mit dem Ihre zukünftige Organisation gesichert werden soll. In unserem Fabrikam-Beispiel gibt ein Benutzer Anmeldeinformationen ein, die dem folgenden Beispielfoto ähneln.

Wichtig

Verwenden Sie keinen Microsoft Entra-Testmandanten für eine Testmigration und Ihren Microsoft Entra-Produktionsmandanten für die Produktionsausführung. Die Verwendung eines Microsoft Entra-Testmandanten kann zu Identitätsmigrationsproblemen führen, wenn Sie mit dem Microsoft Entra-Produktionsmandanten Ihrer Organisation beginnen.

Wenn Sie den prepare Befehl erfolgreich im Datenmigrationstool ausführen, zeigt das Ergebnisfenster eine Reihe von Protokollen und zwei Migrationsdateien an. Suchen Sie im Protokollverzeichnis nach einem Protokollordner und zwei Dateien:

• migration.json ist die Migrationsspezifikationsdatei. Es wird empfohlen, sich Zeit zu nehmen, ihn auszufüllen.
• IdentityMapLog.csv enthält die generierte Zuordnung von Active Directory zu Microsoft Entra-Identitäten. Überprüfen Sie sie auf Vollständigkeit, bevor Sie eine Migration starten.

Die beiden Dateien werden in den nächsten Abschnitten ausführlicher beschrieben.

Die Migrationsspezifikationsdatei

Die Migrationsspezifikation migration.json ist eine JSON-Datei, die Migrationseinstellungen bereitstellt. Sie enthält den gewünschten organization Namen, Speicherkontoinformationen und andere Informationen. Die meisten Felder werden automatisch aufgefüllt, und einige Felder erfordern Ihre Eingabe, bevor Sie eine Migration versuchen.

Die angezeigten Felder und erforderlichen Aktionen der migration.json Datei werden in der folgenden Tabelle beschrieben:

Feld	BESCHREIBUNG	Erforderliche Maßnahme
Quelle	Informationen zum Speicherort und den Namen der Quelldatendateien, die für die Migration verwendet werden.	Keine Aktion erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
Standort	Der Shared Access Signature-Schlüssel für das Azure-Speicherkonto, das das Datenebenenanwendungspaket (DACPAC) hostet.	Keine Aktion erforderlich. Dieses Feld wird in einem späteren Schritt behandelt.
Dateien	Die Namen der Dateien, die Migrationsdaten enthalten.	Keine Aktion erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
DACPAC	Eine DACPAC-Datei, die die Sammlungsdatenbank verpackt, die verwendet werden soll, um die Daten während der Migration einzubringen.	Keine Aktion erforderlich. In einem späteren Schritt erstellen Sie diese Datei mithilfe Ihrer Sammlung und laden sie dann in ein Azure-Speicherkonto hoch. Aktualisieren Sie die Datei basierend auf dem Namen, den Sie verwenden, wenn Sie sie später in diesem Prozess generieren.
Ziel	Eigenschaften der neuen Organisation, in die die Migration erfolgt.	Keine Aktion erforderlich. Überprüfen Sie die Informationen zu den zu befolgenden Unterfeldaktionen.
Name	Der Name der Organisation, die während der Migration erstellt werden soll.	Geben Sie einen Namen ein. Der Name kann später nach Abschluss der Migration schnell geändert werden. HINWEIS: Erstellen Sie vor dem Ausführen der Migration keine Organisation mit diesem Namen. Die Organisation wird als Teil des Migrationsprozesses erstellt.
ImportType	Der Typ der Migration, die Sie ausführen möchten.	Keine Aktion erforderlich. Wählen Sie in einem späteren Schritt den Typ der auszuführenden Migration aus.
Validierungsdaten	Informationen, die erforderlich sind, um Ihre Migrationserfahrung zu fördern.	Das Datenmigrationstool generiert den Abschnitt "ValidationData". Es enthält Informationen, die Ihnen helfen sollen, Ihre Migrationserfahrung zu fördern. Bearbeiten Sie die Werte in diesem Abschnitt nicht, oder Die Migration kann nicht gestartet werden.

Nachdem Sie den vorherigen Prozess abgeschlossen haben, sollten Sie eine Datei haben, die wie im folgenden Beispiel aussieht.

In der vorherigen Abbildung hat der Planer der Fabrikam-Migration den Namen fabrikam-import und ausgewählte CUS (Central USA) als geografischer Standort für die Migration hinzugefügt. Andere Werte wurden so belassen, dass geändert werden soll, bevor der Planer die Sammlung für die Migration offline geschaltet hat.

Hinweis

Testlaufimporte haben automatisch einen "-dryrun" am Ende des Organisationsnamens angefügt, den Sie nach der Migration ändern können.

Unterstützte Azure-Regionen für die Migration

Azure DevOps Services ist an mehreren geografischen Standorten in Azure verfügbar. Aber nicht alle Standorte, an denen Azure DevOps Services verfügbar ist, werden für die Migration unterstützt. In der folgenden Tabelle sind die geografischen Azure-Standorte aufgeführt, die Sie für die Migration auswählen können. Außerdem ist der Wert enthalten, den Sie in der Migrationsspezifikationsdatei platzieren müssen, um diese Geografie für die Migration zu verwenden.

Geografischer Standort	Geografischer Azure-Standort	Importspezifikationswert
USA	Zentrale USA	CUS
Europa	Europa, Westen	WEU
United Kingdom	Vereinigtes Königreich, Süden	UKS
Australien	Australien (Osten)	EAU
Südamerika	Brasilien Süd	SBR
Asien-Pazifik	Indien (Süden)	NI
Asien-Pazifik	Asien, Südosten (Singapur)	SEA
Canada	Kanada, Mitte	CC

Das Identitätszuordnungsprotokoll

Das Identitätszuordnungsprotokoll ist für die tatsächlichen Daten, die Sie zu Azure DevOps Services migrieren, von gleicher Bedeutung. Während Sie die Datei überprüfen, ist es wichtig zu verstehen, wie die Identitätsmigration funktioniert und welche potenziellen Ergebnisse sich ergeben könnten. Wenn Sie eine Identität migrieren, kann sie entweder aktiv oder historisch werden. Aktive Identitäten können sich bei Azure DevOps Services anmelden, historische Identitäten können jedoch nicht.

Aktive Identitäten

Aktive Identitäten beziehen sich auf Benutzeridentitäten in Azure DevOps Services nach der Migration. In Azure DevOps Services werden diese Identitäten lizenziert und im organization als Benutzer angezeigt. Die Identitäten werden in der Identitätszuordnungsprotokolldatei in der Spalte Erwarteter Importstatus als aktiv markiert.

Historische Identitäten

Historische Identitäten werden als solche in der Spalte Erwarteter Importstatus in der Identitätszuordnungsprotokolldatei zugeordnet. Identitäten ohne Zeileneintrag in der Datei werden ebenfalls historisch. Ein Beispiel für eine Identität ohne Zeileneintrag kann ein Mitarbeiter sein, der nicht mehr in einem Unternehmen arbeitet.

Im Gegensatz zu aktiven Identitäten, historische Identitäten:

• Nach der Migration haben Sie keinen Zugriff auf eine organization.
• Sie verfügen nicht über Lizenzen.
• Werden Sie nicht als Benutzer im organization angezeigt. Es bleibt nur die Vorstellung des Namens dieser Identität im organization erhalten, damit derEn Verlauf später durchsucht werden kann. Es wird empfohlen, historische Identitäten für Benutzer zu verwenden, die nicht mehr im Unternehmen arbeiten oder keinen weiteren Zugriff auf die Organisation benötigen.

Hinweis

Nachdem eine Identität als Verlauf importiert wurde, kann sie nicht aktiv werden.

Grundlegendes zur Identitätszuordnungsprotokolldatei

Die Identitätszuordnungsprotokolldatei ähnelt dem hier gezeigten Beispiel:

Die Spalten in der Identitätszuordnungsprotokolldatei werden in der folgenden Tabelle beschrieben:

Sie und Ihr Microsoft Entra-Administrator müssen Benutzer untersuchen, die als "Keine Übereinstimmung gefunden" gekennzeichnet sind (Microsoft Entra ID Sync überprüfen), um zu verstehen, warum sie nicht Teil Ihrer Microsoft Entra Connect-Synchronisierung sind.

Spalte	BESCHREIBUNG
Active Directory: Benutzer (Azure DevOps Server)	Der Anzeigename, der von der Identität in Azure DevOps Server verwendet wird. Dieser Name erleichtert die Identifizierung, auf welchen Benutzer die Zeile in der Karte verweist.
Active Directory: Sicherheitsbezeichner	Der eindeutige Bezeichner für die lokales Active Directory Identität in Azure DevOps Server. Diese Spalte wird verwendet, um Benutzer in der Sammlung zu identifizieren.
Microsoft Entra-ID: Importbenutzer erwartet (Azure DevOps Services)	Entweder die erwartete Anmeldeadresse des abgeglichenen bald zu aktiven Benutzers oder keine Übereinstimmung gefunden (Microsoft Entra ID-Synchronisierung überprüfen), was angibt, dass die Identität während der Microsoft Entra-ID-Synchronisierung verloren gegangen ist und als Verlauf importiert wird.
Erwarteter Importstatus	Der erwartete Benutzermigrationsstatus: Entweder aktiv , wenn eine Übereinstimmung zwischen Active Directory und Microsoft Entra-ID vorhanden ist, oder "Historisch ", wenn keine Übereinstimmung vorhanden ist.
Überprüfungsdatum	Die letzte Überprüfung des Identitätszuordnungsprotokolls.

Beachten Sie beim Lesen der Datei, ob der Wert in der Spalte Erwarteter ImportstatusAktiv oder Verlauf ist. Aktiv gibt an, dass die Identität in dieser Zeile bei der Migration ordnungsgemäß zugeordnet wird. Historisch bedeutet, dass die Identitäten bei der Migration historisch werden. Es ist wichtig, die generierte Zuordnungsdatei auf Vollständigkeit und Richtigkeit zu überprüfen.

Wichtig

Die Migration schlägt fehl, wenn wichtige Änderungen an Ihrer Sicherheits-ID von Microsoft Entra Connect zwischen Migrationsversuchen auftreten. Sie können neue Benutzer zwischen Testläufen hinzufügen und Korrekturen vornehmen, um sicherzustellen, dass zuvor importierte historische Identitäten aktiv werden. Sie können jedoch keinen vorhandenen Benutzer ändern, der zuvor als aktiv importiert wurde. Dies führt dazu, dass ihre Migration fehlschlägt. Ein Beispiel für eine Änderung kann sein, eine Testausführungsmigration abzuschließen, eine Identität aus Ihrer Microsoft Entra-ID zu löschen, die aktiv importiert wurde, einen neuen Benutzer in der Microsoft Entra-ID für dieselbe Identität neu zu erstellen und dann eine andere Migration zu versuchen. In diesem Fall versucht eine aktive Identitätsmigration zwischen Active Directory und neu erstellte Microsoft Entra-Identität, verursacht jedoch einen Migrationsfehler.

1. Überprüfen Sie die korrekt übereinstimmenen Identitäten. Sind alle erwarteten Identitäten vorhanden? Sind die Benutzer der richtigen Microsoft Entra-Identität zugeordnet?

   Wenn Werte geändert werden müssen, wenden Sie sich an Ihren Microsoft Entra-Administrator, um zu überprüfen, ob die lokales Active Directory Identität Teil der Synchronisierung mit Microsoft Entra-ID ist und ordnungsgemäß eingerichtet ist. Weitere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in die Microsoft Entra-ID.

2. Überprüfen Sie als Nächstes die Identitäten, die als historisch gekennzeichnet sind. Diese Bezeichnung impliziert, dass aus einem der folgenden Gründe eine übereinstimmende Microsoft Entra-Identität nicht gefunden werden konnte:

   • Die Identität ist nicht für die Synchronisierung zwischen lokales Active Directory und Microsoft Entra ID eingerichtet.
   • Die Identität wird noch nicht in Ihrer Microsoft Entra-ID ausgefüllt (z. B. ein neuer Mitarbeiter).
   • Die Identität ist in Ihrer Microsoft Entra-Instanz nicht vorhanden.
   • Der Benutzer, der diese Identität besitzt, arbeitet nicht mehr im Unternehmen.

Um die ersten drei Gründe zu beheben, richten Sie die beabsichtigte lokales Active Directory Identität für die Synchronisierung mit Microsoft Entra ID ein. Weitere Informationen finden Sie unter Integrieren Ihrer lokalen Identitäten in die Microsoft Entra-ID. Sie müssen Microsoft Entra Connect einrichten und ausführen, damit Identitäten in Azure DevOps Services als aktiv importiert werden.

Sie können den vierten Grund ignorieren, da Mitarbeiter, die nicht mehr im Unternehmen sind, als historisch importiert werden sollten.

Historische Identitäten (kleine Teams)

Hinweis

Die in diesem Abschnitt vorgeschlagene Identitätsmigrationsstrategie sollte nur von kleinen Teams berücksichtigt werden.

Wenn Microsoft Entra Connect nicht konfiguriert ist, werden alle Benutzer in der Identitätszuordnungsprotokolldatei als Verlauf markiert. Das Ausführen einer Migration führt dazu, dass alle Benutzer als Verlauf importiert werden. Es wird dringend empfohlen, Microsoft Entra Connect zu konfigurieren, um sicherzustellen, dass Ihre Benutzer als aktiv importiert werden.

Das Ausführen einer Migration mit allen historischen Identitäten hat Konsequenzen, die sorgfältig berücksichtigt werden müssen. Nur Teams mit wenigen Benutzern und für die die Kosten für die Einrichtung von Microsoft Entra Connect als zu hoch eingestuft werden sollten.

Um alle Identitäten als Verlauf zu migrieren, führen Sie die in späteren Abschnitten beschriebenen Schritte aus. Wenn Sie eine Migration in die Warteschlange stellen, wird die Identität, mit der die Migration in die Warteschlange gestellt wird, als Organisationsbesitzer in die Organisation gestartet. Alle anderen Benutzer werden als Verlauf importiert. Organisationsbesitzer können dann die Benutzer wieder hinzufügen, indem sie ihre Microsoft Entra-Identität verwenden. Die hinzugefügten Benutzer werden als neue Benutzer behandelt. Sie besitzen keinen ihrer Geschichte, und es gibt keine Möglichkeit, diesen Verlauf der Microsoft Entra-Identität erneut zu machen. Benutzer können jedoch weiterhin ihre Vormigrationshistorie nachschlagen, indem sie nach deren \<domain>\<Active Directory username>Suchen suchen.

Das Datenmigrationstool zeigt eine Warnung an, wenn das vollständige Verlaufsidentitätsszenario erkannt wird. Wenn Sie sich für diesen Migrationspfad entscheiden, müssen Sie im Tool den Einschränkungen zustimmen.

Visual Studio-Abonnements

Das Datenmigrationstool kann Visual Studio-Abonnements (früher als MSDN-Vorteile bezeichnet) nicht erkennen, wenn sie die Identitätszuordnungsprotokolldatei generiert. Stattdessen wird empfohlen, das Feature für das automatische Lizenzupgrade nach der Migration anzuwenden. Solange die Geschäftskonten der Benutzer ordnungsgemäß verknüpft sind, wendet Azure DevOps Services automatisch ihre Visual Studio-Abonnementvorteile bei der ersten Anmeldung nach der Migration an. Sie werden niemals Lizenzen in Rechnung gestellt, die während der Migration zugewiesen sind, damit Sie Abonnements später sicher verarbeiten können.

Sie müssen keine Testausführungsmigration wiederholen, wenn die Visual Studio-Abonnements von Benutzern in Azure DevOps Services nicht automatisch aktualisiert werden. Visual Studio-Abonnementverknüpfung erfolgt außerhalb des Bereichs einer Migration. Solange ihr Geschäftskonto vor oder nach der Migration ordnungsgemäß verknüpft ist, werden die Lizenzen der Benutzer bei der nächsten Anmeldung automatisch aktualisiert. Nachdem ihre Lizenzen erfolgreich aktualisiert wurden, werden die Benutzer beim nächsten Ausführen einer Migration automatisch bei der ersten Anmeldung bei der Organisation aktualisiert.

Vorbereiten der Migration

Jetzt haben Sie alles bereit, um die Testausführungsmigration auszuführen. Planen Sie Ausfallzeiten mit Ihrem Team, um die Sammlung für die Migration offline zu schalten. Wenn Sie sich auf eine Zeit zum Ausführen der Migration einigen, laden Sie die erforderlichen Ressourcen hoch, die Sie generiert haben, und eine Kopie der Datenbank in Azure. Die Vorbereitung für die Migration besteht aus den folgenden fünf Schritten.

Schritt 1: Schalten Sie die Sammlung offline, und trennen Sie sie. Schritt 2: Generieren Sie eine DACPAC-Datei aus der Sammlung, die Sie migrieren möchten.
Schritt 3: Laden Sie die DACPAC-Datei und Migrationsdateien in ein Azure-Speicherkonto hoch.
Schritt 4: Generieren eines SAS-Tokens für den Zugriff auf das Speicherkonto.
Schritt 5: Abschließen der Migrationsspezifikation.

Hinweis

Bevor Sie eine Produktionsmigration durchführen, wird dringend empfohlen, eine Testausführungsmigration abzuschließen. Bei einer Testausführung können Sie überprüfen, ob der Migrationsprozess für Ihre Sammlung funktioniert und dass keine eindeutigen Daten-Shapes vorhanden sind, die zu einem Produktionsmigrationsfehler führen können.

Schritt 1: Trennen Der Sammlung

Das Trennen der Sammlung ist ein wichtiger Schritt im Migrationsprozess. Identitätsdaten für die Sammlung befinden sich in der Konfigurationsdatenbank des Azure DevOps Server instance, während die Sammlung angefügt und online ist. Wenn eine Sammlung von der Azure DevOps Server instance getrennt wird, nimmt sie eine Kopie dieser Identitätsdaten an und verpackt sie mit der Auflistung für den Transport. Ohne diese Daten kann der Identitätsteil der Migration nicht ausgeführt werden.

Tipp

Es wird empfohlen, die Sammlung so lange getrennt zu lassen, bis die Migration abgeschlossen ist, da es keine Möglichkeit gibt, die während der Migration aufgetretenen Änderungen zu migrieren. Fügen Sie Ihre Sammlung nach der Sicherung für die Migration erneut an, daher sind Sie nicht besorgt darüber, dass Sie die neuesten Daten für diese Art der Migration haben. Um Offlinezeit insgesamt zu vermeiden, können Sie auch eine Offlineablösung für Testläufe verwenden.

Es ist wichtig, die Kosten abzuwägen, für einen Testlauf null Ausfallzeiten zu verursachen. Sie erfordert das Erstellen von Sicherungen der Sammlungs- und Konfigurationsdatenbank, deren Wiederherstellung auf einer SQL-instance und das anschließende Erstellen einer getrennten Sicherung. Eine Kostenanalyse könnte belegen, dass es am Ende besser ist, nur ein paar Stunden Ausfallzeiten zu nehmen, um die getrennten Sicherungen direkt zu nehmen.

Schritt 2: Generieren einer DACPAC-Datei

DACPACs bieten eine schnelle und relativ einfache Methode zum Verschieben von Sammlungen in Azure DevOps Services. Nachdem die Größe einer Sammlungsdatenbank jedoch einen bestimmten Schwellenwert überschreitet, beginnen sich die Vorteile der Verwendung einer DACPAC-Datei zu verringern.

Hinweis

Wenn das Datenmigrationstool eine Warnung anzeigt, dass Sie die DACPAC-Methode nicht verwenden können, müssen Sie die Migration mithilfe der VM-Methode (VM) von SQL Azure durchführen. Überspringen Sie die Schritte 2 bis 5 in diesem Fall, und folgen Sie den Anweisungen in der Phase "Vorbereitung der Testausführung", dem Abschnitt "Migrieren großer Sammlungen", und bestimmen Sie dann den Migrationstyp. Wenn das Datenmigrationstool keine Warnung anzeigt, verwenden Sie die in diesem Schritt beschriebene DACPAC-Methode.

DACPAC ist ein Feature von SQL Server, mit dem Datenbanken in eine einzelne Datei verpackt und in anderen Instanzen von SQL Server bereitgestellt werden können. Eine DACPAC-Datei kann auch direkt in Azure DevOps Services wiederhergestellt werden, sodass Sie sie als Paketerstellungsmethode zum Abrufen der Daten Ihrer Sammlung in der Cloud verwenden können.

Wichtig

• Wenn Sie SqlPackage.exe verwenden, müssen Sie die .NET Framework-Version von SqlPackage.exe verwenden, um DACPAC vorzubereiten. Das MSI-Installationsprogramm muss zum Installieren der .NET Framework-Version von SqlPackage.exe verwendet werden. Verwenden Sie die dotnet CLI- oder .zip-Versionen (Windows .NET 6) von SqlPackage.exe nicht, da diese Versionen DACPACs generieren können, die mit Azure DevOps Services nicht kompatibel sind.
• Version 161 von SqlPackage verschlüsselt standardmäßig Datenbankverbindungen und stellt möglicherweise keine Verbindung her. Wenn sie einen Anmeldevorgangsfehler erhalten, fügen Sie der Verbindungszeichenfolge der SqlPackage-Anweisung hinzu;Encrypt=False;TrustServerCertificate=True.

Laden Sie SqlPackage.exe mithilfe des neuesten MSI-Installers aus den SqlPackage-Versionshinweisen herunter, und installieren Sie sie.

Nachdem Sie das MSI-Installationsprogramm verwendet haben, wird SqlPackage.exe in einem pfad ähnlichen %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\Pfad installiert.

Beachten Sie beim Generieren eines DACPAC zwei Überlegungen: den Datenträger, auf dem DACPAC gespeichert ist, und den Speicherplatz auf dem Computer, auf dem DACPAC generiert wird. Sie möchten sicherstellen, dass genügend Speicherplatz vorhanden ist, um den Vorgang abzuschließen.

Während das Paket erstellt wird, speichert SqlPackage.exe vorübergehend Daten aus Ihrer Sammlung im temporären Verzeichnis auf Laufwerk C des Computers, von dem Sie die Paketanforderung initiieren.

Möglicherweise stellen Sie fest, dass Laufwerk C zu klein ist, um die Erstellung einer DACPAC-Datei zu unterstützen. Sie können den benötigten Speicherplatz schätzen, indem Sie nach der größten Tabelle in Ihrer Sammlungsdatenbank suchen. DACPACs werden nacheinander erstellt. Der maximale Speicherplatzbedarf zum Ausführen der Generierung entspricht in etwa der Größe der größten Tabelle in der Sammlungsdatenbank. Wenn Sie die generierte DACPAC auf Laufwerk C speichern, sollten Sie die Größe der Sammlungsdatenbank berücksichtigen, wie in der DataMigrationTool.log Datei aus einer Überprüfungsausführung angegeben.

Die datei DataMigrationTool.log stellt eine Liste der größten Tabellen in der Auflistung bei jeder Ausführung des Befehls bereit. Ein Beispiel für Tabellengrößen für eine Auflistung finden Sie in der folgenden Ausgabe. Vergleichen Sie die Größe der größten Tabelle mit dem freien Speicherplatz auf dem Laufwerk, auf dem Ihr temporäres Verzeichnis gehostet wird.

Wichtig

Bevor Sie mit dem Generieren einer DACPAC-Datei fortfahren, stellen Sie sicher, dass Ihre Sammlung getrennt ist.

[Info   @08:23:59.539] Table name                               Size in MB
[Info   @08:23:59.539] dbo.tbl_Content                          38984
[Info   @08:23:59.539] dbo.tbl_LocalVersion                     1935
[Info   @08:23:59.539] dbo.tbl_Version                          238
[Info   @08:23:59.539] dbo.tbl_FileReference                    85
[Info   @08:23:59.539] dbo.Rules                                68
[Info   @08:23:59.539] dbo.tbl_FileMetadata                     61

Stellen Sie sicher, dass das Laufwerk, auf dem Ihr temporäres Verzeichnis gehostet wird, über mindestens so viel freien Speicherplatz verfügt. Wenn dies nicht der Fall ist, müssen Sie das temporäre Verzeichnis umleiten, indem Sie eine Umgebungsvariable festlegen.

SET TEMP={location on disk}

Ein weiterer Aspekt ist, wo die DACPAC-Daten gespeichert werden. Das Verweisen auf den gespeicherten Speicherort auf ein ferngesteuertes Remotelaufwerk kann zu längeren Erzeugungszeiten führen. Wenn ein schnelles Laufwerk wie ein Solid State Drive (SSD) lokal verfügbar ist, wird empfohlen, das Laufwerk als DACPAC-Speicherort zu verwenden. Andernfalls ist es immer schneller, einen Datenträger zu verwenden, der sich auf dem Computer befindet, auf dem sich die Sammlungsdatenbank befindet, und nicht ein Remotelaufwerk.

Nachdem Sie den Zielspeicherort für DACPAC identifiziert und sichergestellt haben, dass genügend Speicherplatz vorhanden ist, ist es an der Zeit, die DACPAC-Datei zu generieren.

Öffnen Sie ein Eingabeaufforderungsfenster, und wechseln Sie zum SqlPackage.exe Speicherort. Ersetzen Sie zum Generieren der DACPAC die Platzhalterwerte durch die erforderlichen Werte, und führen Sie dann den folgenden Befehl aus:

SqlPackage.exe /sourceconnectionstring:"Data Source={database server name};Initial Catalog={Database Name};Integrated Security=True" /targetFile:{Location & File name} /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

• Datenquelle: Die SQL Server instance, die Ihre Azure DevOps Server-Sammlungsdatenbank hostet.
• Anfangskatalog: Der Name der Sammlungsdatenbank.
• targetFile: Der Speicherort auf dem Datenträger und der DACPAC-Dateiname.

Ein DACPAC-Generierungsbefehl, der auf der Azure DevOps Server Datenebene selbst ausgeführt wird, wird im folgenden Beispiel gezeigt:

SqlPackage.exe /sourceconnectionstring:"Data Source=localhost;Initial Catalog=Foo;Integrated Security=True" /targetFile:C:\DACPAC\Foo.dacpac /action:extract /p:ExtractAllTableData=true /p:IgnoreUserLoginMappings=true /p:IgnorePermissions=true /p:Storage=Memory

Die Ausgabe des Befehls ist eine DACPAC-Datei, die aus der Sammlungsdatenbank Foo namens Foo.dacpac generiert wird.

Konfigurieren Ihrer Sammlung für die Migration

Nachdem Ihre Sammlungsdatenbank auf Ihrem virtuellen Azure-Computer wiederhergestellt wurde, konfigurieren Sie eine SQL-Anmeldung, damit Azure DevOps Services eine Verbindung mit der Datenbank herstellen kann, um die Daten zu migrieren. Diese Anmeldung ermöglicht nur Lesezugriff auf eine einzelne Datenbank.

Öffnen Sie zunächst SQL Server Management Studio auf dem virtuellen Computer, und öffnen Sie dann ein neues Abfragefenster für die zu importierende Datenbank.

Legen Sie die Wiederherstellung der Datenbank auf einfach fest:

ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;

Erstellen Sie eine SQL-Anmeldung für die Datenbank, und weisen Sie diese Anmeldung bei "TFSEXECROLE" zu:

USE [<database name>]
CREATE LOGIN <pick a username> WITH PASSWORD = '<pick a password>'
CREATE USER <username> FOR LOGIN <username> WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='<username>'

Im Anschluss an unser Fabrikam-Beispiel würden die beiden SQL-Befehle wie im folgenden Beispiel aussehen:

ALTER DATABASE [Fabrikam] SET RECOVERY SIMPLE;

USE [Foo]
CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikampassword'
CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo]
EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Hinweis

Aktivieren Sie SQL Server und Windows-Authentifizierung Modus in SQL Server Management Studio auf dem virtuellen Computer. Wenn Sie den Authentifizierungsmodus nicht aktivieren, schlägt die Migration fehl.

Konfigurieren der Migrationsspezifikationsdatei für den virtuellen Computer

Aktualisieren Sie die Migrationsspezifikationsdatei, um Informationen zum Herstellen einer Verbindung mit der SQL Server-Instanz einzuschließen. Öffnen Sie Die Migrationsspezifikationsdatei, und nehmen Sie die folgenden Updates vor.

1. Entfernen Sie den DACPAC-Parameter aus dem Quelldateiobjekt.

   Die Migrationsspezifikation vor der Änderung wird im folgenden Code angezeigt.

   

   Die Migrationsspezifikation nach der Änderung wird im folgenden Code angezeigt.

   

2. Füllen Sie die erforderlichen Parameter aus, und fügen Sie das folgende Eigenschaftenobjekt in Ihrem Quellobjekt in der Spezifikationsdatei hinzu.

   "Properties":
   {
       "ConnectionString": "Data Source={SQL Azure VM Public IP};Initial Catalog={Database Name};Integrated Security=False;User ID={SQL Login Username};Password={SQL Login Password};Encrypt=True;TrustServerCertificate=True" 
   }
   

Nachdem Sie die Änderungen angewendet haben, sieht die Migrationsspezifikation wie im folgenden Beispiel aus.

Ihre Migrationsspezifikation ist jetzt für die Verwendung einer SQL Azure-VM für die Migration konfiguriert. Fahren Sie mit den restlichen Vorbereitungsschritten fort, um zu Azure DevOps Services zu migrieren. Achten Sie nach Abschluss der Migration darauf, die SQL-Anmeldung zu löschen oder das Kennwort zu drehen. Microsoft behält die Anmeldeinformationen nach Abschluss der Migration nicht bei.

Schritt 3: Hochladen der DACPAC-Datei

Hinweis

Wenn Sie die SQL Azure VM-Methode verwenden, müssen Sie nur die Verbindungszeichenfolge angeben. Sie müssen keine Dateien hochladen, und Sie können diesen Schritt überspringen.

Ihr DACPAC muss in einem Azure-Speichercontainer platziert werden, bei dem es sich um einen vorhandenen Container oder einen container handelt, der speziell für Ihren Migrationsaufwand erstellt wurde. Es ist wichtig, sicherzustellen, dass Ihr Container an den richtigen geografischen Standorten erstellt wird.

Azure DevOps Services ist an mehreren geografischen Standorten verfügbar. Wenn Sie an diese Speicherorte importieren, ist es wichtig, Ihre Daten korrekt zu platzieren, um sicherzustellen, dass die Migration erfolgreich gestartet werden kann. Ihre Daten müssen sich an demselben geografischen Ort befinden, in den Sie importieren. Das Platzieren der Daten an einer anderen Stelle führt dazu, dass die Migration nicht gestartet werden kann. In der folgenden Tabelle sind die zulässigen geografischen Standorte für das Erstellen Ihres Speicherkontos und das Hochladen Ihrer Daten aufgeführt.

Gewünschter geografischer Standort der Migration	Geografischer Standort des Speicherkontos
Zentrale USA	Zentrale USA
Europa, Westen	Europa, Westen
United Kingdom	Vereinigtes Königreich, Süden
Australien (Osten)	Australien (Osten)
Brasilien Süd	Brasilien Süd
Indien, Süden	Indien, Süden
Kanada, Mitte	Kanada, Mitte
Asien-Pazifik, (Singapur)	Asien-Pazifik, (Singapur)

Obwohl Azure DevOps Services an mehreren geografischen Standorten in den USA verfügbar ist, akzeptiert nur der zentrale USA Standort neue Azure DevOps Services. Sie können Ihre Daten zurzeit nicht zu anderen US-Azure-Standorten migrieren.

Erstellen Sie einen BLOB-Container aus dem Azure-Portal. Laden Sie nach dem Erstellen des Containers die Sammlungs-DACPAC-Datei hoch.

Löschen Sie nach Abschluss der Migration den BLOB-Container und das zugehörige Speicherkonto mit Tools wie AzCopy oder einem anderen Azure Storage Explorer-Tool, z. B. Azure Storage-Explorer.

Hinweis

Wenn Ihre DACPAC-Datei größer als 10 GB ist, wird empfohlen, AzCopy zu verwenden. AzCopy unterstützt Multithreaduploads für schnellere Uploads.

Schritt 4: Generieren eines SAS-Tokens

Ein SAS-Token (Shared Access Signature) ermöglicht delegierten Zugriff auf Ressourcen in einem Speicherkonto. Mit dem Token können Sie Microsoft die niedrigste Berechtigungsstufe erteilen, die für den Zugriff auf Ihre Daten für die Ausführung der Migration erforderlich ist.

Sie können SAS-Token mithilfe der Azure-Portal generieren. Aus Sicherheitsgründen wird empfohlen, die folgenden Aufgaben auszuführen:

1. Wählen Sie nur "Lesen " und "Liste" als Berechtigungen für Ihr SAS-Token aus. Es sind keine weiteren Berechtigungen erforderlich.
2. Legen Sie eine Ablaufzeit nicht mehr als sieben Tage in die Zukunft fest.
3. Beschränken sie den Zugriff nur auf Azure DevOps Services-IPs.
4. Behandeln Sie den SAS-Schlüssel als geheimen Schlüssel. Lassen Sie den Schlüssel nicht an einem unsicheren Speicherort, da er Lese- und Listenzugriff auf alle Daten gewährt, die Sie im Container gespeichert haben.

Schritt 5: Abschließen der Migrationsspezifikation

Zuvor haben Sie die Migrationsspezifikationsdatei teilweise ausgefüllt, die als migration.json bezeichnet wird. An diesem Punkt verfügen Sie über genügend Informationen, um alle verbleibenden Felder mit Ausnahme des Migrationstyps abzuschließen. Der Migrationstyp wird später im Migrationsabschnitt behandelt.

Füllen Sie in der migration.json Spezifikationsdatei unter "Quelle" die folgenden Felder aus.

• Speicherort: Fügen Sie den SAS-Schlüssel ein, den Sie aus dem Skript generiert und dann im vorherigen Schritt kopiert haben.
• Dacpac: Stellen Sie sicher, dass die Datei, einschließlich der Dateierweiterung .dacpac , denselben Namen wie die DACPAC-Datei hat, die Sie in das Speicherkonto hochgeladen haben.

Die endgültige Migrationsspezifikationsdatei sollte wie im folgenden Beispiel aussehen.

Bestimmen des Migrationstyps

Importe können entweder als Testlauf oder als Produktionsausführung in die Warteschlange gestellt werden. Der Parameter ImportType bestimmt den Migrationstyp:

• TestRun: Verwenden Sie eine Testausführung für Testzwecke. Das System löscht die Testausführung nach 45 Tagen.
• ProductionRun: Verwenden Sie eine Produktionsausführung, wenn Sie die resultierende Migration beibehalten und die Organisation nach Abschluss der Migration in Azure DevOps Services vollzeit verwenden möchten.

Tipp

Es wird immer empfohlen, zuerst eine Testausführungsmigration abzuschließen.

Testausführungsorganisationen

Testausführungsorganisationen helfen Teams beim Testen der Migration ihrer Sammlungen. Bevor eine Produktionsmigration ausgeführt werden kann, müssen alle abgeschlossenen Testausführungsorganisationen gelöscht werden. Alle Testausführungsorganisationen verfügen über eine begrenzte Existenz und werden nach einem festgelegten Zeitraum automatisch gelöscht. Informationen dazu, wann die Organisation gelöscht wird, sind in der Erfolgs-E-Mail enthalten, die Sie nach Abschluss der Migration erhalten sollten. Achten Sie darauf, dieses Datum zur Kenntnis zu nehmen und entsprechend zu planen.

Testausführungsorganisationen haben 45 Tage, bevor sie gelöscht werden. Nach dem angegebenen Zeitraum wird die Testausführungsorganisation gelöscht. Sie können Die Testausführungsimporte beliebig oft wiederholen, bevor Sie eine Produktionsmigration durchführen.

Testläufe löschen

Löschen Sie alle vorherigen Testläufe, bevor Sie versuchen, eine neue auszuführen. Wenn Ihr Team bereit ist, eine Produktionsmigration durchzuführen, müssen Sie die Testausführungsorganisation manuell löschen. Bevor Sie eine zweite Testausführungsmigration oder die endgültige Produktionsmigration ausführen können, müssen Sie alle vorherigen Azure DevOps Services-Organisationen löschen, die Sie in einer vorherigen Testausführung erstellt haben. Weitere Informationen finden Sie unter "Organisation löschen".

Tipp

Optionale Informationen, die einem Benutzer helfen sollen, erfolgreicher zu sein, dass die Migration eines Testlaufs, die dem ersten folgt, aufgrund der zusätzlichen Zeit, die zum Bereinigen von Ressourcen aus früheren Testläufen erforderlich ist, länger dauert.

Es kann bis zu einer Stunde dauern, bis ein organization Name nach dem Löschen oder Umbenennen verfügbar ist. Weitere Informationen finden Sie im Artikel zu Aufgaben nach der Migration.

Wenn Migrationsprobleme auftreten, lesen Sie die Problembehandlung bei Migrations- und Migrationsfehlern.

Ausführen einer Migration

Ihr Team ist jetzt bereit, mit dem Prozess der Ausführung einer Migration zu beginnen. Es wird empfohlen, mit einer erfolgreichen Testausführungsmigration zu beginnen, bevor Sie versuchen, eine Migration mit Produktionsausführung durchzuführen. Mit Importen von Testausführungen können Sie im Voraus sehen, wie eine Migration aussieht, potenzielle Probleme erkennen und Erfahrungen sammeln, bevor Sie in ihre Produktionsausführung gehen.

Hinweis

• Wenn Sie eine abgeschlossene Produktionsausführungsmigration für eine Sammlung wiederholen müssen, wie bei einem Rollback, wenden Sie sich an den Kundensupport von Azure DevOps Services, bevor Sie eine andere Migration in die Warteschlange stellen.

• Azure-Administratoren können verhindern, dass Benutzer neue Azure DevOps-Organisationen erstellen. Wenn die Microsoft Entra-Mandantenrichtlinie aktiviert ist, kann Ihre Migration nicht abgeschlossen werden. Bevor Sie beginnen, stellen Sie sicher, dass die Richtlinie nicht festgelegt ist oder dass für den Benutzer, der die Migration ausführt, eine Ausnahme vorhanden ist. Weitere Informationen finden Sie unter Einschränken der Organisationserstellung über die Microsoft Entra-Mandantenrichtlinie.
• Azure DevOps Services unterstützt keine Aufbewahrungsrichtlinien pro Pipeline, und sie werden nicht an die gehostete Version übertragen.

Überlegungen für Rollbackpläne

Ein häufiges Problem für Teams, die eine endgültige Produktionsausführung durchführen, ist ihr Rollbackplan, wenn etwas mit der Migration schief geht. Es wird dringend empfohlen, eine Testausführung durchzuführen, um sicherzustellen, dass Sie die Migrationseinstellungen testen können, die Sie für das Datenmigrationstool für Azure DevOps bereitstellen.

Das Rollback für die endgültige Produktionsausführung ist relativ einfach. Bevor Sie die Migration in die Warteschlange stellen, trennen Sie die Teamprojektsammlung von Azure DevOps Server, wodurch sie ihren Teammitgliedern nicht zur Verfügung steht. Wenn Sie aus irgendeinem Grund einen Rollback für die Produktionsausführung durchführen und den lokalen Server für Ihre Teammitglieder wieder online schalten müssen, können Sie dies tun. Fügen Sie die Teamprojektsammlung erneut lokal an, und informieren Sie Ihr Team darüber, dass sie weiterhin normal arbeiten, während Ihr Team gruppiert, um mögliche Fehler zu verstehen.

Sie können sich dann an den Kundensupport von Azure DevOps Services wenden, um Hilfe beim Verständnis der Ursache des Fehlers zu erhalten, wenn Sie die Ursache nicht ermitteln können. Weitere Informationen finden Sie im Artikel zur Problembehandlung. Kundensupporttickets können auf der folgenden Seite https://aka.ms/AzureDevOpsImportSupportgeöffnet werden. Es ist wichtig zu beachten, dass, wenn das Problem erfordert, dass Produktgruppentechniker diese Fälle während der regulären Geschäftszeiten behandeln.

Trennen Sie Ihre Teamprojektsammlung von Azure DevOps Server, um sie für die Migration vorzubereiten.

Bevor Sie eine Sicherung Ihrer SQL-Datenbank generieren, muss die Datenmigrationstool die Sammlung vollständig von Azure DevOps Server (nicht SQL) trennen. Der Abtrennvorgang in Azure DevOps Server überträgt Benutzeridentitätsinformationen, die außerhalb der Sammlungsdatenbank gespeichert sind, und macht ihn portierbar, um zu einem neuen Server oder in diesem Fall zu Azure DevOps Services zu wechseln.

Das Trennen einer Sammlung erfolgt ganz einfach über die Azure DevOps Server-Verwaltungskonsole in Ihrer Azure DevOps Server-Instanz. Weitere Informationen finden Sie unter Move project collection, Detach the collection.

Warteschlange für die Migration

Wichtig

Bevor Sie fortfahren, stellen Sie sicher, dass Ihre Sammlung getrennt wurde, bevor Sie eine DACPAC-Datei generieren oder die Sammlungsdatenbank auf einen SQL Azure virtuellen Computer hochladen. Wenn Sie diesen Schritt nicht abschließen, schlägt die Migration fehl. Wenn ihre Migration fehlschlägt, lesen Sie "Beheben von Migrationsfehlern".

Starten Sie eine Migration mithilfe des Importbefehls des Datenmigrationstools . Der Migrationsbefehl verwendet eine Migrationsspezifikationsdatei als Eingabe. Sie analysiert die Datei, um sicherzustellen, dass die bereitgestellten Werte gültig sind und bei erfolgreicher Ausführung eine Migration zu Azure DevOps Services in die Warteschlange stellt. Der Migrationsbefehl erfordert eine Internetverbindung, erfordert jedoch keine Verbindung mit Ihrer Azure DevOps Server-Instanz.

Öffnen Sie zunächst ein Eingabeaufforderungsfenster, und ändern Sie Verzeichnisse in den Pfad zum Datenmigrationstool. Es wird empfohlen, den Hilfetext zu überprüfen, der mit dem Tool bereitgestellt wird. Führen Sie den folgenden Befehl aus, um die Anleitungen und Hilfe für den Migrationsbefehl anzuzeigen:

Migrator import /help

Der Befehl für die Warteschlange einer Migration weist die folgende Struktur auf:

Migrator import /importFile:{location of migration specification file}

Das folgende Beispiel zeigt einen abgeschlossenen Migrationsbefehl:

Migrator import /importFile:C:\DataMigrationToolFiles\migration.json

Nachdem die Überprüfung bestanden wurde, melden Sie sich bei der Microsoft Entra-ID mit einer Identität an, die Mitglied desselben Microsoft Entra-Mandanten ist, für den die Identitätszuordnungsprotokolldatei erstellt wurde. Der angemeldete Benutzer ist der Besitzer der importierten Organisation.

Hinweis

Jeder Microsoft Entra-Mandant ist auf fünf Importe pro 24-Stunden-Zeitraum beschränkt. Nur Importe, die sich in der Warteschlange befinden, zählen für diese Obergrenze.

Wenn Ihr Team eine Migration initiiert, wird eine E-Mail-Benachrichtigung an den Benutzer gesendet, der die Migration in die Warteschlange gestellt hat. Etwa 5 bis 10 Minuten nach der Warteschlange der Migration kann Ihr Team zur Organisation wechseln, um den Status zu überprüfen. Nach Abschluss der Migration wird Ihr Team zur Anmeldung weitergeleitet, und eine E-Mail-Benachrichtigung wird an die Organisationsbesitzer gesendet.

Das Datenmigrationstool kennzeichnet Fehler, die Vor der Migration korrigiert werden müssen. In diesem Artikel werden die häufigsten Warnungen und Fehler beschrieben, die beim Vorbereiten der Migration auftreten können. Nachdem Sie jeden Fehler korrigiert haben, führen Sie den Migrationsüberprüfungsbefehl erneut aus, um die Auflösung zu überprüfen.

Nächste Schritte

Beheben von Migrationsfehlern

Verwandte Artikel

• Migration overview (Übersicht über die Migration)
• Aufgaben nach der Migration