迁移完成后，会向组织所有者发送电子邮件，此时，有权访问的任何人都可以登录到新迁移的 Azure DevOps Services 组织。 但是，在使组织可供所有用户使用之前，应完成本文中列出的常见任务。
验证迁移的内容
组织可用后立即验证迁移的内容和配置，以确保所有关键组件都已成功迁移。 项目集合管理员应领导此过程，并涵盖集合的所有主要区域。 建议验证以下内容：
- 源代码：确认所有存储库都已正确迁移且可访问。
- 生成历史记录：验证完整的生成历史记录是否完好无损，并符合预期。
- 区域路径：确保所有区域路径都存在且结构正确。
- 工作项：查看工作项的代表性示例，以确认数据完整性和关系。
- 权限和安全性：验证是否已正确配置用户权限、组和访问控制。 根据用户在您的 Azure DevOps Server 中的设置方式，他们可能直到首次登录后才会出现在新组织的用户集中。 如果迁移后缺少任何用户，请让他们登录，然后重新检查其状态。
- 服务连接和管道：检查服务连接和管道配置是否正常工作。
- 仪表板和控件：确认仪表板正确呈现，控件显示预期数据。
在将组织打开到更广泛的用户群之前，此验证有助于识别任何缺失、不完整或配置不当的数据，确保顺利过渡并最大程度地减少中断。
重要
在确认迁移组织中存在所有预期数据和功能之前，请勿删除或销毁本地数据或停用系统。
重命名组织（可选）
如果在 “入门”阶段创建了具有所需名称的占位符组织，现在可以重命名已迁移的组织以替换它。 仅当这是最终迁移并且想要使用特定组织名称时，才需要执行此步骤。 有关详细信息，请参阅 重命名组织。
设置帐单
若要为 Azure DevOps 中的用户或服务（如托管生成和部署代理）付费，需要为组织设置计费。 如果迁移多个集合，则应确保所有组织都使用同一 Azure 订阅进行计费，并确保您的订阅已启用 多组织计费。 然后，可以在运行迁移的日历月份免费分配任意数量的基本用户。
配置构建代理
如果在 Azure DevOps Server 环境中使用了自动生成或部署服务器，则可以将它们连接到 Azure DevOps Services 组织。 迁移过程中，迁移了所有生成定义，但必须针对新的 Azure DevOps Services 组织重新配置代理和池。
有关详细信息，请参阅 Azure Pipelines 代理。
如果计划使用现有的本地私有生成代理，必须清除其缓存，以确保不会遇到与旧版 Team Foundation 版本控制（TFVC）或指向本地集合的 Git 指针相关的任何生成问题。 有关详细信息，请参阅刷新客户端计算机上的缓存。
小窍门
如果在 Azure DevOps Server 中使用了发布管理，则迁移了发布管道和历史记录数据。 与构建类似，您必须针对新组织重新配置代理（再次链接）和池。
使用 Azure Artifacts
Azure Artifacts 包含在 Azure DevOps Services 中，面向授予基本许可证的所有用户。 无需安装扩展。 迁移后，Azure Artifacts 数据应可用。 有关详细信息，请参阅 Azure Artifacts 概述。
自定义 Azure Boards
如果已有与 Azure DevOps Server 关联的 GitHub Enterprise Server 连接，则它无法按预期工作。 GitHub 中提到的工作项可能会延迟或永远不会显示在 Azure DevOps Services 中。 出现此问题的原因是与 GitHub 关联的回调 URL 不再有效。
若要解决此问题，请考虑以下任务：
- 删除并重新创建连接： 删除并重新创建与 GitHub Enterprise Server 存储库的连接。 按照 Azure Boards 文档中“Connect”部分提供的步骤顺序进行操作。
-
修复 Webhook URL：转到 GitHub 的存储库设置页并编辑 Webhook URL 以指向已迁移的 Azure DevOps Services 组织 URL：
https://dev.azure.com/{OrganizationName}/_apis/work/events?api-version=5.2-preview
有关详细信息，请参阅 “配置和自定义 Azure Boards”。
检查权限
你的组织包括五个具有 基本 访问权限的免费用户。 有关详细信息，请参阅添加组织用户和管理访问权限。
通知团队
运行生成并配置许可证订阅后，建议向所有用户打开组织进行验证。 然后，单个用户可以确保所有内容都已到位，具有正确的访问级别，并且可以拉取代码。
具有本地工作区的 TFVC 用户必须针对新组织重新映射其工作区，Git 用户必须重新配置其远程服务器以拉取代码。