问题描述
谁能提供有关多次迁移运行的最佳实践？从TFS 2017.3.1迁移到Azure DevOps服务。处理大量工作项目（32k）。当然，TSTU的节流使运行需要很长时间，因此我一直在考虑要尽力而为，然后是第二次通过以承接第一次大的努力。因此...启用UpdateSourceReflectedId将在已经迁移的源项目上设置ReflectedWorkItemId。但是，如果有人更改已经推送的工作项会怎样？历史三角洲会被拾起吗？通常如何解决...我在想也许像Querybit这样的：ReflectedWorkItemId ''和ChangedDate>（上次运行时间），但这是否有必要？那些已经存在于目标上了... ReplayRevisions是否会仅选择缺少的更改？ TIA ...
解决方法
对于大批量生产，我通常会执行以下操作：
- 打开最近90天内编辑的工作项
- 过去90天内编辑的已关闭工作项
- 大量开放更多时间
要注意的重要一点是，仅当链接的两端都存在时才创建链接。
长期运行后，您可以重新运行“上个月编辑”，以使所有更改都被划掉。
要避免在源代码中进行的更改：
- 更改工作项类型
- 在团队项目之间移动工作项
我们会处理这些，但是很松懈。