我只想将整个工作项目项目从一个“组织”移动到另一个。当我使用以下配置运行 migration.exe 时，我收到一个错误。我确实观看了 YouTube 视频并尝试按照 git 中的说明进行操作，但我无法弄清楚我做错了什么。任何帮助深表感谢！谢谢！

我们在 TFS 中有一个 Bug 描述列和重现步骤，但我们的 Dev Ops 模板只有 Reproduction Steps 列。我想合并 TFS 中的描述 + 复制步骤并迁移到 Azure 中的复制步骤。

Azure DevOps 迁移工具文档列出了 FieldMergeMap，但我没有看到任何示例文档。有人可以提供有关如何配置 FieldMergeMap json 的示例吗？

[错误][完成：55/837][sid:16308 |Rev:15][tid:null | 在 Work item:16308 上找到 15 个要迁移的修订

[错误][完成：55/837][sid:16308 |Rev:15][tid:null | ...未能保存 [错误][完成：55/837][sid:16308 |Rev:15][tid:null | Microsoft.TeamFoundation.TeamFoundationServiceUnavailableException：HTTP 代码 503：服务不可用 ---> System.Net.WebException：远程服务器返回错误：（503）服务器不可用。在 System.Net.HttpWebRequest.GetResponse() 在 Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.SendRequestAndGetResponse(HttpWebRequest webRequest, WebException& webException) --- 内部异常堆栈跟踪结束 --- 在 Microsoft.TeamFoundation.Client.Channels。 TfsHttpWebRequest.ReadResponse(HttpWebResponse webResponse, WebException webException) 在 Microsoft.TeamFoundation.Client.Channels.TfsHttpWebRequest.IsAuthenticationChallenge(TfsMessage requestMessage,1 asOfDate, Boolean useMaster, RowSetCollection& workItem, MetadataTableHaveEntry[] metadataHave, String& dbStamp, RowSetCollection& metadata) at Microsoft.TeamFoundation.WorkItemTracking.Proxy.WorkItemServer.GetWorkItem(String requestId, Int32 workItemId, Int32 revisionId, Int32 minimumRevisionId, Nullable1 asOfDate, Boolean useMaster, IWorkItemRowSets& workItem, MetadataTableHaveEntry[] metadataHave, String& dbStamp, IMetadataRowSets& metadata) at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.LoadWorkItem(Int32 id, Int32 rev, Nullable1 asof, IWorkItemRowSets& witem) at Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItem..ctor(WorkItemStore store, Int32 id, Int32 revision) at VstsSyncMigrator.Engine.WorkItemStoreContext.GetRevision(WorkItem workItem, Int32 revision) in D:\a\1\s\src\VstsSyncMigrator.Core\Execution\ComponentContext\WorkItemStoreContext.cs:line 202 at VstsSyncMigrator.Engine.WorkItemMigrationContext.ReplayRevisions(List1 revisionsToMigrate, WorkItem sourceWorkItem, WorkItem targetWorkItem, Project destProject, WorkItemStoreContext sourceStore, Int32 current, WorkItemStoreContext targetStore) 在 D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs:line 323 [错误] [完成：55/837][sid:16308 |Rev:15][tid:null | System.NullReferenceException：对象引用未设置为对象的实例。在 D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs 中的 VstsSyncMigrator.Engine.WorkItemMigrationContext.ProcessWorkItem(WorkItemStoreContext sourceStore, WorkItemStoreContext targetStore, Project destProject, WorkItem sourceWorkItem, Int32 retryLimit, Int32 retrys) ：第 197 行 migration.exe 警告：0：[异常] System.NullReferenceException：你调用的对象是空的。在 D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs 中的 VstsSyncMigrator.Engine.WorkItemMigrationContext.ProcessWorkItem(WorkItemStoreContext sourceStore, WorkItemStoreContext targetStore, Project destProject, WorkItem sourceWorkItem, Int32 retryLimit, Int32 retrys) :D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\WorkItemMigrationContext.cs 中 VstsSyncMigrator.Engine.WorkItemMigrationContext.InternalExecute() 的第 244 行：VstsSyncMigrator.Engine.MigrationContextBase.Execute() 中的第 124 行D:\a\1\s\src\VstsSyncMigrator.Core\Execution\MigrationContext\MigrationContextBase.cs：第 35 行

我正在使用 Naked Agility 提供的 Azure DevOps 迁移工具，并且它们运行良好。工作项正在迁移，但在短短几分钟内，我们就达到了速率限制的阈值。我自己不是开发人员，所以我不确定从哪里开始，或者是否有办法绕过这些限制。我们正在迁移大约 9000 个工作项，并在 4 天内迁移了大约一半，然后程序崩溃了。那么有没有人有关于如何加快速度的提示？

我现在重新开始迁移，它会跳过已经存在的迁移，但它仍然需要几天才能完成。

我使用了 10.2 的版本并面临以下问题之一

问题是，在 17 个任务工作项中，有 15 个即将到来，2 个任务未迁移，但在那个地方创建了两个没有标题和状态的产品积压项目，并带有新状态

1. 这是我的配置文件：

我们需要将特定团队（在区域路径 X 下）的选定工作项类型从本地 TFS 服务器迁移到 Azure DevOps。我们尝试将QueryBit和BasePaths设置为源区域路径，但没有成功过滤团队的工作项。

• 我们应该使用QueryBit还是BasePaths，或者两者都使用？
• 是否有任何示例配置文件可用作快速入门或参考？

我们已经看了几次概述视频，并努力寻找相关文档。

我正在使用Azure DevOps 迁移工具软件将我们的现场 TFS 项目迁移到 DevOps。我们有许多项目包含项目工作项之间的循环链接。

例如，

• ProjectA.WorkItem#1相关ProjectB.WorkItem#2
• ProjectB.WorkItem#3相关ProjectA.WorkItem#4

假设我先迁移 ProjectA，然后迁移 ProjectB，和之间的链接#1将#2无效，但和之间的链接#3将#4完好无损。

我已尽我所能查看了文档，但似乎找不到“修复断开的链接”选项。如果我再次重新运行迁移工具，它不会发现对工作项的任何更改，因此会跳过它们。

#1 -> #2一旦它们都存在于 DevOps 服务器上，有什么方法可以修复链接？

我们正在使用 Azure DevOps OSS 迁移工具，并观看视频和链接。

我们正在从一个 Azure DevOps 组织迁移到另一个组织。

我们经常遇到如下问题，迁移工具停止。

我使用的是版本 10，在我的 configuration.json 中，我只使用 NodeStructuresMigrationConfig 和 WorkItemMigrationConfig 处理器。

我迁移所有打开的工作项，然后迁移关闭的工作项。有时在迁移已关闭的工作项期间，迁移工具会创建重复的父项和空的工作项。

这是我的configuration.json：

有人可以提供一些关于错误的信息吗？

谢谢，丹尼斯

我正在将数据从一台服务器迁移到另一台服务器。除了新位置的 newley 导入的工作项有问题外，它工作得很好。

选择一个时，它显示“字段'激活日期'的值必须为空。如果我删除激活日期，它只会跳转到类似的新警告。在源数据检查时，有子链接到 devops 工具没有拉过来的工作项目。

有没有办法在配置文件中指定它以在迁移时包含子链接？

亲切的问候

我目前正在使用 Azure DevOps 迁移工具将一些工作项从本地 Azure DevOps 集合移动到 Azure DevOps 在线/云集合。

在云版本上，我们专门使用敏捷模板，因此我需要迁移一些使用 scrum 模板的项目。这意味着将产品待办事项列表项转换为用户故事。

运行迁移工具并设置 WorkItemTypeDefinition 如下

导致错误“System.Exception: WARNING: Unable to find 'Product Backlog Item' in the target project。这很可能是由于 WorkItemTypeDefinition 下的 .json 配置中的拼写错误！”

似乎没有错字，也没有我能看到的任何其他明显错误。其他 WIT 似乎处理得很好。任何人都可以帮忙吗？

有关 configuration.json 的扩展视图，请参见片段

配置.json