Share via

Testuitvoeringsmigratie uitvoeren

  • Artikel

Uw team is nu klaar om te beginnen met het starten van een testuitvoering van uw migratie en vervolgens een volledige productiemigratie. In deze fase bespreken we de laatste stappen voor het in de wachtrij plaatsen van een migratie, naast andere taken die doorgaans aan het einde van het migratieproject worden weergegeven.

Diagram waarin de fase Vereisten in opeenvolgende fasen wordt gemarkeerd.

Vereisten

Voltooi de testuitvoeringsfase voorbereiden voordat u een testuitvoeringsmigratie start.

Een verzameling valideren

Valideer elke verzameling die u wilt migreren naar Azure DevOps Services. In de validatiestap worden verschillende aspecten van uw verzameling onderzocht, waaronder, maar niet beperkt tot, grootte, sortering, identiteit en processen.

Voer de validatie uit met behulp van het hulpprogramma voor gegevensmigratie.

  1. Download het hulpprogramma voor gegevensmigratie.

  2. Kopieer het zip-bestand naar een van uw Azure DevOps Server-toepassingslagen.

  3. Pak het bestand uit. U kunt het hulpprogramma ook uitvoeren vanaf een andere computer zonder Dat Azure DevOps Server is geïnstalleerd, zolang de machine verbinding kan maken met de configuratiedatabase van het Azure DevOps Server-exemplaar.

  4. Open een opdrachtpromptvenster op de server en voer een cd-opdracht in om naar de map te gaan waarin het hulpprogramma voor gegevensmigratie is opgeslagen. Neem even de tijd om de Help-inhoud voor het hulpprogramma te bekijken.

    a. Voer de volgende opdracht uit om de Help en richtlijnen op het hoogste niveau weer te geven.

     Migrator /help

    b. Bekijk de Help-tekst voor de opdracht.

     Migrator validate /help

  5. Als de eerste keer dat u een verzameling valideert, moet uw opdracht de volgende eenvoudige structuur hebben.

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

    Waar {name} de naam van uw Microsoft Entra-tenant wordt opgegeven, bijvoorbeeld om uit te voeren op de DefaultCollection en de fabrikam-tenant , ziet de opdracht eruit zoals in het volgende voorbeeld.

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

  6. Als u het hulpprogramma wilt uitvoeren vanaf een andere computer dan de Azure DevOps-server, hebt u de parameter /connectionString nodig. De verbindingsreeks parameter verwijst naar uw Azure DevOps Server-configuratiedatabase. Als de gevalideerde opdracht bijvoorbeeld wordt uitgevoerd door de Fabrikam corporation, zou de opdracht er als volgt uitzien.

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

    Belangrijk

    Het hulpprogramma voor gegevensmigratie bewerkt geen gegevens of structuren in de verzameling. De verzameling wordt alleen gelezen om problemen te identificeren.

  7. Nadat de validatie is voltooid, kunt u de logboekbestanden en resultaten bekijken.

    Schermopname van de validatieresultaten en logboeken in het opdrachtpromptvenster.

    Tijdens de validatie ontvangt u een waarschuwing als sommige pijplijnen bewaarregels per pijplijn bevatten. Azure DevOps Services maakt gebruik van een bewaarmodel op basis van een project en biedt geen ondersteuning voor bewaarbeleid per pijplijn. Als u doorgaat met de migratie, worden de beleidsregels niet overgedragen naar de gehoste versie. In plaats daarvan zijn het standaard bewaarbeleid op projectniveau van toepassing. Behoud builds die belangrijk zijn voor u om verlies te voorkomen.

Nadat alle validaties zijn geslaagd, kunt u naar de volgende stap van het migratieproces gaan. Als het hulpprogramma voor gegevensmigratie fouten markeert, corrigeert u deze voordat u verdergaat. Zie Migratie- en migratiefouten oplossen voor hulp bij het corrigeren van validatiefouten.

Logboekbestanden importeren

Wanneer u de logboekmap opent, ziet u mogelijk verschillende logboekbestanden.

Het hoofdlogboekbestand heeft de naam DataMigrationTool.log. Het bevat details over alles wat is uitgevoerd. Om u gemakkelijker te richten op specifieke gebieden, wordt er een logboek gegenereerd voor elke primaire validatiebewerking.

Als TfsMigrator bijvoorbeeld een fout rapporteert in de stap 'Projectprocessen valideren', kunt u het ProjectProcessMap.log bestand openen om alles weer te geven dat voor die stap is uitgevoerd in plaats van door het hele logboek te bladeren.

Controleer het TryMatchOobProcesses.log bestand alleen als u uw projectprocessen wilt migreren om het overgenomen model te gebruiken. Als u het overgenomen model niet wilt gebruiken, kunt u deze fouten negeren, omdat u hiermee niet kunt importeren in Azure DevOps Services. Zie de validatiefase van de migratie voor meer informatie.

Migratiebestanden genereren

Het hulpprogramma voor gegevensmigratie heeft de verzameling gevalideerd en retourneert een resultaat van 'Alle verzamelingsvalidaties geslaagd'. Voordat u een verzameling offline neemt om deze te migreren, genereert u de migratiebestanden. Wanneer u de prepare opdracht uitvoert, genereert u twee migratiebestanden:

  • IdentityMapLog.csv: geeft een overzicht van uw identiteitsoverzicht tussen Active Directory en Microsoft Entra-id.
  • migration.json: Hiervoor moet u de migratiespecificatie invullen die u wilt gebruiken om de migratie te starten.

Opdracht Voorbereiden

De prepare opdracht helpt bij het genereren van de vereiste migratiebestanden. In wezen scant deze opdracht de verzameling naar een lijst met alle gebruikers om het identiteitsoverzichtlogboek te vullen, IdentityMapLog.csv en probeert vervolgens verbinding te maken met Microsoft Entra-id om de overeenkomst van elke identiteit te vinden. Hiervoor moet uw bedrijf het hulpprogramma Microsoft Entra Verbinding maken gebruiken (voorheen bekend als het hulpprogramma Adreslijstsynchronisatie, directorysynchronisatie of DirSync.exe hulpprogramma).

Als adreslijstsynchronisatie is ingesteld, moet het hulpprogramma voor gegevensmigratie de overeenkomende identiteiten vinden en deze markeren als Actief. Als er geen overeenkomsten zijn, wordt de identiteit gemarkeerd als Historisch in het identiteitsoverzichtslogboek. Daarom moet u onderzoeken waarom de gebruiker niet is opgenomen in de adreslijstsynchronisatie. Het migratiespecificatiebestand, migration.json, moet vóór de migratie worden ingevuld.

In tegenstelling tot de validate opdracht prepareis een internetverbinding vereist, omdat deze verbinding moet maken met Microsoft Entra ID om het logboekbestand voor identiteitstoewijzing te vullen. Als uw Azure DevOps Server-exemplaar geen internettoegang heeft, voert u het hulpprogramma uit vanaf een computer die dat wel doet. Zolang u een computer met een intranetverbinding met uw Azure DevOps Server-exemplaar en een internetverbinding kunt vinden, kunt u deze opdracht uitvoeren. Voer de volgende opdracht uit voor hulp bij de prepare opdracht:

Migrator prepare /help

Opgenomen in de Help-documentatie zijn instructies en voorbeelden voor het uitvoeren van de Migrator opdracht vanuit het Azure DevOps Server-exemplaar zelf en een externe computer. Als u de opdracht uitvoert vanuit een van de toepassingslagen van het Azure DevOps Server-exemplaar, moet uw opdracht de volgende structuur hebben:

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"

De parameter connectionString is een verwijzing naar de configuratiedatabase van uw Azure DevOps Server-exemplaar. Als de Fabrikam-onderneming bijvoorbeeld de prepare opdracht uitvoert, ziet de opdracht eruit als in het volgende voorbeeld:

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

Wanneer het hulpprogramma voor gegevensmigratie de prepare opdracht uitvoert, wordt er een volledige validatie uitgevoerd om ervoor te zorgen dat er niets is gewijzigd met uw verzameling sinds de laatste volledige validatie. Als er nieuwe problemen worden gedetecteerd, worden er geen migratiebestanden gegenereerd.

Kort nadat de opdracht wordt uitgevoerd, wordt er een aanmeldingsvenster van Microsoft Entra weergegeven. Meld u aan met een identiteit die deel uitmaakt van het tenantdomein, dat is opgegeven in de opdracht. Zorg ervoor dat de opgegeven Microsoft Entra-tenant de tenant is waarmee u wilt dat uw toekomstige organisatie wordt ondersteund. In ons Fabrikam-voorbeeld voert een gebruiker referenties in die vergelijkbaar zijn met de volgende voorbeeldschermafbeelding.

Belangrijk

Gebruik geen Microsoft Entra-testtenant voor een testmigratie en uw productie-Microsoft Entra-tenant voor de productieuitvoering. Als u een Test-Tenant van Microsoft Entra gebruikt, kan dit leiden tot identiteitsmigratieproblemen wanneer u begint met de productieuitvoering met de Microsoft Entra-tenant van uw organisatie.

Wanneer u de prepare opdracht met succes uitvoert in het hulpprogramma voor gegevensmigratie, worden in het resultatenvenster een set logboeken en twee migratiebestanden weergegeven. Zoek in de logboekmap een map met logboeken en twee bestanden:

  • migration.json is het migratiespecificatiebestand. We raden u aan de tijd te nemen om het in te vullen.
  • IdentityMapLog.csv bevat de gegenereerde toewijzing van Active Directory aan Microsoft Entra-identiteiten. Bekijk deze volledigheid voordat u een migratie start.

De twee bestanden worden uitgebreid beschreven in de volgende secties.

Het migratiespecificatiebestand

De migratiespecificatie, migration.json, is een JSON-bestand dat migratie-instellingen biedt. Het bevat de gewenste organisatienaam, opslagaccountgegevens en andere informatie. De meeste velden worden automatisch ingevuld en sommige velden vereisen uw invoer voordat u een migratie uitvoert.

Schermopname van een zojuist gegenereerd migratiespecificatiebestand.

De weergegeven velden en vereiste acties van het migration.json-bestand worden beschreven in de volgende tabel:

Veld Beschrijving Vereiste actie
Bron Informatie over de locatie en namen van de brongegevensbestanden die worden gebruikt voor migratie. Geen actie vereist. Bekijk de informatie die moet worden gevolgd door de subveldacties.
Locatie De Shared Access Signature-sleutel voor het Azure-opslagaccount dat als host fungeert voor het DACPAC (Data Tier Application Package). Geen actie vereist. Dit veld wordt in een latere stap behandeld.
Bestanden De namen van de bestanden met migratiegegevens. Geen actie vereist. Bekijk de informatie die moet worden gevolgd door de subveldacties.
DACPAC Een DACPAC-bestand dat de verzamelingsdatabase verpakt die moet worden gebruikt voor het ophalen van de gegevens tijdens de migratie. Geen actie vereist. In een latere stap maakt u dit bestand met behulp van uw verzameling en uploadt u het vervolgens naar een Azure-opslagaccount. Werk het bestand bij op basis van de naam die u gebruikt wanneer u het later in dit proces genereert.
Doel Eigenschappen van de nieuwe organisatie naar migratie. Geen actie vereist. Bekijk de informatie die moet worden gevolgd door de subveldacties.
Naam De naam van de organisatie die moet worden gemaakt tijdens de migratie. Geef een naam op. De naam kan later snel worden gewijzigd nadat de migratie is voltooid.
OPMERKING: Maak geen organisatie met deze naam voordat u de migratie uitvoert. De organisatie wordt gemaakt als onderdeel van het migratieproces.
ImportType Het type migratie dat u wilt uitvoeren. Geen actie vereist. Selecteer in een latere stap het type migratie dat moet worden uitgevoerd.
Validatiegegevens Informatie die nodig is om uw migratie-ervaring te stimuleren. Het hulpprogramma voor gegevensmigratie genereert de sectie Validatiegegevens. Het bevat informatie om uw migratie-ervaring te stimuleren. Bewerk de waarden in deze sectie niet* of de migratie kan niet worden gestart.

Nadat u het voorgaande proces hebt voltooid, moet u een bestand hebben dat eruitziet als in het volgende voorbeeld.

Schermopname van een gedeeltelijk voltooid migratiespecificatiebestand.

In de vorige afbeelding heeft de planner van de Fabrikam-migratie de naam fabrikam-import toegevoegd en de geselecteerde CUS (Central Verenigde Staten) als de geografische locatie voor migratie. Andere waarden zijn ongewijzigd gebleven, net voordat de planner de verzameling offline heeft gehaald voor de migratie.

Notitie

Importbewerkingen voor testuitvoeringen hebben automatisch een '-dryrun' toegevoegd aan het einde van de organisatienaam, die u na de migratie kunt wijzigen.

Ondersteunde Azure-regio's voor migratie

Azure DevOps Services is beschikbaar op verschillende geografische Locaties van Azure. Maar niet alle locaties waar Azure DevOps Services beschikbaar is, worden ondersteund voor migratie. De volgende tabel bevat de geografische Azure-locaties die u kunt selecteren voor migratie. Ook inbegrepen is de waarde die u moet plaatsen in het migratiespecificatiebestand om die geografie voor migratie te targeten.

Geografische locatie Geografische azure-locatie Specificatiewaarde importeren
Verenigde Staten Centrale Verenigde Staten CUS
Europa West-Europa WEU
Verenigd Koninkrijk Verenigd Koninkrijk (Zuid) UKS
Australië Australië - oost EAU
Zuid-Amerika Brazilië - zuid SBR
Azië en Stille Oceaan India - zuid MA
Azië en Stille Oceaan Azië - zuidoost (Singapore) SEA
Canada Canada - centraal CC

Het identiteitsoverzichtslogboek

Het identiteitsoverzichtslogboek is van gelijke betekenis voor de werkelijke gegevens die u migreert naar Azure DevOps Services. Wanneer u het bestand bekijkt, is het belangrijk om te begrijpen hoe identiteitsmigratie werkt en wat de mogelijke resultaten kunnen inhouden. Wanneer u een identiteit migreert, kan deze actief of historisch worden. Actieve identiteiten kunnen zich aanmelden bij Azure DevOps Services, maar historische identiteiten kunnen niet.

Actieve identiteiten

Actieve identiteiten verwijzen na de migratie naar gebruikersidentiteiten in Azure DevOps Services. In Azure DevOps Services worden deze identiteiten gelicentieerd en weergegeven als gebruikers in de organisatie. De identiteiten worden gemarkeerd als actief in de kolom Verwachte importstatus in het logboekbestand voor identiteitstoewijzing.

Historische identiteiten

Historische identiteiten worden als zodanig toegewezen in de kolom Verwachte importstatus in het logboekbestand voor identiteitstoewijzing. Identiteiten zonder regelvermelding in het bestand worden ook historisch. Een voorbeeld van een identiteit zonder regelvermelding kan een werknemer zijn die niet meer in een bedrijf werkt.

In tegenstelling tot actieve identiteiten, historische identiteiten:

  • Geen toegang tot een organisatie na de migratie.
  • Geen licenties.
  • Niet weergeven als gebruikers in de organisatie. Alles wat zich blijft voordoen, is het idee van de naam van die identiteit in de organisatie, zodat de geschiedenis later kan worden doorzocht. U wordt aangeraden historische identiteiten te gebruiken voor gebruikers die niet langer in het bedrijf werken of die geen verdere toegang tot de organisatie nodig hebben.

Notitie

Nadat een identiteit als historisch is geïmporteerd, kan deze niet meer actief worden.

Inzicht in het logboekbestand voor identiteitstoewijzing

Het logboekbestand voor identiteitstoewijzing is vergelijkbaar met het voorbeeld dat hier wordt weergegeven:

Schermopname van een logboekbestand voor identiteitstoewijzing dat wordt gegenereerd door het hulpprogramma voor gegevensmigratie.

De kolommen in het logboekbestand voor identiteitstoewijzing worden beschreven in de volgende tabel:

U en uw Microsoft Entra-beheerder moeten gebruikers onderzoeken die zijn gemarkeerd als Geen overeenkomst gevonden (Controleer Microsoft Entra ID Sync) om te begrijpen waarom ze geen deel uitmaken van uw Microsoft Entra Verbinding maken Sync.

Kolom Beschrijving
Active Directory: gebruiker (Azure DevOps-server) De beschrijvende weergavenaam die wordt gebruikt door de identiteit in Azure DevOps Server. Met deze naam kunt u gemakkelijker identificeren welke gebruiker de regel in de kaart verwijst.
Active Directory: beveiligings-id De unieke id voor de on-premises Active Directory-identiteit in Azure DevOps Server. Deze kolom wordt gebruikt om gebruikers in de verzameling te identificeren.
Microsoft Entra-id: Verwachte importgebruiker (Azure DevOps Services) Ofwel het verwachte aanmeldingsadres van de overeenkomende gebruiker die binnenkort actief is of Geen overeenkomst gevonden (Controleer Microsoft Entra ID Sync) die aangeeft dat de identiteit is verloren gegaan tijdens de Synchronisatie van Microsoft Entra-id's en wordt geïmporteerd als historisch.
Verwachte importstatus De verwachte migratiestatus van de gebruiker: Actief als er een overeenkomst is tussen uw Active Directory en Microsoft Entra-id, of historisch als er geen overeenkomst is.
Validatiedatum De laatste keer dat het identiteitsoverzichtlogboek is gevalideerd.

Terwijl u het bestand leest, ziet u of de waarde in de kolom Verwachte importstatus actief of historisch is. Actief geeft aan dat de identiteit op deze rij correct wordt toegewezen bij migratie. Historisch betekent dat de identiteiten historisch worden bij migratie. Het is belangrijk om het gegenereerde toewijzingsbestand te controleren op volledigheid en juistheid.

Belangrijk

De migratie mislukt als er grote wijzigingen optreden in uw Microsoft Entra Verbinding maken beveiligings-id-synchronisatie tussen migratiepogingen. U kunt nieuwe gebruikers toevoegen tussen testuitvoeringen en u kunt correcties aanbrengen om ervoor te zorgen dat eerder geïmporteerde historische identiteiten actief worden. U kunt echter geen bestaande gebruiker wijzigen die eerder als actief is geïmporteerd. Als u dit doet, mislukt de migratie. Een voorbeeld van een wijziging is het voltooien van een testuitvoeringsmigratie, het verwijderen van een identiteit uit uw Microsoft Entra-id die actief is geïmporteerd, het opnieuw maken van een nieuwe gebruiker in Microsoft Entra ID voor diezelfde identiteit en vervolgens een andere migratie probeert uit te voeren. In dit geval probeert een actieve identiteitsmigratie tussen de Active Directory en de zojuist gemaakte Microsoft Entra-identiteit, maar veroorzaakt een migratiefout.

  1. Controleer de correct overeenkomende identiteiten. Zijn alle verwachte identiteiten aanwezig? Zijn de gebruikers toegewezen aan de juiste Microsoft Entra-identiteit?

    Als er waarden moeten worden gewijzigd, neemt u contact op met uw Microsoft Entra-beheerder om te controleren of de on-premises Active Directory-identiteit deel uitmaakt van de synchronisatie met Microsoft Entra-id en correct is ingesteld. Zie Uw on-premises identiteiten integreren met Microsoft Entra-id voor meer informatie.

  2. Bekijk vervolgens de identiteiten die zijn gelabeld als historisch. Deze labeling impliceert dat een overeenkomende Microsoft Entra-identiteit om een van de volgende redenen niet kan worden gevonden:

    • De identiteit is niet ingesteld voor synchronisatie tussen on-premises Active Directory en Microsoft Entra-id.
    • De identiteit is nog niet ingevuld in uw Microsoft Entra-id (er is bijvoorbeeld een nieuwe werknemer).
    • De identiteit bestaat niet in uw Microsoft Entra-exemplaar.
    • De gebruiker die eigenaar is van die identiteit werkt niet meer in het bedrijf.

Als u de eerste drie redenen wilt aanpakken, stelt u de beoogde on-premises Active Directory-identiteit in om te synchroniseren met Microsoft Entra-id. Zie Uw on-premises identiteiten integreren met Microsoft Entra-id voor meer informatie. U moet Microsoft Entra Verbinding maken instellen en uitvoeren om identiteiten te importeren als actief in Azure DevOps Services.

U kunt de vierde reden negeren, omdat werknemers die zich niet meer in het bedrijf bevinden, als historisch moeten worden geïmporteerd.

Historische identiteiten (kleine teams)

Notitie

De strategie voor identiteitsmigratie die in deze sectie wordt voorgesteld, moet alleen door kleine teams worden overwogen.

Als Microsoft Entra Verbinding maken niet is geconfigureerd, worden alle gebruikers in het logboekbestand voor identiteitstoewijzing gemarkeerd als historisch. Als u een migratie op deze manier uitvoert, worden alle gebruikers als historisch geïmporteerd. We raden u ten zeere aan Microsoft Entra Verbinding maken te configureren om ervoor te zorgen dat uw gebruikers als actief worden geïmporteerd.

Het uitvoeren van een migratie met alle historische identiteiten heeft gevolgen die zorgvuldig moeten worden overwogen. Alleen teams met een paar gebruikers en waarvoor de kosten voor het instellen van Microsoft Entra Verbinding maken te hoog worden geacht, moeten overwegen.

Als u alle identiteiten als historisch wilt migreren, volgt u de stappen die in latere secties worden beschreven. Wanneer u een migratie in de wachtrij zet, wordt de identiteit die wordt gebruikt om de migratie in de wachtrij te plaatsen, in de organisatie opgestart als de eigenaar van de organisatie. Alle andere gebruikers worden geïmporteerd als historisch. Eigenaren van organisaties kunnen de gebruikers vervolgens weer toevoegen met behulp van hun Microsoft Entra-identiteit. De toegevoegde gebruikers worden behandeld als nieuwe gebruikers. Ze hebben geen* eigen geschiedenis en er is geen manier om deze geschiedenis te reparen naar de Microsoft Entra-identiteit. Gebruikers kunnen hun voormigratiegeschiedenis echter nog steeds opzoeken door te zoeken naar hun \<domain>\<Active Directory username>.

Het hulpprogramma voor gegevensmigratie geeft een waarschuwing weer als het volledige scenario met historische identiteiten wordt gedetecteerd. Als u besluit dit migratiepad af te gaan, moet u toestemming geven in het hulpprogramma voor de beperkingen.

Visual Studio-abonnementen

Het hulpprogramma voor gegevensmigratie kan Visual Studio-abonnementen (voorheen MSDN-voordelen genoemd) niet detecteren wanneer het logboekbestand voor identiteitstoewijzing wordt gegenereerd. In plaats daarvan raden we u aan de functie voor automatische licentie-upgrade toe te passen na de migratie. Zolang de werkaccounts van gebruikers correct zijn gekoppeld , past Azure DevOps Services automatisch de voordelen van hun Visual Studio-abonnement toe bij hun eerste aanmelding na de migratie. Er worden nooit kosten in rekening gebracht voor licenties die tijdens de migratie worden toegewezen, zodat u daarna veilig abonnementen kunt afhandelen.

U hoeft geen testuitvoeringsmigratie te herhalen als de Visual Studio-abonnementen van gebruikers niet automatisch worden bijgewerkt in Azure DevOps Services. Het koppelen van Visual Studio-abonnementen vindt plaats buiten het bereik van een migratie. Zolang hun werkaccount correct is gekoppeld vóór of na de migratie, worden de licenties van gebruikers automatisch bijgewerkt bij hun volgende aanmelding. Nadat hun licenties zijn geüpgraded, worden de gebruikers de volgende keer dat u een migratie uitvoert, automatisch bijgewerkt bij hun eerste aanmelding bij de organisatie.

Voorbereiden op migratie

Nu hebt u alles klaar om uit te voeren tijdens de migratie van de testuitvoering. Plan downtime met uw team om de verzameling offline te halen voor de migratie. Wanneer u akkoord gaat met het uitvoeren van de migratie, uploadt u de vereiste assets die u hebt gegenereerd en een kopie van de database naar Azure. Het voorbereiden van de migratie bestaat uit de volgende vijf stappen.

Stap 1: Haal de verzameling offline en ontkoppel deze. Stap 2: Genereer een DACPAC-bestand op basis van de verzameling die u gaat migreren.
Stap 3: Upload het DACPAC-bestand en de migratiebestanden naar een Azure-opslagaccount.
Stap 4: Genereer een SAS-token voor toegang tot het opslagaccount.
Stap 5: Voltooi de migratiespecificatie.

Notitie

Voordat u een productiemigratie uitvoert, raden we u ten zeerste aan een testuitvoeringsmigratie te voltooien. Met een testuitvoering kunt u controleren of het migratieproces werkt voor uw verzameling en dat er geen unieke gegevensshapes aanwezig zijn die een productiemigratiefout kunnen veroorzaken.

Stap 1: uw verzameling loskoppelen

Het loskoppelen van de verzameling is een cruciale stap in het migratieproces. Identiteitsgegevens voor de verzameling bevinden zich in de configuratiedatabase van het Azure DevOps Server-exemplaar terwijl de verzameling is gekoppeld en online is. Wanneer een verzameling is losgekoppeld van het Azure DevOps Server-exemplaar, worden die identiteitsgegevens gekopieerd en verpakt met de verzameling voor transport. Zonder deze gegevens kan het identiteitsgedeelte van de migratie niet worden uitgevoerd.

Tip

U wordt aangeraden de verzameling los te houden totdat de migratie is voltooid, omdat er geen manier is om de wijzigingen te migreren die zijn opgetreden tijdens de migratie. Sluit uw verzameling opnieuw aan nadat u een back-up hebt voor migratie, dus u maakt zich geen zorgen over het hebben van de meest recente gegevens voor dit type migratie. Als u offlinetijd helemaal wilt voorkomen, kunt u er ook voor kiezen om offline loskoppelen te gebruiken voor testuitvoeringen.

Het is belangrijk dat u de kosten van het kiezen voor nul downtime voor een testuitvoering afwegen. Hiervoor moeten back-ups van de verzamelings- en configuratiedatabase worden gemaakt, worden hersteld in een SQL-exemplaar en vervolgens een losgekoppelde back-up worden gemaakt. Een kostenanalyse kan aantonen dat het uiteindelijk beter is om slechts een paar uur uitvaltijd te nemen om de losgekoppelde back-up rechtstreeks te maken.

Stap 2: een DACPAC-bestand genereren

DACPACs bieden een snelle en relatief eenvoudige methode voor het verplaatsen van verzamelingen naar Azure DevOps Services. Nadat de grootte van een verzamelingsdatabase echter een bepaalde drempelwaarde overschrijdt, nemen de voordelen van het gebruik van een DACPAC af.

Notitie

Als in het hulpprogramma voor gegevensmigratie een waarschuwing wordt weergegeven dat u de DACPAC-methode niet kunt gebruiken, moet u de migratie uitvoeren met behulp van de virtuele SQL Azure-machinemethode (VM). Sla stap 2 tot en met 5 over en volg de instructies in de sectie Testuitvoering voorbereiden, sectie Grote verzamelingen migreren en ga vervolgens verder met het bepalen van het migratietype. Als het hulpprogramma voor gegevensmigratie geen waarschuwing weergeeft, gebruikt u de DACPAC-methode die in deze stap wordt beschreven.

DACPAC is een functie van SQL Server waarmee databases kunnen worden verpakt in één bestand en kunnen worden geïmplementeerd in andere exemplaren van SQL Server. Een DACPAC-bestand kan ook rechtstreeks worden hersteld naar Azure DevOps Services, zodat u het kunt gebruiken als de verpakkingsmethode voor het ophalen van de gegevens van uw verzameling in de cloud.

Belangrijk

  • Wanneer u SqlPackage.exe gebruikt, moet u de .NET Framework-versie van SqlPackage.exe gebruiken om de DACPAC voor te bereiden. Het MSI-installatieprogramma moet worden gebruikt om de .NET Framework-versie van SqlPackage.exe te installeren. Gebruik de dotnet CLI- of .zip (Windows .NET 6)-versies van SqlPackage.exe niet, omdat deze versies DACPACs kunnen genereren die niet compatibel zijn met Azure DevOps Services.
  • Versie 161 van SqlPackage versleutelt standaard databaseverbindingen en maakt mogelijk geen verbinding. Als u een aanmeldingsprocesfout ontvangt, voegt u deze toe ;Encrypt=False;TrustServerCertificate=True aan de verbindingsreeks van de SqlPackage-instructie.

Download en installeer SqlPackage.exe met behulp van het nieuwste MSI-installatieprogramma uit de releaseopmerkingen van SqlPackage.

Nadat u het MSI-installatieprogramma hebt gebruikt, SqlPackage.exe wordt geïnstalleerd in een pad dat vergelijkbaar is met %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\.

Wanneer u een DACPAC genereert, moet u rekening houden met twee overwegingen: de schijf waarop de DACPAC is opgeslagen en de schijfruimte op de computer die de DACPAC genereert. U wilt ervoor zorgen dat u voldoende schijfruimte hebt om de bewerking te voltooien.

Terwijl het pakket wordt gemaakt, slaat SqlPackage.exe tijdelijk gegevens op uit uw verzameling in de tijdelijke map op station C van de computer waarvan u de verpakkingsaanvraag start.

Mogelijk vindt u dat uw station C te klein is voor het maken van een DACPAC. U kunt een schatting maken van de hoeveelheid ruimte die u nodig hebt door te zoeken naar de grootste tabel in uw verzamelingsdatabase. DACPACs worden één tabel tegelijk gemaakt. De maximale hoeveelheid ruimte die nodig is om de generatie uit te voeren, is ongeveer gelijk aan de grootte van de grootste tabel in de database van de verzameling. Als u de gegenereerde DACPAC opslaat naar station C, moet u rekening houden met de grootte van de verzamelingsdatabase zoals gerapporteerd in het DataMigrationTool.log-bestand na een validatieuitvoering.

Het bestand DataMigrationTool.log bevat een lijst met de grootste tabellen in de verzameling telkens wanneer de opdracht wordt uitgevoerd. Zie de volgende uitvoer voor een voorbeeld van tabelgrootten voor een verzameling. Vergelijk de grootte van de grootste tabel met de vrije ruimte op het station dat als host fungeert voor uw tijdelijke map.

Belangrijk

Voordat u doorgaat met het genereren van een DACPAC-bestand, moet u ervoor zorgen dat uw verzameling is losgekoppeld.

[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

Zorg ervoor dat het station dat als host fungeert voor uw tijdelijke map minstens zoveel vrije ruimte heeft. Als dit niet het probleem is, moet u de tijdelijke map omleiden door een omgevingsvariabele in te stellen.

SET TEMP={location on disk}

Een andere overweging is waar de DACPAC-gegevens worden opgeslagen. Als u de opgeslagen locatie naar een verre externe schijf wijst, kan dit leiden tot langere generatietijden. Als een snelle schijf zoals een SSD (Solid-State Drive) lokaal beschikbaar is, raden we u aan om het station als de DACPAC-opslaglocatie te richten. Anders is het altijd sneller om een schijf te gebruiken die zich op de computer bevindt waarop de verzamelingsdatabase zich bevindt in plaats van een extern station.

Nu u de doellocatie voor de DACPAC hebt geïdentificeerd en ervoor hebt gezorgd dat u voldoende ruimte hebt, is het tijd om het DACPAC-bestand te genereren.

Open een opdrachtpromptvenster en ga naar de SqlPackage.exe locatie. Als u de DACPAC wilt genereren, vervangt u de tijdelijke aanduidingen door de vereiste waarden en voert u vervolgens de volgende opdracht uit:

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
  • Gegevensbron: het SQL Server-exemplaar dat als host fungeert voor uw Azure DevOps Server-verzamelingsdatabase.
  • Initiële catalogus: de naam van de verzamelingsdatabase.
  • targetFile: de locatie op de schijf en de naam van het DACPAC-bestand.

In het volgende voorbeeld wordt een DACPAC-generatieopdracht weergegeven die wordt uitgevoerd op de Azure DevOps Server-gegevenslaag zelf:

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

De uitvoer van de opdracht is een DACPAC-bestand dat is gegenereerd op basis van de verzamelingsdatabase Foo.dacpac.

Uw verzameling configureren voor migratie

Nadat de verzamelingsdatabase is hersteld op uw Azure-VM, configureert u een SQL-aanmelding zodat Azure DevOps Services verbinding kan maken met de database om de gegevens te migreren. Met deze aanmelding is alleen leestoegang tot één database toegestaan.

Als u wilt beginnen, opent u SQL Server Management Studio op de virtuele machine en opent u vervolgens een nieuw queryvenster voor de database die u wilt importeren.

Stel het herstel van de database in op eenvoudig:

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

Maak een SQL-aanmelding voor de database en wijs die aanmelding toe aan TFSEXECROLE:

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>'

Na ons Fabrikam-voorbeeld zien de twee SQL-opdrachten eruit als in het volgende voorbeeld:

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'

Notitie

Schakel sql Server- en Windows-verificatiemodus in in SQL Server Management Studio op de VIRTUELE machine. Als u de verificatiemodus niet inschakelt, mislukt de migratie.

Het migratiespecificatiebestand configureren om de VM te targeten

Werk het migratiespecificatiebestand bij met informatie over het maken van verbinding met het SQL Server-exemplaar. Open uw migratiespecificatiebestand en voer de volgende updates uit.

  1. Verwijder de DACPAC-parameter uit het bronbestandenobject.

    De migratiespecificatie voordat de wijziging wordt weergegeven in de volgende code.

    Schermopname van de migratiespecificatie vóór de wijziging.

    De migratiespecificatie na de wijziging wordt weergegeven in de volgende code.

    Schermopname van de migratiespecificatie na de wijziging.

  2. Vul de vereiste parameters in en voeg het volgende eigenschappenobject toe in uw bronobject in het specificatiebestand.

    "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" 
}

Nadat u de wijzigingen hebt toegepast, ziet de migratiespecificatie eruit zoals in het volgende voorbeeld.

Schermopname van de migratiespecificatie die verwijst naar een SQL Azure-VM.

Uw migratiespecificatie is nu geconfigureerd voor het gebruik van een SQL Azure-VM voor migratie. Ga verder met de rest van de voorbereidingsstappen voor migratie naar Azure DevOps Services. Nadat de migratie is voltooid, moet u de SQL-aanmelding verwijderen of het wachtwoord roteren. Microsoft behoudt de aanmeldingsgegevens niet nadat de migratie is voltooid.

Stap 3: Het DACPAC-bestand uploaden

Notitie

Als u de SQL Azure VM-methode gebruikt, moet u alleen de verbindingsreeks opgeven. U hoeft geen bestanden te uploaden en u kunt deze stap overslaan.

Uw DACPAC moet in een Azure Storage-container worden geplaatst. Dit kan een bestaande container zijn of een container die specifiek is gemaakt voor uw migratie. Het is belangrijk om ervoor te zorgen dat uw container op de juiste geografische locaties wordt gemaakt.

Azure DevOps Services is beschikbaar op meerdere geografische locaties. Wanneer u naar deze locaties importeert, is het essentieel om uw gegevens correct te plaatsen om ervoor te zorgen dat de migratie kan worden gestart. Uw gegevens moeten op dezelfde geografische locatie worden geplaatst als waar u naar importeert. Als u de gegevens ergens anders plaatst, kan de migratie niet worden gestart. De volgende tabel bevat de acceptabele geografische locaties voor het maken van uw opslagaccount en het uploaden van uw gegevens.

Gewenste geografische locatie voor migratie Geografische locatie van opslagaccount
Centrale Verenigde Staten Centrale Verenigde Staten
West-Europa West-Europa
Verenigd Koninkrijk Verenigd Koninkrijk (Zuid)
Australië - oost Australië - oost
Brazilië - zuid Brazilië - zuid
India - zuid India - zuid
Canada - midden Canada - midden
Azië en Stille Oceaan (Singapore) Azië en Stille Oceaan (Singapore)

Hoewel Azure DevOps Services beschikbaar is op meerdere geografische locaties in de VS, accepteert alleen de centrale Verenigde Staten locatie nieuwe Azure DevOps Services. U kunt uw gegevens op dit moment niet migreren naar andere Azure-locaties in de VS.

Een blobcontainer maken vanuit Azure Portal. Nadat u de container hebt gemaakt, uploadt u het DACPAC-bestand collection.

Nadat de migratie is voltooid, verwijdert u de blobcontainer en het bijbehorende opslagaccount met hulpprogramma's zoals AzCopy of een ander hulpprogramma voor Azure Storage Explorer, zoals Azure Storage Explorer.

Notitie

Als uw DACPAC-bestand groter is dan 10 GB, raden we u aan AzCopy te gebruiken. AzCopy biedt ondersteuning voor multithreaded uploaden voor snellere uploads.

Stap 4: Een SAS-token genereren

Een SAS-token (Shared Access Signature) biedt gedelegeerde toegang tot resources in een opslagaccount. Met het token kunt u Microsoft het laagste niveau van bevoegdheden geven dat is vereist voor toegang tot uw gegevens voor het uitvoeren van de migratie.

U kunt SAS-tokens genereren met behulp van Azure Portal. Vanuit een beveiligingspunt raden we u aan de volgende taken uit te voeren:

  1. Selecteer alleen Lezen en Weergeven als machtigingen voor uw SAS-token. Er zijn geen andere machtigingen vereist.
  2. Stel een verlooptijd in die niet langer is dan zeven dagen in de toekomst.
  3. Alleen ip-adressen van Azure DevOps Services beperken.
  4. Behandel de SAS-sleutel als een geheim. Laat de sleutel niet op een onveilige locatie staan, omdat hiermee lees- en lijsttoegang wordt verleend tot gegevens die u in de container hebt opgeslagen.

Stap 5: de migratiespecificatie voltooien

Eerder in het proces hebt u het migratiespecificatiebestand, ook wel migration.json genoemd, gedeeltelijk ingevuld. Op dit moment hebt u voldoende informatie om alle resterende velden te voltooien, met uitzondering van het migratietype. Het migratietype wordt later behandeld in de sectie Migratie.

Vul in het migration.json specificatiebestand onder Bron de volgende velden in.

  • Locatie: Plak de SAS-sleutel die u hebt gegenereerd op basis van het script en kopieer vervolgens in de vorige stap.
  • Dacpac: Zorg ervoor dat het bestand, inclusief de bestandsextensie .dacpac , dezelfde naam heeft als het DACPAC-bestand dat u naar het opslagaccount hebt geüpload.

Het uiteindelijke migratiespecificatiebestand moet eruitzien zoals in het volgende voorbeeld.

Schermopname van het voltooide migratiespecificatiebestand.

Het migratietype bepalen

Importbewerkingen kunnen in de wachtrij worden geplaatst als een testuitvoering of een productieuitvoering. De parameter ImportType bepaalt het migratietype:

  • TestRun: Gebruik een testuitvoering voor testdoeleinden. Het systeem verwijdert testuitvoeringen na 45 dagen.
  • ProductionRun: Gebruik een productieuitvoering wanneer u de resulterende migratie wilt behouden en de organisatie fulltime wilt gebruiken in Azure DevOps Services nadat de migratie is voltooid.

Tip

U wordt altijd aangeraden eerst een testuitvoeringsmigratie te voltooien.

Schermopname van het voltooide migratiespecificatiebestand met het migratietype.

Testuitvoeringsorganisaties

Testuitvoeringsorganisaties helpen teams bij het testen van de migratie van hun verzamelingen. Voordat een productiemigratie kan worden uitgevoerd, moeten alle voltooide testuitvoeringsorganisaties worden verwijderd. Alle testuitvoeringsorganisaties hebben een beperkt bestaan en worden automatisch verwijderd na een bepaalde periode. Informatie over wanneer de organisatie wordt verwijderd, wordt opgenomen in de e-mail met succes die u moet ontvangen nadat de migratie is voltooid. Noteer deze datum en plan dienovereenkomstig.

Testuitvoeringsorganisaties hebben 45 dagen voordat ze worden verwijderd. Na de opgegeven periode wordt de testuitvoeringsorganisatie verwijderd. U kunt de importbewerkingen voor testuitvoeringen zo vaak herhalen als u nodig hebt voordat u een productiemigratie uitvoert.

Testuitvoeringen verwijderen

Verwijder eventuele eerdere testuitvoeringen voordat u een nieuwe test uitvoert. Wanneer uw team klaar is om een productiemigratie uit te voeren, moet u de testuitvoeringsorganisatie handmatig verwijderen. Voordat u een tweede testuitvoeringsmigratie of de uiteindelijke productiemigratie kunt uitvoeren, moet u ervoor zorgen dat u alle eerdere Azure DevOps Services-organisaties verwijdert die u in een vorige testuitvoering hebt gemaakt. Zie Organisatie verwijderen voor meer informatie.

Tip

Optionele informatie om een gebruiker te helpen bij een succesvollere migratie van de testuitvoering, die volgt op de eerste, duurt naar verwachting langer, gezien de extra tijd die nodig is voor het opschonen van resources uit eerdere testuitvoeringen.

Het kan een uur duren voordat de naam van een organisatie beschikbaar is na het verwijderen of wijzigen van de naam. Zie het artikel Na migratietaken voor meer informatie.

Als u migratieproblemen ondervindt, raadpleegt u Migratie- en migratiefouten oplossen.

Een migratie uitvoeren

Uw team is nu klaar om te beginnen met het uitvoeren van een migratie. We raden u aan om te beginnen met een geslaagde testuitvoeringsmigratie voordat u een migratie naar een productie-uitvoering uitvoert. Met importbewerkingen voor testuitvoeringen kunt u van tevoren zien hoe een migratie eruitziet, potentiële problemen identificeert en ervaring krijgt voordat u aan de slag gaat met uw productieuitvoering.

Notitie

  • Als u een voltooide migratie van een productieuitvoering voor een verzameling wilt herhalen, zoals in het geval van een terugdraaiactie, neemt u contact op met de klantondersteuning van Azure DevOps Services voordat u een andere migratie in de wachtrij zet.
  • Azure-beheerders kunnen voorkomen dat gebruikers nieuwe Azure DevOps-organisaties maken. Als het Microsoft Entra-tenantbeleid is ingeschakeld, kan de migratie niet worden voltooid. Controleer voordat u begint of het beleid niet is ingesteld of dat er een uitzondering is voor de gebruiker die de migratie uitvoert. Zie Het maken van een organisatie beperken via microsoft Entra-tenantbeleid voor meer informatie.
  • Azure DevOps Services biedt geen ondersteuning voor bewaarbeleid per pijplijn en ze worden niet overgedragen naar de gehoste versie.

Overwegingen voor terugdraaiplannen

Een veelvoorkomende zorg voor teams die een definitieve productieuitvoering uitvoeren, is hun terugdraaiplan, als er iets misgaat met de migratie. We raden u ten zeerste aan een testuitvoering uit te voeren om ervoor te zorgen dat u de migratie-instellingen kunt testen die u opgeeft voor het Hulpprogramma voor gegevensmigratie voor Azure DevOps.

Terugdraaien voor de uiteindelijke productieuitvoering is vrij eenvoudig. Voordat u de migratie in de wachtrij plaatst, koppelt u de teamprojectverzameling los van Azure DevOps Server, waardoor deze niet beschikbaar is voor uw teamleden. Als u om welke reden dan ook de productieuitvoering terugdraait en de on-premises server weer online brengt voor uw teamleden, kunt u dit doen. Voeg de teamprojectverzameling on-premises opnieuw toe en informeer uw team dat ze normaal blijven werken, terwijl uw team opnieuw groepeert om mogelijke fouten te begrijpen.

U kunt vervolgens contact opnemen met de klantondersteuning van Azure DevOps Services voor hulp bij het begrijpen van de oorzaak van de fout als u de oorzaak niet kunt bepalen. Zie het artikel Probleemoplossing voor meer informatie. Klantenondersteuningstickets kunnen worden geopend vanaf de volgende pagina https://aka.ms/AzureDevOpsImportSupport. Het is belangrijk om te weten dat als voor het probleem productgroepstechnici nodig zijn om deze zaken in te schakelen, deze zaken tijdens normale kantooruren worden afgehandeld.

Koppel uw teamprojectverzameling los van Azure DevOps Server om deze voor te bereiden op migratie.

Voordat u een back-up van uw SQL-database genereert, moet de verzameling volledig worden losgekoppeld van Azure DevOps Server (niet SQL). Het loskoppelproces in Azure DevOps Server draagt gebruikersidentiteitsgegevens over die buiten de verzamelingsdatabase worden opgeslagen en maakt het overdraagbaar om over te stappen op een nieuwe TFS-server of in dit geval naar Azure DevOps Services.

Het loskoppelen van een verzameling wordt eenvoudig uitgevoerd vanuit de Azure DevOps Server-Beheer istration-console op uw Azure DevOps Server-exemplaar. Zie Projectverzameling verplaatsen, de verzameling loskoppelen voor meer informatie.

De migratie in de wachtrij plaatsen

Belangrijk

Voordat u verdergaat, moet u ervoor zorgen dat uw verzameling is losgekoppeld voordat u een DACPAC-bestand genereert of dat u de verzamelingsdatabase uploadt naar een SQL Azure-VM. Als u deze stap niet voltooit, mislukt de migratie. Zie Migratiefouten oplossen als de migratie mislukt.

Start een migratie met behulp van de importopdracht van het hulpprogramma voor gegevensmigratie. De migratieopdracht gebruikt een migratiespecificatiebestand als invoer. Het bestand wordt geparseerd om ervoor te zorgen dat de opgegeven waarden geldig zijn en, indien geslaagd, wordt een migratie naar Azure DevOps Services in de wachtrij geplaatst. Voor de migratieopdracht is een internetverbinding vereist, maar er is geen verbinding met uw Azure DevOps Server-exemplaar vereist.

Als u wilt beginnen, opent u een opdrachtpromptvenster en wijzigt u de mappen in het pad naar het hulpprogramma voor gegevensmigratie. We raden u aan de Help-tekst van het hulpprogramma te bekijken. Voer de volgende opdracht uit om de richtlijnen en help voor de migratieopdracht te bekijken:

Migrator migration /help

De opdracht voor het in de wachtrij plaatsen van een migratie heeft de volgende structuur:

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

In het volgende voorbeeld ziet u een voltooide migratieopdracht:

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

Nadat de validatie is geslaagd, meldt u zich aan bij Microsoft Entra-id met een identiteit die lid is van dezelfde Microsoft Entra-tenant als het logboekbestand voor identiteitstoewijzingen is gemaakt op basis van. De aangemelde gebruiker is de eigenaar van de geïmporteerde organisatie.

Notitie

Elke Microsoft Entra-tenant is beperkt tot vijf importbewerkingen per periode van 24 uur. Alleen importbewerkingen die in de wachtrij staan, tellen mee voor deze limiet.

Wanneer uw team een migratie initieert, wordt er een e-mailmelding verzonden naar de gebruiker die de migratie in de wachtrij heeft geplaatst. Ongeveer 5 tot 10 minuten nadat de migratie is in de wachtrij geplaatst, kan uw team naar de organisatie gaan om de status te controleren. Nadat de migratie is voltooid, wordt uw team omgeleid om u aan te melden en wordt er een e-mailmelding verzonden naar de eigenaar van de organisatie.

Het hulpprogramma voor gegevensmigratie markeert fouten die u vóór de migratie moet corrigeren. In dit artikel worden de meest voorkomende waarschuwingen en fouten beschreven die u mogelijk ontvangt wanneer u de migratie voorbereidt. Nadat u elke fout hebt gecorrigeerd, voert u de opdracht migratievalidatie opnieuw uit om de oplossing te controleren.

Volgende stappen

Migratiefouten oplossen