【问题标题】：Why is my work item migration taking so long?为什么我的工作项迁移需要这么长时间？
【发布时间】：2020-10-16 16:39:55
【问题描述】：
我有一个包含 2200 个工作项的 Azure Devops 2019 项目，我预计这需要不到几个小时。但是，迁移工具需要 3 天多的时间才能完成。这是正常的迁移持续时间，还是我们的设置或工具有问题？
我发现日志记录中似乎没有任何作用
10:33:35 WotrkItemQuery: keyToFiund: XXX
10:33:55 [Test Case] [Complete: 1606/2215] work item has 2 revisions and revision migration is set to True
10:44:16: [Test Case] [Complete 1606/2215] Found 2 revisions to migrate on Work Item:XXX
【问题讨论】：
-
下面的答案是否解决了您的问题？如果是，您可以接受它作为答案，如this。
标签：
azure-devops
azure-devops-migration-tools
【解决方案1】：
每个工作项的迁移时间取决于：
- 修订次数
- 附件数
- 链接数
如果您的 TFS 有汇总插件，2k 工作项变成 20k 保存甚至 200k 的情况并不少见。我已经看到每个工作项需要 3 秒，还有 30 秒。
此外，当 Azure DevOps 检测到您正在进行大量调用时，它可能会主动将Rate Limits 引入进程以保护其他用户的服务。这是正常的，没有办法，也不应该有。您的迁移永远不应取代生产用户。您可以通过转到您的组织上的/_settings/usage 来查看您的使用情况和应用的任何速率限制。
自 2016 年推出该工具以来，我们添加了一些功能来帮助加快流程：
- 我们现在一次性完成工作项、附件和链接；这减少了 Azure DevOps 服务的负载，并降低了速率限制的频率和严重性。
- 我们还添加了恢复迁移的功能，这也使我们能够从源系统中引入新的更改。
- 我们添加了
FilterWorkItemsThatAlreadyExistInTarget 以最大程度地减少处理的项目数量，但这并不是为了防止发生更改。
加速选项：
-
只接受提示 - 您可以关闭修订，以便它只执行工作项的 1 个状态，即最新的。您可以将
ReplayRevisions 设置为false 以仅写入最新的，您可以使用CollapseRevisions 设置为true 来附加一个带有历史记录的JSON。
-
更接近目标运行 - 所有长调用都针对目标，只有一个针对源的查询。我通常会尝试在尽可能靠近目标的地方运行迁移，因此在与目标相同的数据中心内的 AzureVM 上运行是一个不错的选择。但是，如果您的来源不可访问，您可能会受到限制。
-
范围查询 - 如果我正在进行大规模迁移，我通常会将第一次运行的查询范围限定为那些目前在我需要尽快启动和运行的团队范围内的工作项。可能只有在过去 60 天内编辑过的非关闭工作项。然后我会增加后续运行的范围。