执行测试运行迁移
你的团队现在已准备好开始开始迁移测试运行，最后开始完整的生产迁移。 在此阶段，我们讨论了将迁移排入队列的最后步骤，以及通常在迁移项目结束时出现的其他任务。
先决条件
验证集合
验证要迁移到 Azure DevOps Services 的每个集合。 验证步骤检查集合的各个方面，包括但不限于大小、排序规则、标识和流程。
使用数据迁移工具运行验证。
将 zip 文件复制到 Azure DevOps Server 应用程序层之一。
解压缩文件。 也可以从未安装 Azure DevOps Server 的其他计算机运行该工具，前提是该计算机可以连接到 Azure DevOps Server 实例的配置数据库。
打开服务器上的命令提示符窗口，并输入 cd 命令以更改为存储数据迁移工具的目录。 花点时间查看该工具的帮助内容。
a. 若要查看顶级帮助和指南，请运行以下命令。
Migrator /helpb. 查看命令的帮助文本。
Migrator validate /help首次验证集合时，命令应具有以下简单结构。
Migrator validate /collection:{collection URL} /tenantDomainName:{name} /region:{region}例如，如果
{name}为针对 DefaultCollection 和 fabrikam 租户运行 Microsoft Entra 租户的名称，该命令将如以下示例所示。Migrator validate /collection:http://localhost:8080/DefaultCollection /tenantDomainName:fabrikam.OnMicrosoft.com /region:{region}若要从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"重要
数据迁移工具 不会 编辑集合中的任何数据或结构。 它仅读取集合以识别问题。
验证完成后，可以查看日志文件和结果。
在验证期间，如果某些管道包含每管道保留规则，则会收到警告。 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 命令
该 prepare 命令有助于生成所需的迁移文件。 从本质上讲，此命令会扫描集合以查找所有用户的列表，以填充标识映射日志，IdentityMapLog.csv，然后尝试连接到 Microsoft Entra ID 以查找每个标识的匹配项。 为此，公司需要使用 Microsoft Entra 连接 工具（以前称为目录同步工具、目录同步工具或DirSync.exe工具）。
如果设置了目录同步，数据迁移工具应找到匹配的标识并将其标记为“活动”。 如果没有匹配项，则标识在标识映射日志中标记为 “历史记录 ”，因此必须调查用户未包含在目录同步中的原因。迁移规范文件 （migration.json）应在迁移之前填充。
validate与命令不同，prepare需要 Internet 连接，因为它需要连接到 Microsoft Entra ID 来填充标识映射日志文件。 如果 Azure DevOps Server 实例没有 Internet 访问权限，请从执行该操作的计算机运行该工具。 只要可以找到与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 示例中，用户输入类似于以下示例屏幕截图的凭据。
重要
不要对测试迁移使用测试 Microsoft Entra 租户，不要将生产运行的 Microsoft Entra 租户用于生产。 在使用组织的生产 Microsoft Entra 租户开始生产运行时，使用测试 Microsoft Entra 租户可能会导致标识迁移问题。
在数据迁移工具中成功运行 prepare 命令时，结果窗口会显示一组日志和两个迁移文件。 在日志目录中，找到一个日志文件夹和两个文件：
- migration.json 是迁移规范文件。 我们建议你花点时间填写它。
- IdentityMapLog.csv 包含 Active Directory 到 Microsoft Entra 标识的生成映射。 在开始迁移之前，请查看其完整性。
后续部分将更详细地介绍这两个文件。
迁移规范文件
迁移规范 migration.json是一个提供迁移设置的 JSON 文件。 它包括所需的组织名称、存储帐户信息和其他信息。 大多数字段都是自动填充的，某些字段在尝试迁移之前需要输入。
下表介绍了migration.json文件的显示字段和所需操作：
| 字段 | 说明 | 必需的操作 |
|---|---|---|
| Source | 有关用于迁移的源数据文件的位置和名称的信息。 | 无需采取措施。 查看要遵循的子字段操作的信息。 |
| 位置 | 托管数据层应用程序包的 Azure 存储帐户的共享访问签名密钥 (DACPAC) 。 | 无需采取措施。 此字段将在后面的步骤中介绍。 |
| 文件 | 包含迁移数据的文件的名称。 | 无需采取措施。 查看要遵循的子字段操作的信息。 |
| DACPAC | 一个 DACPAC 文件，该文件打包用于在迁移过程中引入数据的集合数据库。 | 无需采取措施。 在后面的步骤中，使用集合创建此文件，然后将其上传到 Azure 存储帐户。 根据你在此过程稍后生成时使用的名称更新文件。 |
| 目标 | 要迁移到的新组织的属性。 | 无需采取措施。 查看要遵循的子字段操作的信息。 |
| 名称 | 在迁移过程中要创建的组织的名称。 | 提供一个名称。 迁移完成后，可以快速更改名称。 注意： 在运行迁移之前， 请勿创建具有此名称的组织。 组织在迁移过程中创建。 |
| ImportType | 要运行的迁移类型。 | 无需采取措施。 在后面的步骤中，选择要运行的迁移类型。 |
| 验证数据 | 帮助推动迁移体验所需的信息。 | 数据迁移工具生成“ValidationData”部分。 它包含有助于推动迁移体验的信息。 请勿* 编辑本部分中的值，否则迁移可能无法启动。 |
完成上述过程后，应有一个如下所示的文件。
在上图中，Fabrikam 迁移的规划器将组织名称 fabrikam-import 和所选 CUS（中央美国）添加为迁移的地理位置。 在规划器使集合脱机进行迁移之前，其他值已保留原样进行修改。
注意
测试运行导入自动追加到组织名称末尾的“-dryrun”，可在迁移后更改。
支持的 Azure 区域进行迁移
Azure DevOps Services 在多个 Azure 地理位置中可用。 但是，不支持迁移支持 Azure DevOps Services 的所有位置。 下表列出了可以选择进行迁移的 Azure 地理位置。 此外，还包括需要在迁移规范文件中放置的值，以针对该地理位置进行迁移。
| 地理位置 | Azure 地理位置 | 导入规范值 |
|---|---|---|
| 美国 | 中央美国 | CUS |
| 欧洲 | 欧洲西部 | WEU |
| 英国 | 英国南部 | UKS |
| 澳大利亚 | 澳大利亚东部 | EAU |
| 南美洲 | Brazil South | Sbr |
| 亚太区 | 印度南部 | MA |
| 亚太区 | 东南亚（新加坡） | SEA |
| 加拿大 | 加拿大中部 | CC |
标识映射日志
标识映射日志对迁移到 Azure DevOps Services 的实际数据同样重要。 查看文件时，请务必了解标识迁移的工作原理以及潜在结果可能带来什么。 迁移标识时，它可以变为 活动 标识或 历史标识。 活动标识可以登录到 Azure DevOps Services，但历史标识无法登录。
活动标识
活动标识是指迁移后 Azure DevOps Services 中的用户标识。 在 Azure DevOps Services 中，这些标识已获得许可，并显示为组织中的用户。 标识映射日志文件的“预期导入状态”列中将标识标记为活动。
历史标识
在标识映射日志文件的 “预期导入状态” 列中映射历史标识。 文件中没有行条目的标识也将成为历史标识。 没有行条目的标识示例可能是不再在公司工作的员工。
与活动标识不同，历史标识：
- 迁移后无权访问组织。
- 没有 许可证。
- 不要 显示为组织中的用户。 保留的只是该标识在组织中的名称的概念，以便以后可以搜索其历史记录。 建议对不再在公司工作或不需要进一步访问组织的用户使用历史标识。
注意
将标识导入为历史标识后，它 将无法 变为活动状态。
了解标识映射日志文件
标识映射日志文件类似于此处所示的示例：
下表描述了标识映射日志文件中的列：
你和你的 Microsoft Entra 管理员必须调查标记为“找不到匹配”的用户（检查 Microsoft Entra ID 同步），以了解他们为何不是 Microsoft Entra 连接 同步的一部分。
| 列 | 说明 |
|---|---|
| Active Directory：用户 (Azure DevOps Server) | 标识在 Azure DevOps Server 中使用的友好显示名称。 通过此名称，可以更轻松地识别地图中线条所引用的用户。 |
| Active Directory：安全标识符 | Azure DevOps Server 中本地 Active Directory标识的唯一标识符。 此列用于标识集合中的用户。 |
| Microsoft Entra ID：预期导入用户（Azure DevOps Services） | 匹配即将激活的用户的预期登录地址或 “未找到匹配项”（检查 Microsoft Entra ID Sync），指示标识在 Microsoft Entra ID Sync 期间丢失，并作为历史导入。 |
| 预期导入状态 | 预期的用户迁移状态：Active Directory 和 Microsoft Entra ID 之间存在匹配项;如果没有匹配项，则为“历史记录”。 |
| 验证日期 | 上次验证标识映射日志的时间。 |
通读文件时，请注意 “预期导入状态” 列中的值是 “活动” 还是 “历史”。 活动 表示此行上的标识在迁移时正确映射为活动状态。 历史 意味着标识在迁移时成为历史。 请务必查看生成的映射文件的完整性和正确性。
重要
如果 Microsoft Entra 发生重大更改，则迁移失败，连接迁移尝试之间的安全 ID 同步。 可以在测试运行之间添加新用户，并且可以进行更正，以确保以前导入的历史标识处于活动状态。 但是，无法更改以前作为活动状态导入的现有用户。 这样做会导致迁移失败。 更改的示例可能是完成测试运行迁移，从已主动导入的 Microsoft Entra ID 中删除标识，为同一标识在 Microsoft Entra ID 中重新创建一个新用户，然后尝试另一个迁移。 在这种情况下，Active Directory 与新创建的 Microsoft Entra 标识之间的活动标识迁移尝试，但会导致迁移失败。
查看正确匹配的标识。 是否存在所有预期的标识？ 用户是否映射到正确的 Microsoft Entra 标识？
如果必须更改任何值，请联系 Microsoft Entra 管理员，验证本地 Active Directory标识是否是同步到 Microsoft Entra ID 并正确设置的一部分。 有关详细信息，请参阅 将本地标识与 Microsoft Entra ID 集成。
接下来，查看标记为 “历史”的标识。 此标记意味着找不到匹配的 Microsoft Entra 标识，原因如下：
- 未为本地 Active Directory与 Microsoft Entra ID 之间的同步设置标识。
- 该标识尚未在 Microsoft Entra ID 中填充（例如，有新员工）。
- Microsoft Entra 实例中不存在标识。
- 拥有该标识的用户不再在公司工作。
若要解决前三个原因，请设置与 Microsoft Entra ID 同步的预期本地 Active Directory标识。 有关详细信息，请参阅 将本地标识与 Microsoft Entra ID 集成。 必须设置并运行 Microsoft Entra 连接，才能在 Azure DevOps Services 中将标识导入为活动状态。
可以忽略第四个原因，因为不再在公司的员工应作为 历史人员导入。
小型团队 (历史标识)
注意
本部分中建议的标识迁移策略应由小型团队考虑。
如果未配置 Microsoft Entra 连接，则标识映射日志文件中的所有用户都标记为历史。 以这种方式运行迁移会导致所有用户导入为 历史记录。 强烈建议配置 Microsoft Entra 连接，以确保将用户导入为活动状态。
运行具有所有历史标识的迁移会产生需要仔细考虑的后果。 只有拥有少数用户的团队，并且设置 Microsoft Entra 连接的成本被视为过高应考虑。
若要将所有标识迁移为历史标识，请遵循后续部分中概述的步骤。 对迁移进行排队时，用于将迁移排队的标识作为组织所有者启动到组织中。 所有其他用户作为历史用户导入。 然后 ，组织所有者可以使用其 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 Azure 虚拟机 （VM） 方法执行迁移。 在这种情况下，请跳过步骤 2 到 5，并按照“准备测试运行阶段”中的说明 ，迁移大型集合部分，然后继续 确定迁移类型。 如果数据迁移工具未显示警告，请使用此步骤中所述的 DACPAC 方法。
DACPAC 是 SQL Server 的一项功能，允许将数据库打包到单个文件中，并部署到 SQL Server 的其他实例。 DACPAC 文件也可以直接还原到Azure DevOps Services，因此你可以将其用作在云中获取集合数据的打包方法。
重要
- 使用SqlPackage.exe时，必须使用 .NET Framework 版本的 SqlPackage.exe 来准备 DACPAC。 MSI 安装程序必须用于安装 .NET Framework 版本的 SqlPackage.exe。 请勿使用 dotnet CLI 或 .zip （Windows .NET 6） 版本的SqlPackage.exe，因为这些版本可能会生成与 Azure DevOps Services 不兼容的 DACPAC。
- 默认情况下，SqlPackage 版本 161 会加密数据库连接，并且可能无法连接。 如果收到登录进程错误，请添加到
;Encrypt=False;TrustServerCertificate=TrueSqlPackage 语句的连接字符串。
使用 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文件都会提供集合中最大表的列表。 有关集合的表大小示例，请参阅以下输出。 将最大表的大小与托管临时目录的驱动器上的可用空间进行比较。
重要
在继续生成 DACPAC 文件之前，请确保 已分离集合。
[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生成的 DACPAC 文件。
为迁移配置集合
在 Azure VM 上还原集合数据库后，请配置 SQL 登录以允许 Azure DevOps Services 连接到数据库以迁移数据。 此登录仅 允许对单一数据库进行读取 访问。
若要开始，请在 VM 上打开SQL Server Management Studio，然后针对要导入的数据库打开新的查询窗口。
将数据库的恢复设置为简单：
ALTER DATABASE [<Database name>] SET RECOVERY SIMPLE;
为数据库创建 SQL 登录，并分配该登录“TF标准版XECROLE”：
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 [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'
注意
在 VM 上的 SQL Server Management Studio 中启用 SQL Server 和Windows 身份验证模式。 如果未启用身份验证模式，迁移将失败。
配置迁移规范文件以面向 VM
更新迁移规范文件，以包含有关如何连接到 SQL Server 实例的信息。 打开迁移规范文件并进行以下更新。
从源文件对象中删除 DACPAC 参数。
更改前的迁移规范显示在以下代码中。
更改后的迁移规范显示在以下代码中。
填写所需的参数，并在规范文件中的源对象中添加以下属性对象。
"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 文件
注意
如果使用 SQL Azure VM 方法，只需提供连接字符串。 无需上传任何文件，可以跳过此步骤。
DACPAC 必须放置在 Azure 存储容器中，该容器可以是现有容器，也可以是专门为迁移工作创建的容器。 请务必确保在正确的地理位置创建容器。
Azure DevOps Services 在多个 地理位置可用。 导入到这些位置时，正确放置数据以确保迁移能够成功启动至关重要。 数据必须放置在要导入到的同一地理位置。 将数据放置在任何其他位置会导致迁移无法启动。 下表列出了用于创建存储帐户和上传数据的可接受地理位置。
| 所需迁移地理位置 | 存储帐户地理位置 |
|---|---|
| 中央美国 | 中央美国 |
| 欧洲西部 | 欧洲西部 |
| 英国 | 英国南部 |
| 澳大利亚东部 | 澳大利亚东部 |
| 巴西南部 | Brazil South |
| 印度南部 | 印度南部 |
| 加拿大中部 | 加拿大中部 |
| 亚太（新加坡） | 亚太（新加坡） |
尽管 Azure DevOps Services 在美国多个地理位置可用，但只有 Central 美国 位置接受新的 Azure DevOps Services。 目前无法将数据迁移到其他美国 Azure 位置。
从Azure 门户创建 Blob 容器。 创建容器后，上传集合 DACPAC 文件。
迁移完成后，删除 Blob 容器，并随附包含 AzCopy 或任何其他 Azure 存储资源管理器工具（如 Azure 存储 资源管理器）的工具随附的存储帐户。
注意
如果 DACPAC 文件大于 10 GB，建议使用 AzCopy。 AzCopy 支持多线程上传，可加快上传速度。
步骤 4：生成 SAS 令牌
共享访问签名 (SAS) 令牌提供对存储帐户中资源的委派访问。 令牌允许你为 Microsoft 提供访问数据以执行迁移所需的最低权限级别。
可以使用Azure 门户生成 SAS 令牌。 从安全点来看，我们建议执行以下任务：
- 仅 选择“读取 ”和 “列出 ”作为 SAS 令牌的权限。 不需要其他权限。
- 设置不超过未来七天的到期时间。
- 仅限制对 Azure DevOps Services IP 的访问。
- 将 SAS 密钥视为机密。 不要将密钥保留在不安全的位置，因为它授予对存储在容器中的任何数据的读取和列出访问权限。
步骤 5：完成迁移规范
在前面的过程中，你部分填写了迁移规范文件，称为 migration.json。 此时，你有足够的信息来完成除迁移类型之外的所有剩余字段。 迁移类型稍后将在迁移部分中介绍。
在migration.json规范文件中的“源”下，完成以下字段。
- 位置：粘贴从脚本生成的 SAS 密钥，然后在上一步中复制。
- Dacpac：确保文件（包括 .dacpac 文件扩展名）与上传到存储帐户的 DACPAC 文件同名。
最终迁移规范文件应如以下示例所示。
确定迁移类型
导入可以排队作为测试运行或生产运行。 ImportType 参数确定迁移类型：
- TestRun：将测试运行用于测试目的。 系统在 45 天后删除测试运行。
- ProductionRun：如果要保留生成的迁移，并在迁移完成后在 Azure DevOps Services 中全职使用组织，请使用生产运行。
提示
我们始终建议先完成测试运行迁移。
测试运行组织
测试运行组织可帮助团队测试其集合的迁移。 在可以运行生产迁移之前，必须删除任何已完成的测试运行组织。 所有测试运行组织都有 有限的存在，并在一定时间段后自动删除。 有关组织何时被删除的信息包含在迁移完成后应收到的成功电子邮件中。 请务必记下此日期并相应地计划。
测试运行组织在删除前 45 天。 在指定的时间段后，将删除测试运行组织。 在进行生产迁移之前，可以根据需要多次重复测试运行导入。
删除测试运行
在尝试新测试之前删除任何以前的测试运行。 当团队准备好执行生产迁移时，需要手动删除测试运行组织。 在运行第二次测试运行迁移或最终生产迁移之前，请确保删除在上一测试运行中创建的任何以前的 Azure DevOps Services 组织。 有关详细信息，请参阅 “删除组织”。
提示
可选信息，以帮助用户更成功的测试运行迁移，遵循第一个测试的迁移预计需要更长的时间，因为需要额外的时间来清理以前的测试运行中的资源。
删除或重命名后，组织名称最多可能需要一小时才能可用。 有关详细信息，请参阅 迁移后任务 文章。
如果遇到任何迁移问题，请参阅 排查迁移和迁移错误。
运行迁移
你的团队现已准备好开始运行迁移的过程。 在尝试生产运行迁移之前，建议先进行成功的测试运行迁移。 通过测试运行导入，可以提前了解迁移的外观、识别潜在问题，并在进入生产运行之前获得经验。
注意
- 如果需要对集合重复已完成的生产运行迁移，就像回滚时一样，请在对另一个迁移进行排队之前联系 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 中的分离过程将存储在集合数据库外部的用户标识信息传输到新的 TFS 服务器，或者在这种情况下，可移植到 Azure DevOps Services。
从 Azure DevOps Server 实例上的 Azure DevOps Server 管理员istration 控制台轻松分离集合。 有关详细信息，请参阅 移动项目集合，分离集合。
将迁移排队
使用数据迁移工具的 导入 命令启动迁移。 迁移命令将迁移规范文件作为输入。 它会分析文件，以确保提供的值有效，如果成功，它将排队迁移到 Azure DevOps Services。 迁移命令需要 Internet 连接，但不要求连接到 Azure DevOps Server 实例。
若要开始，请打开命令提示符窗口，并将目录更改为数据迁移工具的路径。 建议查看工具提供的帮助文本。 运行以下命令以查看迁移命令的指南和帮助：
Migrator migration /help
用于对迁移进行排队的命令具有以下结构：
Migrator migration /importFile:{location of migration specification file}
以下示例演示已完成的迁移命令：
Migrator migration /importFile:C:\DataMigrationToolFiles\migration.json
验证通过后，使用与生成标识映射日志文件相同的 Microsoft Entra 租户成员的标识登录到 Microsoft Entra ID。 已登录用户是导入组织的所有者。
注意
每个 Microsoft Entra 租户限制为每 24 小时 5 次导入。 只有排队的导入才会计入此上限。
当团队启动迁移时，会将电子邮件通知发送给排队迁移的用户。 在迁移排队大约 5 到 10 分钟后，团队可以转到组织检查状态。 迁移完成后，团队将定向到登录，并向组织所有者发送电子邮件通知。
数据迁移工具会标记迁移之前需要更正的错误。 本文介绍在准备迁移时可能收到的最常见警告和错误。 更正每个错误后，再次运行 迁移程序验证 命令以验证解决方法。
后续步骤
相关文章
反馈
即将发布：在整个 2024 年，我们将逐步淘汰作为内容反馈机制的“GitHub 问题”，并将其取代为新的反馈系统。 有关详细信息，请参阅：https://aka.ms/ContentUserFeedback。
提交和查看相关反馈