Issues in Work Items Migration from Azure DevOps Services (Cloud) to Azure DevOps Server 2022.2 #2962
Unanswered
SohaibRashid808
asked this question in
Q&A
Replies: 1 comment 1 reply
-
You are hitting the prevalidator. Please check the docs for how to Validate |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I am trying to migrate work items from Azure DevOps Services (Cloud) to Azure DevOps Server 2022.2. Note that the Azure DevOps Server 2022.2 was previously upgraded from Team Foundation Server 2015. Both also are on different domains. The Project in the cloud is made on a custom inherited process HBL-Agile from the built-in Agile Process. It has a few custom work items like Epic_CR, Release Notes etc. I have created the same HBL-Agile process with the same custom work items in it having the same fields, from the inherited from the built-in Agile Process in the Azure DevOps Server as well. I have attached the configuration.json file I am executing. I keep running into same errors like:
1. Validating work item type 'Code Review Request'
'Code Review Request' does not contain reflected work item ID field 'Custom.ReflectedWorkItemId'.
2. Validating work item type 'User Story'
Source field 'Microsoft.VSTS.Common.ResolvedReason' and target field 'Microsoft.VSTS.Common.ResolvedReason'
have different allowed values.
Source allowed values:
Target allowed values: 'As Designed', 'Cannot Reproduce', 'Copied to Backlog', 'Deferred', 'Duplicate', 'Fixed', 'Fixed and
verified', 'Obsolete', 'Will not Fix'
3. Validating work item type 'Issue'
Source field 'Microsoft.VSTS.Common.Activity' and target field 'Microsoft.VSTS.Common.Activity' have different
allowed values.
Source allowed values:
Target allowed values: 'Deployment', 'Design', 'Development', 'Documentation', 'Requirements', 'Testing'
4. Some work item types or their fields are not present in the target system (see previous logs). Either add these fields into
target work items, or map source fields to other target fields in options (SourceFieldMappings).
5. If you have some field mappings defined for validation, do not forget also to configure proper field mapping in
FieldMappingTool so data will preserved during migration.
6. If you have different allowed values in some field, either update target field to match allowed values from source, or configure
FieldValueMap in FieldMappingTool.
I have also attached the logs as well for reference. Can someone help me out in resolving these issues, I understand that it is asking me to add the Custom.ReflectedWorkItemId field in some work items types but those items are not visible and I cannot edit it as it is Inherited Process Model. Also I cannot change the value in fields like Microsoft.VSTS.Common.Activity. Is there any way I can skips validation of these work item types and complete the migration.
configuration.json
Logs.txt
Beta Was this translation helpful? Give feedback.
All reactions