Azure devops 为什么我的工作项迁移需要这么长时间？

我有一个拥有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

---

每个工作项的迁移长度取决于：

修订数

附件数量

链接数

2k个工作项转化为20k个保存，甚至200k个保存（如果您有TFS的汇总加载项），这种情况并不少见。我看到每个工作项需要3秒，也需要30秒

此外，当Azure DevOps检测到您正在进行大量呼叫时，它可能会主动引入该流程以保护其他用户的服务。这是正常的，没有办法，也不应该有办法。您的迁移不应取代生产用户。您可以通过转到组织上的

/\u settings/usage

查看您的使用情况和应用的任何费率限制

自2016年推出该工具以来，我们增加了一些功能，以帮助加快流程：

• 我们现在只需一次就可以完成工作项、附件和链接；这降低了Azure DevOps服务的负载，并降低了速率限制的频率和严重性
• 我们还添加了恢复迁移的功能，这也使得能够从源系统带来新的更改
• 我们添加了目标中已存在的过滤工作项，以最大限度地减少已处理的项的数量，但这并不能防止发生更改

加速选项：

只接受提示-您可以更改修订，使其只执行工作项的一种状态，即最新状态。您可以将

ReplayRevisions

设置为

false

以仅写入最新版本，并且可以使用

CollapseRevisions

设置为

true

以将JSON与历史附加在一起

靠近目标运行-所有长调用都针对目标，只对源进行一次查询。我通常尝试尽可能靠近目标运行迁移，因此在与目标相同的数据中心运行AzureVM是一个不错的选择。但是，如果您的源不可访问，您可能会受到限制

范围化查询-如果我正在进行大规模迁移，我通常只会在第一次运行时将查询范围化到那些我需要尽快启动并运行的团队当前在范围内的工作项。可能只有在过去60天内编辑过的非关闭工作项。然后，我会增加后续运行的范围

---

下面的答案解决了你的问题吗？如果是，你可以接受这样的答案。