-
Hello Team, I am attempting to migrate an ADO board hosted on an internal network (GIDE ADO) to an external ADO board using devops migration tools. However, I am encountering an error message. Could you please assist me in understanding the error message? I also wanted to confirm if it is necessary to add the ReflectedWorkItemIdField in both the source and target systems. I have already added this field in the target system for the 'User Story' work item type, as i am trying to testing only "user story' for now. I have also
|
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 1 reply
-
Hi there, You're reporting a problem with an old version of the Azure DevOps Migration Tools. Please try the latest version and tell us if that fixes your problem. Bonus points for also trying with the latest preview version. Good luck, Thanks, Azure DevOps Migration Tools team |
Beta Was this translation helpful? Give feedback.
-
in your config you have This is validated in newer versions. |
Beta Was this translation helpful? Give feedback.
-
Hello Team, I have tried with the latest version as well as preview version , both ended up in below error. I have used the attached configuration file. Even though I have mentioned PAT token details under access token , getting error as Ouput logs: C:\Users\workspace\DevopsMigrationtool>devopsmigration execute --config configuration.json --dry-run | / | () __ _ _ __ __ _ | | () ___ _ __ | | ___ ___ | | ___ [11:40:29 DBG] [16.0.3] =================================== |
Beta Was this translation helpful? Give feedback.
-
Hello Team, Thank you for your assistance in resolving my previous issue. I successfully migrated all work items(799 items) from the source to the destination. However, I have encountered a scenario that requires clarification. In the source, we have a work item type called "Opportunity," which does not exist in the target. I mapped it to the "User Story" work item type in the target. However, both the source and target already have a "User Story" work item type. Only for the "User Story" work item type do we have a field called "Story Type" in both the source and target. To differentiate between the migrated "Opportunity" work items and the existing "User Story" work items, I would like to update the "Story Type" field in the target. This field has two values: "Story" and "Spike/Opportunity." For the migrated "Opportunity" work items, I want to set the "Story Type" to "Spike/Opportunity." For the original "User Story" work items in both the source and target, the "Story Type" should remain as "Story." In the source, we do not have a "Story Type" field for the "Opportunity" work item type, but we do have it in the target because its getting migrated as 'user story'. Additionally, for the existing "User Story" work items in the source, we need to map their "Story Type" field to the target. I have attached the configuration file, but it is not functioning as expected. I set the default value to "Spike/Opportunity" for all opportunity migrated as user stories work item type, which resulted in all of them being updated to "Spike/Opportunity." If I do not specify a default value under the "Opportunity" block, all entries default to "Story." I suspect there may be an issue with how I am referencing the field called System.WorkItemType for the "Opportunity" work item type. In source story type is referred as xxxx.StoryType , in target its referred Could you please provide guidance on how to handle this mapping and updating process? Thank you! |
Beta Was this translation helpful? Give feedback.
in your config you have
ReflectedWorkItemIdFieldName
instead ofReflectedWorkItemIdField
. This leaves the field empty as there is no default.This is validated in newer versions.