Work Items Not To Be Migrated Causing Errors

[rpollick]

Please review the attached log and script. I am getting errors still when attempting to perform the migration that do not include all the work items. Have placed these work items in the TfsValidateRequiredFieldTool that is set to true and the work items to be excluded listed. Also getting error, does not contain reflected work item ID field 'Custom.ReflectedWorkItemId'. Can this name be set to your liking as long as it's set to this name in the script? Would this be the label name or the Field Reference Name?
migration2025072906.log
configuration-default-shared.json

[rpollick]

Will someone please take a look at the log and my configuration JSON file? Sorry for all the questions. I'm kinda in a tight spot now and need to turn this around.

[MrHinsh]

Commercial support is available at cost @rpollick from any of the consultants listed on https://devopsmigration.io/support/. Everyting here is a best effort and not timely..

[MrHinsh]

Have you followed the instructions in the error? What did not work?

[06:34:12 ERR] [16.2.11-Preview.1] 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 (FieldMappings).

You can turn the validator off using https://blue-river-093197403-preview.westeurope.5.azurestaticapps.net/docs/reference/tools/work-item-type-validator-tool/

[MrHinsh]

@satano can you respond?

[satano]

Hi. This is caused by fields validation between source and target. TfsWorkItemTypeValidatorTool is responsible for this and you need to configure it. The warnings in the log and resulting error means, that there are some fileds in source, that do not exist in target. If you want to just continue migration anyway, you can just disable this tool. Configuration of the tool is under CommonTools – but I really do not recommend this:

"TfsWorkItemTypeValidatorTool": {
  "Enabled": false
},

But this validation is for good cause. because if you have some missing field in target, that data will not be migrated. This may and may not be what you want. So either fix missing fields by adding it to target, or set the fields in configuration to not validate them. Output in the log informs you about field type and some more in information, so you can easily add relevant field into target. In the following example configuration, I added only work item types from your migration processor query. And this is sample configuratio for Bug work item type only. You have two options. If you just do not want be notified about discrepancy of the field between source and target, configure it in FixedTargetFields. If the field exist in target, but have different name, configure this mapping in SourceFieldMappings.

"TfsWorkItemTypeValidatorTool": {
  "Enabled": true,
  "IncludeWorkItemtypes": [
    "Test Case",
    "Task",
    "Issue",
    "Feature",
    "Bug",
    "User Story",
    "Epic"
  ],
  "SourceFieldMappings": {
    "Bug": {
      "Custom.ProdTarget": "Custom.SomeOtherFieldNameInTarget",
    },
  },
  "FixedTargetFields": {
    "Bug": [
      "Custom.Enhancement",
      "Custom.DevEstDate",
      "Custom.RootCause"
    ]
  }
},

You have one more problem with your configuration. This warnings:

'Bug' does not contain reflected work item ID field 'Custom.ReflectedWorkItemId'.

Reflected work item ID is mandatory for work item migration, though if you disable that validator, migration will run. But without reflected work item ID the migration will (probabaly) fail. Name of this field is configured in source and target endpoints and property for it is ReflectedWorkItemIdField. Value from target endpoint is used when validating work item types and migrating work items. You have there ReflectedWorkItemIDFieldName which is not correct.