多次迁移运行的建议？

Question

谁能提供有关多次迁移运行的任何最佳实践？从 TFS 2017.3.1 迁移到 Azure DevOps 服务。处理相当数量的工作项目（32k）。当然，TSTU 节流使运行需要很长时间，所以我正在考虑将我能做的事情推到前面，然后第二次通过以获取自第一次大推后的新工作项。所以...启用 UpdateSourceReflectedId 会在已迁移的源项目上设置 ReflectedWorkItemId。但是，如果有人更改了已经推送的工作项，会发生什么？历史增量会被拾起吗？这通常是如何解决的...我在想可能是一个 Querybit，例如： ReflectedWorkItemId '' 和 ChangedDate > （上次运行时间），但这有必要吗？那些已经存在于目标上... ReplayRevisions 会只拾取缺少的更改吗？ TIA...

Answer 1

对于大型运行，我通常会执行以下操作：

• 过去 90 天内编辑的打开工作项
• 过去 90 天内编辑的已关闭工作项
• 分块开放更多天

需要注意的重要一点是，只有在链接的两端都存在时才会创建链接。

长时间运行后，您可以重新运行“上个月已编辑”以取消任何更改。

在源代码中要避免的更改：

• 更改工作项类型
• 在团队项目之间移动工作项

我们处理这些，但很松散。