Share via

Vorbereiten der Testausführungsmigration

  • Artikel

Dieser Artikel konzentriert sich auf die Teamvorbereitung und die Generierung von Dateien, die vom Datenmigrationstool benötigt werden.

Diagramm mit hervorgehobener Option

Voraussetzungen

Führen Sie die Überprüfungsphase aus, bevor Sie mit der Vorbereitung der Testausführungsmigration beginnen.

Generieren von Migrationseinstellungen

Führen Sie die folgenden Schritte aus, um die Migrationsspezifikation und die zugehörigen Dateien zu generieren, um die Migration Ihrer Sammlungsdatenbank in die Warteschlange zu stellen.

  1. Führen Sie den Befehl "Datenmigrationstool vorbereiten" mit den folgenden Parametern aus:

    /collection:http://localhost:8080/tfs/DefaultCollection/ tenantDomainName:contoso.com /Region:CUS

    • Die Option "Mandant do Standard Name ist der Name des Microsoft Entra ID-Mandanten Ihres Unternehmens.
    • Der Befehl "Vorbereiten" erfordert Internetzugriff. Wenn Ihr Azure DevOps Server keine Internetverbindung hat, führen Sie den Befehl von einem anderen Computer aus.
    • Der Begriff "Organisationsregion" bezieht sich auf den Speicherort, an dem Sie Ihre Sammlung in Azure DevOps Services migrieren möchten. Sie haben zuvor einen Bereich ausgewählt und dessen Kurzcode aufgezeichnet. Verwenden Sie diesen Code im Befehl "Vorbereiten".

  2. Melden Sie sich mit einem Benutzer vom Mandanten an, der über die Berechtigung zum Lesen von Informationen zu allen Benutzern im Microsoft Entra ID-Mandanten verfügt.

Konfigurieren der Migrationsspezifikationsdatei

Die Migrationsspezifikationsdatei ist eine JSON-Datei, die das Datenmigrationstool anweist, wie die folgenden Aktionen ausgeführt werden.

  • Konfigurieren Ihrer migrierten Organisation
  • Angeben der Quellspeicherorte
  • Anpassen der Migration

Viele der Felder werden während des Vorbereitungsschritts automatisch ausgefüllt, aber Sie müssen die folgenden Felder konfigurieren:

  • Name der Organisation: Der Name der Organisation, die Sie zum Migrieren Ihrer Daten erstellen möchten.
  • Speicherort: Eine Sicherung Ihrer Datenbank- und Migrationsdateien, die in einen Azure-Speichercontainer hochgeladen werden sollen. Dieses Feld gibt den SAS-Schlüssel an, der vom Migrationstool zum sicheren Herstellen einer Verbindung mit den Quelldateien aus dem Azure-Speichercontainer verwendet wird. Das Erstellen des Speichercontainers wird später in Phase 5 behandelt und das Generieren eines SAS-Schlüssels wird in Phase 6 behandelt, bevor Sie eine Warteschlange für eine neue Migration durchführen.
  • DACPAC: Eine Datei, die die SQL-Datenbank Ihrer Sammlung packt.
  • Migrationstyp: Der Migrationstyp: Testausführung oder Produktionsausführung.

Jede Migrationsspezifikationsdatei ist für eine einzelne Sammlung vorgesehen. Wenn Sie versuchen, eine Migrationsspezifikationsdatei zu verwenden, die für eine andere Sammlung generiert wurde, wird die Migration nicht gestartet. Sie müssen eine Testausführung für jede Sammlung vorbereiten, die Sie migrieren möchten, und die generierte Migrationsspezifikationsdatei verwenden, um die Migration in die Warteschlange zu stellen.

Überprüfen der Identitätszuordnungsprotokolldatei

Das Identitätszuordnungsprotokoll ist entscheidend, ebenso wichtig wie die tatsächlichen Daten, die Sie migrieren. Wenn Sie die Protokolldatei untersuchen, verstehen Sie, wie Identitätsmigration und mögliche Ergebnisse funktionieren. Wenn Sie eine Identität migrieren, kann sie entweder aktiv oder historisch sein. Aktive Identitäten können sich bei Azure DevOps Services anmelden, während historische Identitäten nicht möglich sind. Der Dienst entscheidet, welcher Typ verwendet wird.

Hinweis

Sobald eine Identität als historische Identität migriert wird, gibt es keine Möglichkeit, sie in eine aktive Identität zu konvertieren.

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 Spalte "Erwarteter Importstatus " in der Identitätszuordnungsprotokolldatei 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 historisch migriert wurde, können Sie sie nicht mehr aktivieren.

Lizenzen

Während der Migration werden Lizenzen automatisch für alle Benutzer zugewiesen, die in der Spalte "Erwarteter Importstatus" des Identitätszuordnungsprotokolls als "aktiv" angezeigt werden. Wenn die automatische Lizenzzuweisung falsch ist, können Sie sie ändern, indem Sie die Zugriffsstufe eines oder mehrerer Benutzer nach Abschluss der Migration bearbeiten.

Die Aufgabe ist möglicherweise nicht immer perfekt, sodass Sie bis zum ersten des folgenden Monats lizenzen nach Bedarf neu zuweisen müssen. Wenn Sie bis zum ersten des nächsten Monats kein Abonnement mit Ihrer Organisation verknüpfen und die richtige Anzahl von Lizenzen erworben haben, werden alle Ihre Nachfristlizenzen widerrufen. Wenn die automatische Zuweisung mehr Lizenzen zugewiesen hat, als Sie für den nächsten Monat erworben haben, berechnen wir Sie nicht für die zusätzlichen Lizenzen, aber wir widerrufen alle nicht bezahlten Lizenzen.

Um den Zugriff zu vermeiden, empfehlen wir, ein Abonnement zu verknüpfen und erforderliche Lizenzen vor dem ersten Monat zu erwerben, da die Abrechnung monatlich ausgeführt wird. Für alle Testläufe sind Lizenzen kostenlos, solange die Organisation aktiv ist.

Azure DevOps-Abonnements

Visual Studio-Abonnements werden für Migrationen nicht standardmäßig zugewiesen. Stattdessen werden Benutzer mit Visual Studio-Abonnements automatisch aktualisiert, um diese Lizenz zu verwenden. Wenn die Arbeitsorganisation eines Benutzers ordnungsgemäß verknüpft ist, wendet Azure DevOps Services automatisch seine Visual Studio-Abonnementvorteile auf die erste Anmeldung nach der Migration an.

Sie müssen keine Testausführungsmigration wiederholen, wenn Benutzer nicht automatisch aktualisiert werden, um ihr Visual Studio-Abonnement in Azure DevOps Services zu verwenden. Visual Studio-Abonnementverknüpfung ist etwas, das außerhalb des Bereichs einer Migration geschieht. Wenn die Arbeitsorganisation vor oder nach der Migration ordnungsgemäß verknüpft wird, wird die Lizenz automatisch für die nächste Anmeldung aktualisiert. Nachdem sie aktualisiert wurden, wird beim nächsten Migrieren des Benutzers bei der ersten Anmeldung bei der Organisation automatisch ein Upgrade ausgeführt.

Beschränken des Zugriffs auf Azure DevOps Services IP-Adressen

Beschränken Sie den Zugriff auf Ihr Azure Storage-Konto nur auf IPs von Azure DevOps Services. Sie können den Zugriff einschränken, indem Sie nur Verbindungen von Azure DevOps Services-IPs zulassen, die am Migrationsprozess der Sammlungsdatenbank beteiligt sind. Die Ip-Adressen, denen Der Zugriff auf Ihr Speicherkonto gewährt werden muss, hängt von der Region ab, zu der Sie migrieren.

Option 1: Diensttags verwenden

Sie können Problemlos Verbindungen aus allen Azure DevOps Services-Regionen zulassen, indem Sie das azuredevops Servicetag zu Ihren Netzwerksicherheitsgruppen oder Firewalls entweder über das Portal oder programmgesteuert hinzufügen.

Option 2: IP-Liste verwenden

Verwenden Sie den IpList Befehl, um die Liste der Ip-Adressen abzurufen, denen Zugriff gewährt werden muss, um Verbindungen aus einer bestimmten Azure DevOps Services-Region zuzulassen.

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

Migrator IpList /collection:{CollectionURI} /tenantDomainName:{name} /region:{region}

Sie können die Liste der Ip-Adressen entweder über das Portal oder programmgesteuert zu Ihren Netzwerksicherheitsgruppen oder Firewalls hinzufügen.

Konfigurieren von IP-Firewall-Ausnahmen für SQL Azure

Dieser Abschnitt gilt nur für das Konfigurieren von Firewall-Ausnahmen für SQL Azure. Informationen zu DACPAC-Migrationen finden Sie unter Konfigurieren von Azure Storage-Firewalls und virtuellen Netzwerken.

Für das Datenmigrationstool müssen die Azure DevOps Services-IPs nur für eingehende Verbindungen konfiguriert 1433werden.

Führen Sie die folgenden Schritte aus, um Ausnahmen für die erforderlichen IPs zu gewähren, die auf der Azure-Netzwerkebene für Ihre SQL Azure-VM behandelt werden.

  1. Melden Sie sich beim Azure-Portal an.
  2. Wechseln Sie zu Ihrer SQL Azure-VM.
  3. Wählen Sie unter Einstellungen die Option Netzwerk.
  4. Wählen Sie Regel für eingehenden Port hinzufügen aus. Screenshot der Schaltfläche
  5. Wählen Sie "Erweitert" aus, um eine eingehende Portregel für eine bestimmte IP zu konfigurieren. Screenshot der Schaltfläche
  6. Wählen Sie in der Dropdownliste "Quelle" die Option "IP-Adressen" aus, geben Sie eine IP-Adresse ein, die eine Ausnahme erteilt werden muss, legen Sie den Zielportbereich 1433 fest, und geben Sie im Feld "Name" einen Namen ein, der die ausnahme, die Sie konfigurieren, am besten beschreibt.

Je nach anderen konfigurierten eingehenden Portregeln müssen Sie möglicherweise die Standardpriorität für die Azure DevOps Services-Ausnahmen ändern, sodass sie nicht ignoriert werden. Wenn Sie beispielsweise eine Regel "Für alle eingehenden Verbindungen mit 1433 verweigern" mit einer höheren Priorität als Ihre Azure DevOps Services-Ausnahmen haben, kann das Datenmigrationstool möglicherweise keine erfolgreiche Verbindung mit Ihrer Datenbank herstellen.

Screenshot einer abgeschlossenen Konfiguration der Portregel für eingehenden Datenverkehr.

Wiederholen Sie das Hinzufügen eingehender Portregeln, bis alle erforderlichen Azure DevOps Services-IPs eine Ausnahme erhalten. Fehlende IP-Adresse kann dazu führen, dass die Migration nicht gestartet werden konnte.

Migrieren großer Sammlungen

Für Datenbanken, die das Datenmigrationstool warnt, ist ein anderer Ansatz zum Verpacken von Daten erforderlich, um zu Azure DevOps Services zu migrieren. Wenn Sie nicht sicher sind, ob Ihre Sammlung den Größenschwellenwert überschreitet, sollten Sie eine Überprüfung des Datenmigrationstools für die Sammlung ausführen. Die Überprüfung teilt Ihnen mit, ob Sie die SQL Azure VM-Methode für die Migration verwenden müssen.

Ermitteln, ob Sie die Sammlungsgröße reduzieren können

Überprüfen Sie, ob Sie alte Daten sauber können. Im Laufe der Zeit können Sammlungen große Datenmengen erstellen. Dieses Wachstum ist ein natürlicher Bestandteil des DevOps-Prozesses, aber Möglicherweise müssen Sie nicht alle Daten aufbewahren. Einige gängige Beispiele für nicht mehr relevante Daten sind ältere Arbeitsbereiche und Buildergebnisse.

Das Datenmigrationstool überprüft Ihre Sammlung und vergleicht sie mit den Grenzwerten, die zuvor Erwähnung wurden. Anschließend wird gemeldet, ob Ihre Sammlung für die DACPAC- oder SQL-Migrationsmethode geeignet ist. Im Allgemeinen ist die Idee, dass Sie, wenn Ihre Sammlung klein genug ist, um in die DACPAC-Grenzwerte passen, den schnelleren und einfacheren DACPAC-Ansatz verwenden können. Wenn Ihre Sammlung jedoch zu groß ist, müssen Sie die SQL-Migrationsmethode verwenden, bei der eine SQL Azure-VM eingerichtet und die Datenbank manuell migriert wird.

Größenbeschränkungen

Die aktuellen Limits lauten wie folgt:

  • 150 GB Gesamtdatenbankgröße (Datenbankmetadaten + Blobs) für DACPAC, wenn Sie diesen Grenzwert überschreiten, müssen Sie die SQL-Migrationsmethode ausführen.
  • 30 GB einzelne Tabellengröße (Datenbankmetadaten + Blobs) für DACPAC, wenn eine einzelne Tabelle diesen Grenzwert überschreitet, müssen Sie die SQL-Migrationsmethode ausführen.
  • 1.536 GB Datenbankmetadatengröße für die SQL-Migrationsmethode. Eine Warnung, die diesen Grenzwert überschreitet, wird empfohlen, dass Sie unter dieser Größe bleiben, um eine erfolgreiche Migration zu haben.
  • 2.048 GB Datenbankmetadatengröße für die SQL-Migrationsmethode. Das Überschreiten dieses Grenzwerts führt zu einem Fehler, sodass Sie keine Migration durchführen können.
  • Kein Grenzwert für BLOB-Größen für die SQL-Migrationsmethode.

Wenn Sie ältere, nicht mehr relevante Artefakte sauber, könnten sie viel mehr Platz entfernen, als Sie erwarten, und es könnte bestimmen, ob Sie die DACPAC-Migrationsmethode oder eine SQL Azure-VM verwenden.

Wichtig

Nachdem Sie ältere Daten gelöscht haben, können Sie sie nur wiederherstellen, wenn Sie eine ältere Sicherung der Sammlung wiederherstellen.

Wenn Sie sich unter dem DACPAC-Schwellenwert befinden, befolgen Sie die Anweisungen zum Generieren eines DACPAC für die Migration. Wenn Sie die Datenbank immer noch nicht unter dem DACPAC-Schwellenwert abrufen können, müssen Sie eine SQL Azure-VM einrichten, um zu Azure DevOps Services zu migrieren.

Einrichten einer SQL Azure-VM zum Migrieren zu Azure DevOps Services

Führen Sie die folgenden allgemeinen Schritte aus, um einen virtuellen SQL Azure-Computer (VM) für die Migration zu Azure DevOps Services einzurichten.

  1. Einrichten einer SQL Azure-VM
  2. Konfigurieren von IP-Firewall-Ausnahmen
  3. Wiederherstellen der Datenbank auf dem virtuellen Computer
  4. [Konfigurieren Der Sammlung für die Migration
  5. Konfigurieren der Migrationsspezifikationsdatei für den virtuellen Computer

Einrichten einer SQL Azure-VM

Sie können eine SQL Azure-VM schnell aus dem Azure-Portal einrichten. Weitere Informationen finden Sie unter Verwenden des Azure-Portal zum Bereitstellen eines virtuellen Windows-Computers mit SQL Server.

Die Leistung Ihrer SQL Azure-VM und angefügter Datenträger hat erhebliche Auswirkungen auf die Leistung der Migration. Aus diesem Grund wird dringend empfohlen, die folgenden Aufgaben auszuführen:

  • Wählen Sie eine VM-Größe auf der Ebene oder höher aus D8s_v5_* .
  • Verwaltete Datenträger verwenden.
  • Sehen Sie sich die Leistung des virtuellen Computers und der Datenträger an. Stellen Sie sicher, dass Ihre Infrastruktur so konfiguriert ist, dass die VM-IOPS (Eingabe/Ausgabe pro Sekunde) und Speicher-IOPS nicht zu einem Engpass bei der Leistung der Migration werden. Stellen Sie beispielsweise sicher, dass die Anzahl der an Ihre VM angefügten Datenträger ausreicht, um die IOPS von der VM zu unterstützen.

Azure DevOps Services ist in mehreren Azure-Regionen auf der ganzen Welt verfügbar. Um sicherzustellen, dass die Migration erfolgreich gestartet wird, ist es wichtig, Ihre Daten in der richtigen Region zu platzieren. Wenn Sie Ihren SQL Azure-virtuellen Computer an einem falschen Speicherort einrichten, kann die Migration nicht gestartet werden.

Wichtig

Der virtuelle Azure-Computer erfordert eine öffentliche IP-Adresse.

Wenn Sie diese Migrationsmethode verwenden, erstellen Sie Ihren virtuellen Computer in einer unterstützten Region. Obwohl Azure DevOps Services in mehreren Regionen im USA (USA) verfügbar ist, akzeptiert nur die Region "Central USA" neue Organisationen. Sie können Ihre Daten jetzt nicht in andere US-Azure-Regionen migrieren.

Hinweis

DACPAC-Kunden sollten die Regionstabelle im Abschnitt "Schritt 3: Hochladen der DACPAC-Datei](Migration-test-run.md#)" konsultieren. Die oben genannten Richtlinien gelten nur für SQL Azure VMs. Wenn Sie ein DACPAC-Kunde sind, lesen Sie unterstützte Azure-Regionen für die Migration.

Verwenden Sie die folgenden SQL Azure-VM-Konfigurationen:

  • Konfigurieren Sie die temporäre SQL-Datenbank so, dass sie ein anderes Laufwerk als Laufwerk C verwendet. Idealerweise sollte das Laufwerk über ausreichend freien Speicherplatz verfügen. entspricht mindestens der größten Tabelle Ihrer Datenbank.
  • Wenn Ihre Quelldatenbank noch über 1 Terabyte (TB) liegt, nachdem Sie die Größe reduziert haben, müssen Sie mehr 1 TB Datenträger anfügen und sie in einer einzigen Partition kombinieren, um Ihre Datenbank auf dem virtuellen Computer wiederherzustellen.
  • Wenn Ihre Sammlungsdatenbanken mehr als 1 TB groß sind, sollten Sie eine SSD (Festkörperfestlaufwerke) sowohl für die temporäre Datenbank als auch für die Sammlungsdatenbank verwenden. Ziehen Sie außerdem die Verwendung größerer VMs mit 16 virtuellen CPUs (vCPUs) und 128 GB (Gigabyte) ram (Random Access Memory) in Betracht.

Wiederherstellen der Datenbank auf dem virtuellen Computer

Nachdem Sie eine Azure-VM eingerichtet und konfiguriert haben, müssen Sie Die getrennten Sicherungen von Ihrer Azure DevOps Server-Instanz auf Ihren virtuellen Azure-Computer durchführen. Die Sammlungsdatenbank muss auf Ihrer SQL-Instanz wiederhergestellt werden, und es muss keine Azure DevOps Server auf dem virtuellen Computer installiert werden.

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.

  1. Öffnen Sie SQL Server Management Studio auf der VM, und öffnen Sie dann ein neues Abfragefenster für die Zu migrierende Datenbank.

  2. Legen Sie die Wiederherstellung der Datenbank auf einfach fest:

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

  3. Erstellen Sie eine SQL-Anmeldung für die Datenbank, und weisen Sie diese Anmeldung bei "TFSEXECROLE" wie im folgenden Beispiel 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>'

Sehen Sie sich das folgende Beispiel des SQL-Befehls an:

    ALTER DATABASE [Foo] SET RECOVERY SIMPLE; 
     
    USE [Foo] 
    CREATE LOGIN fabrikam WITH PASSWORD = 'fabrikamimport1!' 
    CREATE USER fabrikam FOR LOGIN fabrikam WITH DEFAULT_SCHEMA=[dbo] 
    EXEC sp_addrolemember @rolename='TFSEXECROLE', @membername='fabrikam'

Wichtig

Aktivieren Sie SQL Server und Windows-Authentifizierung Modus in SQL Server Management Studio auf der VM. 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 Aktualisierungen vor:

  1. Entfernen Sie den DACPAC-Parameter aus dem Quelldateiobjekt. Die Migrationsspezifikation vor der Änderung sieht wie der folgende Beispielcode aus.

    Screenshot der Migrationsspezifikation vor der Änderung.

    Die Migrationsspezifikation nach der Änderung sieht wie der folgende Beispielcode aus.

    Screenshot der Migrationsspezifikation nach der Änderung.

  2. Geben Sie die erforderlichen Parameter ein, 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.

Screenshot der Migrationsspezifikation, die auf eine SQL Azure-VM verweist.

Ihre Migrationsspezifikation ist jetzt für die Verwendung einer SQL Azure-VM für die Migration konfiguriert. Fahren Sie mit den restlichen Vorbereitungsschritten für die Migration fort. 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.

Erstellen eines Azure Storage-Containers im ausgewählten Rechenzentrum

Die Verwendung des Datenmigrationstools für Azure DevOps erfordert, dass ein Azure Storage-Container im selben Azure-Rechenzentrum wie die endgültige Azure DevOps Services-Organisation vorhanden ist. Wenn Sie beispielsweise beabsichtigen, dass Ihre Azure DevOps Services-Organisation im zentralen USA Rechenzentrum erstellt werden soll, erstellen Sie den Azure Storage-Container im selben Rechenzentrum. Diese Aktion beschleunigt drastisch die Zeit, die zum Migrieren der SQL-Datenbank benötigt wird, da die Übertragung innerhalb desselben Rechenzentrums erfolgt.

Weitere Informationen finden Sie unter Erstellen eines Speicherkontos.

Einrichten der Abrechnung

Eine Nachfrist wird in der neu migrierten Azure DevOps Services-Organisation platziert, damit Ihr Team alle erforderlichen Schritte abschließen und Lizenzzuweisungen korrigieren kann. Wenn Sie davon ausgehen, dass Sie möglicherweise weitere Benutzerpläne, Build- oder Bereitstellungspipelinen, gehostete Builddienste, gehostete Auslastungstestdienste erwerben möchten, empfehlen wir Ihnen beispielsweise dringend, dass Sie über ein Azure-Abonnement verfügen, das für die Verknüpfung mit Ihrer migrierten Organisation bereit ist. Die Nachfrist endet am ersten Tag des folgenden Monats, nachdem Sie die Migration abgeschlossen haben.

Wir erinnern Sie erneut in der Phase nach der Migration(Verknüpfung) daran, wann Sie die Verknüpfung ausführen müssen. Dieser Vorbereitungsschritt dient dazu, sicherzustellen, dass Sie wissen, welches Azure-Abonnement Sie in diesem späteren Schritt verwenden. Weitere Informationen finden Sie unter Einrichten der Abrechnung für Ihre Organisation.

Nächste Schritte

Ausführen der Testausführungsmigration