進行測試移轉

您的團隊現在已準備好開始進行移轉測試執行的流程，最終進行完整的生產環境移轉。 在此階段中，除了通常會在移轉項目結束時出現的其他工作之外，我們也會討論將移轉排入佇列的最後步驟。

必要條件

開始測試回合移轉之前，請先完成準備測試回合階段。

驗證集合

驗證您想要移轉至 Azure DevOps Services 的每個集合。 驗證步驟會檢查集合的各個層面，包括但不限於大小、定序、身分識別和程式。

使用資料遷移工具執行驗證。

1. 下載數據遷移工具。

2. 將 zip 檔案複製到其中一個 Azure DevOps Server 應用層。

3. 將 檔案解壓縮。 您也可以從未安裝 Azure DevOps Server 的不同機器執行此工具，只要機器可以連線到 Azure DevOps Server 實例的組態資料庫即可。

4. 開啟伺服器上的 [命令提示字元] 視窗，然後輸入 cd 命令，以變更為儲存資料遷移工具的目錄。 請花點時間檢閱工具的說明內容。

   a. 若要檢視最上層的說明和指引，請執行下列命令。

    Migrator /help
   

   b. 檢視命令的幫助文字。

    Migrator validate /help 
   

5. 當您第一次驗證集合時，您的命令應該具有下列簡單結構。

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

   {name} 提供您的 Microsoft Entra 租戶名稱，例如，要針對 DefaultCollection 和 fabrikam 租戶執行，命令看起來會像下列範例一樣。

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

6. 若要從 Azure DevOps Server 以外的電腦執行此工具，您需要 /connectionString 參數。 連接字串 參數會指向您的 Azure DevOps Server 組態資料庫。 例如，如果 Fabrikam 公司執行已驗證的命令，此命令看起來會像這樣。

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

   重要

   數據遷移工具 不會 編輯集合中的任何數據或結構。 它只會讀取集合來識別問題。

7. 驗證完成後，您可以檢視記錄檔和結果。

   

   在驗證過程中，如果某些管線具有特定的保留規則，您會收到警告。 Azure DevOps Services 會使用 以專案為基礎的保留模型，而不支援針對每個 pipeline 的保留原則。 如果您繼續進行移轉，則政策不會延續至託管版本。 相反地，會套用預設專案層級保留原則。 保留重要的構建，避免遺失。

所有驗證通過之後，您就可以移至 移轉程式的下一個步驟。 如果數據遷移工具標記任何錯誤，請先更正錯誤，再繼續進行。 如需修正驗證錯誤的指引，請參閱 針對移轉和移轉錯誤進行疑難排解。

匯入記錄檔

當您開啟記錄檔目錄時，您可能會注意到數個記錄檔。

主要記錄檔名為 DataMigrationTool.log。 其中包含已執行之所有專案的詳細數據。 為了讓您可以更輕鬆地專注於特定區域，系統會為每個主要驗證作業產生記錄。

例如，如果 TfsMigrator 在「驗證項目進程」步驟中報告錯誤，您可以開啟 ProjectProcessMap.log 檔案，以檢視針對該步驟執行的所有專案，而不需要捲動整個記錄檔。

只有在您嘗試移轉項目程式以使用繼承的模型時，才檢閱TryMatchOobProcesses.log檔案。 如果您不想使用繼承的模型，您可以忽略這些錯誤，因為它們不會阻止您匯入 Azure DevOps Services。 如需詳細資訊，請參閱 驗證移轉階段。

產生移轉檔案

數據遷移工具已驗證集合，並傳回「所有已傳遞的集合驗證」的結果。將集合脫機移轉之前，請先產生移轉檔案。 當您執行 命令時 prepare ，會產生兩個移轉檔案：

• IdentityMapLog.csv：概述 Active Directory 與 Microsoft Entra ID 之間的身分識別對應。
• migration.json：要求您填寫您想要用來開始移轉的移轉規格。

準備指令

命令 prepare 可協助產生必要的移轉檔案。 基本上，此命令會掃描集合，尋找所有使用者的清單，以填入身分對應記錄檔 IdentityMapLog.csv，然後嘗試連線到 Microsoft Entra ID 以尋找每個身分的相符項目。 若要這樣做，您的公司必須使用 Microsoft Entra Connect 工具（先前稱為目錄同步處理工具 、目錄同步工具或DirSync.exe工具）。

如果設定目錄同步處理，數據遷移工具應該會尋找相符的身分識別，並將其標示為 作用中。 如果沒有相符項目，身分識別會在身分識別對應記錄中標示為 歷史，因此您必須調查用戶為何未包含在目錄同步處理中。在遷移之前，遷移規格檔案 migration.json 應該填入。

與validate命令不同，prepare需要網際網路連線，因為它必須連線到 Microsoft Entra ID 以填寫身分識別對應記錄檔。 如果您的 Azure DevOps Server 實例沒有網際網路存取，請在具備網際網路存取的電腦上執行此工具。 只要您可以找到一台連接至 Azure DevOps Server 實例的內部網路和因特網的電腦，便可以執行此命令。 如需 prepare 命令的說明，請執行下列命令：

Migrator prepare /help

說明文件中包含用於從 Azure DevOps Server 實例本機及遠端電腦執行 Migrator 命令的指示和範例。 如果您是從其中一個 Azure DevOps Server 實例應用層執行命令，您的命令應該具有下列結構：

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"

connectionString 參數是 Azure DevOps Server 實例組態資料庫的指標。 例如，如果 Fabrikam 公司執行 prepare 命令，此命令看起來會像下列範例：

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

當資料遷移工具執行 prepare 命令時，它會執行完整的驗證，以確保自上次完整驗證之後，您的集合沒有任何變更。 如果偵測到任何新問題，則不會產生任何移轉檔案。

命令開始執行之後不久，就會顯示Microsoft Entra 登入視窗。 使用屬於租使用者網域的身分識別登入，該身分識別是在 命令中指定的。 請確定指定的 Microsoft Entra 租戶是您希望未來組織依托的租戶。 在我們的 Fabrikam 範例中，使用者輸入類似下列範例螢幕快照的認證。

當您在資料遷移工具中成功執行 prepare 命令時，結果視窗會顯示一組記錄和兩個移轉檔案。 在記錄目錄中，尋找logs資料夾和兩個檔案：

• migration.json是移轉規格檔案。 建議您花點時間填寫。
• IdentityMapLog.csv 包含 Active Directory 與 Microsoft Entra 身分識別的對應關係。 開始移轉之前，請先檢閱其完整性。

下一節會更詳細地說明這兩個檔案。

移轉規格檔案

移轉規格 migration.json是提供移轉設定的 JSON 檔案。 其中包含所需的組織名稱、記憶體帳戶資訊和其他資訊。 大部分欄位都會自動填入，有些字位需要輸入才能嘗試移轉。

下表說明migration.json檔案的顯示欄位和必要動作：

完成上述程序之後，您應該會有類似下列範例的檔案。

在上圖中，Fabrikam 遷移規劃工具新增了組織名稱 fabrikam-import，並選取了美國中部 (CUS) 作為遷移的地理位置。 其他值則保留不變，待規劃者在將集合下線進行遷移前修改。

支援的 Azure 區域以進行移轉

Azure DevOps Services 可在數個 Azure 地理位置中使用。 但是，並非所有可用的 Azure DevOps Services 位置都支援移轉。 下表列出您可以選取以進行移轉的 Azure 地理位置。 還包含了您需要在移轉規格檔案中填入的值，以針對該地理位置進行移轉。

身分映射日誌

身分識別映射記錄與您移轉至 Azure DevOps Services 的實際資料同等重要。 當您檢閱檔案時，請務必瞭解身分識別移轉的運作方式，以及可能的結果。 當您移轉身分識別時，它可能會變成 作用中 或 歷程記錄。 作用中身分識別可以登入 Azure DevOps Services，但歷史身分識別無法登入。

啟用的身分識別

在 Azure DevOps Services 中，作用中身分識別是指移轉後的使用者身分識別。 在 Azure DevOps Services 中，這些身分識別已獲得授權，並顯示為組織內的使用者。 身分識別在身分識別對應記錄檔的預期匯入狀態欄位中標示為啟用。

歷史身份

歷史身分識別會被映射， 如在識別對應記錄檔的預期匯入狀態欄中。 檔案中沒有行記錄的身分識別也會變成歷史紀錄。 沒有行輸入的身分識別範例可能是不再在公司工作的員工。

不同於活躍身分識別，歷史身分識別：

• 移轉后無法 存取組織。
• 沒有 執照。
• 不要 在組織中顯示為使用者。 組織內部持續存在的是有關該身分識別名稱的觀念，以便日後可以搜尋其歷史記錄。 我們建議您針對不再在公司工作或不需要進一步存取組織的使用者，使用歷程記錄身分識別。

瞭解身份識別對應記錄檔

身分識別對應記錄檔的格式類似於此處展示的範例：

身份識別映射記錄檔之欄位如下表所示：

您和您的 Microsoft Entra 系統管理員必須調查標示為 「找不到相符專案（請檢查 Microsoft Entra ID 同步）」 的使用者，以了解他們為什麼不在您的 Microsoft Entra Connect 同步中。

當您閱讀檔案時，請注意預期匯入狀態列中的值是作用中還是歷史記錄。 啟用 表示此列的身份識別在遷移時正確映射後會啟用。 歷史 表示身份在遷移時會變成歷史。 務必檢閱生成的對應檔案，以確保完整性和正確性。

1. 查看正確匹配的身份信息。 所有預期的身份都存在嗎？ 使用者是否對應至正確的 Microsoft Entra 帳戶？

   如果需要更新任何值，請連絡您的Microsoft Entra 系統管理員，以確保內部部署 Active Directory 身分識別會與Microsoft Entra 識別符同步，並正確設定。 如需詳細資訊，請參閱 整合內部部署身分識別與Microsoft Entra ID。

2. 接下來，檢閱標示為 歷史 的身分識別。 此標籤表示找不到相符Microsoft Entra 身分識別，原因如下：

   • 尚未設定身分識別以進行內部部署 Active Directory 與 Microsoft Entra 識別碼之間的同步。
   • 身分帳戶尚未加入您的 Microsoft Entra 目錄中（例如，有新員工）。
   • 身分識別不存在於您的 Microsoft Entra 實例中。
   • 擁有該身分識別的使用者不再在公司工作。

若要解決前三個原因，請設定預期的 內部部署的 Active Directory 身分識別，以與Microsoft Entra 標識符同步。 如需詳細資訊，請參閱 整合內部部署身分識別與Microsoft Entra ID。 您必須設定並執行 Microsoft Entra Connect，才能將身分識別匯入為 Azure DevOps Services 中的啟用狀態。

您可以忽略第四個原因，因為離職的員工應該匯入為 歷史紀錄。

歷史身份認同（小型團隊）

如果未設定 Microsoft Entra Connect，則身分識別對應記錄檔中的所有用戶都會標示為 歷史。 以這種方式執行移轉會導致所有用戶匯入為歷史用戶。 強烈建議您設定 Microsoft Entra Connect ，以確保您的使用者已匯入為 使用中狀態。

執行具有所有歷史身份的移轉會產生需要仔細考慮的影響。 只有在少數使用者的小組，且當設定 Microsoft Entra Connect 的成本被認為過高時，才應該考慮。

若要將所有身分識別移轉為歷程記錄，請遵循後續各節中所列的步驟。 當您將移轉排入佇列時，用來將移轉排入佇列的身分識別會以組織擁有者身分進入組織。 所有其他用戶都會匯入為歷程記錄。 然後組織擁有者可以使用他們的Microsoft Entra身分識別，將使用者重新新增進去。 新增的使用者會被視為新使用者。 他們不擁有任何歷史紀錄，也無法將這些歷史重新關聯到 Microsoft Entra 身份。 不過，使用者仍可藉由搜尋\<domain>\<Active Directory username>來查閱\<domain>\<Active Directory username>的移轉前歷程。

如果數據遷移工具偵測到完整的歷程記錄身分識別案例，就會顯示警告。 如果您決定前往此移轉路徑，則必須在工具中同意限制。

Visual Studio 訂閱

數據遷移工具在生成身分映射日誌文件時，偵測不到 Visual Studio 訂閱（先前稱為 MSDN 權益）。 相反地，建議您在移轉之後套用自動授權升級功能。 只要使用者的工作帳戶 正確連結 ，Azure DevOps Services 就會在移轉後的第一次登入時自動套用其Visual Studio 訂用帳戶權益。 在移轉期間指派的授權不會收取任何費用，因此您可以在移轉後安全地處理訂用帳戶。

如果使用者的Visual Studio訂用帳戶未在 Azure DevOps Services 中自動升級，就不需要重複測試回合移轉。 Visual Studio 訂用帳戶連結會在移轉範圍之外發生。 只要在移轉前後正確連結其工作帳戶，用戶授權就會在其下一次登入時自動升級。 成功升級其授權之後，下次執行移轉時，使用者就會在其第一次登入組織時自動升級。

為移轉做準備

現在您已準備好進行測試遷移的所有操作。 與團隊協商安排停機時間，以便進行集合的遷移工作。 當您同意執行移轉的時間時，請將您產生的必要資產和資料庫的複本上傳至 Azure。 準備移轉包含下列五個步驟。

步驟 1： 讓集合離線並中斷連結。 步驟 2： 從您要移轉的集合產生 DACPAC 檔案。
步驟 3： 將 DACPAC 檔案和移轉檔案上傳至 Azure 記憶體帳戶。
步驟 4： 產生 SAS 令牌以存取記憶體帳戶。
步驟 5： 完成移轉規格。

步驟 1：中斷連結您的集合

中斷連結集合 是移轉程式中的重要步驟。 集合的身分識別數據位於 Azure DevOps Server 實例的組態資料庫中，而集合則附加並上線。 當集合與 Azure DevOps Server 實例中斷連結時，它會擷取該身分識別數據的複本，並將它與集合封裝以用於傳輸。 如果沒有此數據，就無法執行移轉的身分識別部分。

務必慎重考量為測試過程達到零停機時間而付出的成本。 它要求備份集合和組態資料庫，然後在 SQL 實例上還原它們，最後創建一個獨立的備份。 成本分析可能證明，只需要幾個小時的停機時間來直接執行分離備份，最終會更加有利。

步驟 2：產生 DACPAC 檔案

DACPAC 提供快速且相對容易的方法，可將集合移至 Azure DevOps Services。 不過，在集合資料庫大小超過特定閾值之後，使用 DACPAC 的優點會開始減少。

DACPAC 是 SQL Server 的功能，可讓資料庫封裝成單一檔案，並部署到 SQL Server 的其他實例。 DACPAC 檔案也可以直接還原至 Azure DevOps Services，因此您可以使用它作為封裝方法，以在雲端中取得集合的數據。

使用 SqlPackage 版本資訊的最新 MSI 安裝程式下載並安裝SqlPackage.exe。

使用 MSI 安裝程式之後，SqlPackage.exe安裝路徑類似 %PROGRAMFILES%\Microsoft SQL Server\160\DAC\bin\。

當您產生 DACPAC 時，請記住兩個考慮：DACPAC 儲存的磁碟，以及產生 DACPAC 之電腦上的磁碟空間。 您要確保有足夠的磁碟空間來完成作業。

建立封裝時，SqlPackage.exe暫時將集合中的數據儲存在您起始封裝要求的機器 C 磁碟驅動器 C 上的暫存目錄中。

您可能會發現磁碟驅動器 C 太小，無法支援建立 DACPAC。 您可以藉由尋找集合資料庫中的最大數據表來估計所需的空間量。 DACPAC 會一次建立一個數據表。 執行產生的最大空間需求大致相當於集合資料庫中最大數據表的大小。 如果您將產生的 DACPAC 儲存在磁碟驅動器 C，請考慮從驗證執行 DataMigrationTool.log 檔案中報告的集合資料庫大小。

DataMigrationTool.log檔案會在每次執行命令時，提供集合中最大的數據表清單。 如需集合的數據表大小範例，請參閱下列輸出。 比較最大數據表的大小與裝載暫存目錄之磁碟驅動器上的可用空間。

[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

請確定裝載您暫存目錄的磁碟驅動器至少有一樣多的可用空間。 如果沒有，您必須藉由設定環境變數來重新導向暫存目錄。

SET TEMP={location on disk}

另一個考慮是儲存 DACPAC 資料的位置。 將儲存位置指向遙遠的遠端硬碟可能會導致生成時間更長。 如果在本機提供固態硬碟 （SSD） 等快速磁碟驅動器，建議您將磁碟驅動器作為 DACPAC 儲存位置的目標。 否則，使用存放集合資料庫的計算機上的磁碟會比使用遠端磁碟驅動器更快。

既然您已識別 DACPAC 的目標位置，並確定您有足夠的空間，就可以產生 DACPAC 檔案。

開啟 [命令提示字元] 視窗，並移至SqlPackage.exe位置。 若要產生 DACPAC，請將佔位元值取代為必要值，然後執行下列命令：

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

• 數據源：裝載 Azure DevOps Server 集合資料庫的 SQL Server 實例。
• 初始目錄：集合資料庫的名稱。
• targetFile：磁碟上的位置和 DACPAC 檔名。

在 Azure DevOps Server 數據層本身上執行的 DACPAC 產生命令，如下列範例所示：

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

命令的輸出是從名為 Foo.dacpac 的集合資料庫 Foo 產生的 DACPAC 檔案。

設定您的集合以進行移轉

在 Azure VM 上還原收集資料庫之後，請設定 SQL 登入以允許 Azure DevOps Services 連線到資料庫以移轉數據。 此登入只允許單一資料庫的讀取權限。

若要啟動，請在 VM 上開啟 SQL Server Management Studio，然後針對要匯入的資料庫開啟新的查詢視窗。

將資料庫的復原設定為簡單：

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

建立 SQL 資料庫的登入帳戶，並將該帳戶指派為「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>'

在 Fabrikam 範例之後，這兩個 SQL 命令看起來會像下列範例：

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'

將移轉規格檔案設定為以 VM 為目標

更新移轉規格檔案，以包含如何連線到 SQL Server 實例的相關信息。 開啟您的移轉規格檔案，並進行下列更新。

1. 從來源檔案物件中移除 DACPAC 參數。

   變更前的移轉規格會顯示在下列程式代碼中。

   

   變更之後的移轉規格會顯示在下列程式代碼中。

   

2. 填寫必要的參數，並在規格檔案中的來源物件中新增下列屬性物件。

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

套用變更之後，移轉規格看起來像下列範例。

您的移轉規格現在已設定為使用 SQL Azure VM 進行移轉。 繼續進行移轉至 Azure DevOps Services 的其餘準備步驟。 移轉完成後，請務必刪除 SQL 登入或輪替密碼。 Microsoft移轉完成後不會保留登入資訊。

步驟 3：上傳 DACPAC 檔案

DACPAC 必須放在 Azure 記憶體容器中，它可以是現有的容器，或專為移轉工作建立的容器。 請務必確定您的容器是在正確的地理位置中建立的。

Azure DevOps Services 可在多個 地理位置使用。 當您匯入這些位置時，請務必正確放置您的數據，以確保移轉可以順利啟動。 您的數據必須放在您要匯入的相同地理位置。 將數據放在其他地方會導致移轉無法啟動。 下表列出建立記憶體帳戶及上傳數據可接受的地理位置。

雖然 Azure DevOps Services 在美國的多個地理位置提供服務，但只有美國中部位置接受新的 Azure DevOps Services。 目前您無法將數據遷移至其他美國 Azure 位置。

從 Azure 入口網站 建立 Blob 容器。 建立容器之後，請上傳集合 DACPAC 檔案。

移轉完成後，請使用 AzCopy 或任何其他 Azure 儲存體瀏覽器工具刪除 Blob 容器和其相關的儲存體帳戶。

步驟 4：產生 SAS 令牌

共用存取簽章 （SAS） 令牌提供對記憶體帳戶中資源的委派存取權。 令牌可以讓您將最低層級的權限提供給 Microsoft，以存取您的數據以執行移轉。

您可以使用 Azure 入口網站 產生 SAS 令牌。 從安全性觀點來看，我們建議執行下列工作：

1. 只選取 讀取 和 列出 作為 SAS 令牌的許可權。 不需要任何其他權限。
2. 設定到期時間在未來七天內。
3. 僅限制對 Azure DevOps Services IP 的存取。
4. 將 SAS 金鑰視為秘密。 請勿將密鑰放置在不安全的位置，因為它會賦予任何人存取容器中數據的讀取和列表權限。

步驟 5：完成移轉規格

稍早在過程中，您部分填寫了稱為 migration.json 的移轉規格檔案。 此時，您有足夠的資訊可以完成除了移轉類型以外的其他所有欄位。 稍後會在移轉區段中討論移轉類型。

在migration.json規範文件中，來源下的，完成下列欄位。

• 位置：貼上您從腳本產生的 SAS 金鑰，然後在上一個步驟中複製。
• Dacpac：請確定檔案，包括 .dacpac 擴展名，與您上傳至記憶體帳戶的 DACPAC 檔案同名。

最終的移轉規格檔案看起來應該像下列範例。

判斷移轉類型

匯入可以排入隊列為測試運行（DryRun），或生產運行（ProductionRun）。 ImportType 參數會決定移轉類型：

• DryRun：也稱為測試回合。 用於測試和驗證用途。 系統會在 45 天后刪除測試回合。
• ProductionRun：當您想要保留移轉結果，並在移轉完成後全時使用 Azure DevOps Services 中的組織時，請使用生產模式執行。

測試執行組織

測試運行組織可協助團隊測試其資料集的遷移。 執行生產環境移轉之前，必須先刪除任何已完成的測試回合組織。 所有測試回合組織都有 有限的存在，而且會在一段時間后自動刪除。 完成遷移後，您應會收到一封成功的電子郵件，其中包括有關何時刪除組織的信息。 請務必記下此日期並據以規劃。

測試運行組織將在45天後被刪除。 在指定的時間期限之後，會刪除測試執行組織。 在執行生產環境遷移之前，您可以根據需要多次重複進行測試匯入。

刪除測試回合

在您嘗試新的測試之前，請先刪除任何先前的測試回合。 當團隊準備好執行遷移至生產環境時，您必須手動刪除測試運行的組織。 在您執行第二次測試回合移轉或最終生產移轉之前，請確定您刪除您在先前測試回合中建立的任何先前 Azure DevOps Services 組織。 如需詳細資訊，請參閱 刪除組織。

刪除或重新命名之後，最多可能需要一小時的時間，組織名稱才會可供使用。 如需詳細資訊，請參閱 移轉後工作 一文。

如果您遇到任何移轉問題，請查看 移轉和移轉錯誤的疑難解答。

執行移轉

您的小組現在已準備好開始執行移轉的程式。 建議您在進行生產環境的移轉之前，先進行一次成功的測試遷移。 透過測試回合匯入，您可以事先查看移轉的外觀、找出潛在問題，以及在進入生產執行之前取得經驗。

• Azure 系統管理員可以防止使用者建立新的 Azure DevOps 組織。 如果開啟 Microsoft Entra 租用戶策略，您的移轉將無法完成。 開始之前，先確認政策是否未設定，或是執行遷移的使用者是否有例外。 如需詳細資訊，請參閱 透過 Microsoft Entra 租用戶原則限制組織的建立。
• Azure DevOps Services 不支援單一管線保留政策，而且這些政策不會延續到裝載的版本。

回退計劃的考量

對於執行最終生產階段的小組來說，常見的問題在於其復原計劃，如果遷移發生任何問題。 強烈建議執行測試，以確保您可以測試提供給 Azure DevOps 的數據遷移工具的移轉設定。

對於最後生產階段的回退相當簡單。 在將移轉排入佇列之前，請先從 Azure DevOps Server 中中斷小組專案集合的連結，這將使其暫時無法供小組成員使用。 如果您需要因任何原因復原生產執行，並讓內部部署伺服器重新運作以供小組成員使用，您可以這麼做。 再次附加團隊專案集合，並通知您的小組，他們將繼續正常工作，而您的團隊將重新組織以了解任何潛在的故障。

然後，如果無法判斷原因，您可以連絡 Azure DevOps Services 客戶支援以取得了解失敗原因的說明。 如需詳細資訊，請參閱 疑難解答一文。 您可以在下列頁面 https://aka.ms/AzureDevOpsImportSupport開啟客服支援請求。 如果問題需要產品群組工程師參與，這些案例會在一般上班時間處理。

將小組專案集合從 Azure DevOps Server 中斷連結，以準備移轉。

在為您的 SQL 資料庫建立備份之前，您必須使用資料遷移工具，從 Azure DevOps Server （並非從 SQL）完全卸載集合。 Azure DevOps Server 中的卸離程式會將儲存在集合資料庫外部的使用者身分識別資訊，使其可移植到新的伺服器，或在此案例中移至 Azure DevOps Services。

在您的 Azure DevOps Server 實例中，可以透過 Azure DevOps Server 管理控制台輕鬆卸載集合。 如需詳細資訊，請參閱 移動專案集合、分離集合。

將移轉排入佇列

使用資料遷移工具的 匯 入命令啟動移轉。 匯入命令會採用移轉規格檔案作為輸入。 它會解析檔案，以確保所提供的值是否有效。如果有效，則會將遷移佇列至 Azure DevOps Services。 匯入命令需要因特網連線，但不需要連線到您的 Azure DevOps Server 實例。

若要開始使用，請開啟 [命令提示字元] 視窗，並將目錄變更為數據遷移工具的路徑。 建議您檢閱工具所提供的說明文字。 執行下列命令以查看匯入命令的指引和說明：

Migrator import /help

將遷移排入佇列的命令具有下列結構：

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

下列範例顯示已完成的匯入命令：

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

驗證通過之後，請使用與身分識別對應記錄檔建立時屬於相同 Microsoft Entra 租用戶的身分識別登入 Microsoft Entra ID。 登入的用戶是匯入組織的擁有者。

當小組起始移轉時，會將電子郵件通知傳送給排入移轉佇列的使用者。 在將遷移排入佇列後大約 5 到 10 分鐘，您的小組可以到組織查看狀態。 移轉完成後，您的小組會導向登入，並將電子郵件通知傳送給組織擁有者。

數據遷移工具會標幟移轉之前必須更正的錯誤。 本文說明您在準備移轉時可能收到的最常見警告和錯誤。 更正每個錯誤之後，請再次執行 migrator validate 命令以確認解決問題。

下一步

相關內容

• 移轉概觀
• 移轉後工作