执行测试运行迁移

你的团队现在准备开始执行迁移测试运行，最后进行完整的生产迁移。 在此阶段，我们将讨论排队迁移的最终步骤以及迁移项目结束时通常出现的其他任务。

先决条件

在开始测试运行迁移之前，完成准备测试运行阶段。

验证集合

验证要迁移到 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 使用基于项目的保留模型，不支持每个管道的保留策略。 如果继续迁移，这些策略不会转移到托管版本。 而是应用默认的项目级保留策略。 保留对你重要的生成以避免丢失。

所有验证通过后，你可以移至迁移过程的下一步。 如果数据迁移工具标记任何错误，请在继续之前纠正这些错误。 有关纠正验证错误的指南，请参阅排查迁移和迁移错误。

导入日志文件

打开日志目录时，你可能会注意到多个日志文件。

main日志文件名为 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 工具（以前称为目录同步工具、Directory Sync 工具或 DirSync.exe 工具）。

如果已设置目录同步，数据迁移工具应会找到匹配的标识并将其标记为活动。 如果没有匹配项，该标识在标识映射日志中会被标记为“历史”，因此你必须调查该用户未包含在目录同步中的原因。迁移规范文件 migration.json 应在迁移前填写完整。

与 validate 命令不同，prepare确实需要互联网连接，因为它需要连接到 Microsoft Entra ID 以填充标识映射日志文件。 如果你的 Azure DevOps Server 实例没有互联网访问权限，请从有互联网访问权限的计算机运行此工具。 只要可以找到与Azure DevOps Server实例建立 Intranet 连接和 Internet 连接的计算机，就可以运行此命令。 有关 命令的 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 ID 同步并正确配置。 有关详细信息，请参阅将本地标识与 Microsoft Entra ID 集成。

2. 接下来，查看标记为 “历史”的标识。 此标记表示找不到匹配的 Microsoft Entra 标识，原因如下：

   • 该标识未设置为在本地 Active Directory 与 Microsoft Entra ID 之间同步。
   • 该标识尚未填充到你的 Microsoft Entra ID 中（例如，有新员工）。
   • 该标识在你的 Microsoft Entra 实例中不存在。
   • 拥有该标识的用户不再在公司工作。

要解决前三个原因，请设置预期的本地 Active Directory 标识以与 Microsoft Entra ID 同步。 有关详细信息，请参阅将本地标识与 Microsoft Entra ID 集成。 要将标识作为活动标识导入到 Azure DevOps Services，你必须设置并运行 Microsoft Entra Connect。

可以忽略第四个原因，因为不再在公司的员工应作为 历史人员导入。

小型团队 (历史标识)

如果未配置 Microsoft Entra Connect，标识映射日志文件中的所有用户都会被标记为历史用户。 以这种方式运行迁移会导致所有用户都作为历史用户导入。 我们强烈建议你配置 Microsoft Entra Connect，以确保你的用户作为活动用户导入。

使用所有历史标识运行迁移会产生需要仔细考虑的后果。 只有用户数量较少且认为设置 Microsoft Entra Connect 的成本过高的团队才应考虑。

要将所有标识作为历史标识迁移，请按照后面部分概述的步骤操作。 当你排队迁移时，用于排队迁移的标识会作为组织所有者自动加入该组织。 所有其他用户作为历史用户导入。 然后，组织所有者可以使用用户的 Microsoft Entra 标识将其重新添加进来。 添加的用户被视为新用户。 他们没有拥有他们的任何历史，也无法将此历史重新关联到Microsoft Entra 身份。 不过，用户仍可以通过搜索其 \<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 太小，无法支持创建 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

该命令的输出是一个 DACPAC 文件，从名为 Foo 的集合数据库生成，称为 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 ID 租户策略限制组织创建。
• 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。 导入命令需要 Internet 连接，但不* 要求连接到 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 分钟，你的团队可以前往组织查看状态。 迁移完成后，你的团队会被引导登录，并且会向组织所有者发送电子邮件通知。

数据迁移工具会标记迁移前需要纠正的错误。 本文介绍准备迁移时可能收到的最常见警告和错误。 纠正每个错误后，再次运行迁移器验证命令以确认已解决。

后续步骤

相关内容

• 迁移概述
• 迁移后的任务