Path is not anchored in the target project areas despite AreaMaps (v16.3.3, TfsNodeStructureTool)

[TKO261011]

I’m migrating work items from an project “KD WIBU” to an Azure DevOps Services organization, target project “D365 Projekt TST”, using Azure DevOps Migration Tools v16.3.3.

The migration consistently fails during the node validation phase with:

[hh:mm:ss INF] [16.3.3] Migrating all Nodes before the Processor run.
[hh:mm:ss INF] [16.3.3]  Processing Node: \KD WiBU\Area\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop, start date: null, finish date: null
[hh:mm:ss FTL] [16.3.3] Path \KD WiBU\Area\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop is not anchored in the target project, it cannot be created.

Because of this fatal error, no work items are migrated. This happens even though I’ve configured AreaMaps according to the documentation and created a matching area structure in the target project.

Area structures
Source project KD WIBU
In the Azure DevOps UI, the area path for the problematic items is directly under the project, e.g.
KD WIBU\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop.

Target project D365 Projekt TST
I have created a corresponding area structure:
D365 Projekt TST\KD WIBU\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop.

My goal with the AreaMaps is to map all KD WIBU area paths to the KD WIBU root in the target (D365 Projekt TST\KD WIBU), effectively using it as a catch‑all area for the migration.

What the logs show
Pre‑validation (WorkItemTypeValidatorTool)

All work item types and fields, including System.AreaPath and System.IterationPath, are either present or mapped for all tested types (Analyse Task, Approval Task, Bug, Change Request, Config Task, Deployment Task, Design Task, Dev Task, etc.).

The reflected work item ID field Custom.ReflectedWorkItemId is present in all target work item types.

Node validation / migration

The run then proceeds to “Migrating all Nodes before the Processor run”.

It attempts to process the node \KD WiBU\Area\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop and fails with:
Path ... is not anchored in the target project, it cannot be created.

As a result, the processor stops and no work items are migrated.

According to the documentation and discussions, any nodes that are validly mapped by AreaMaps should be converted to target paths and should not be caught by the “This path is not anchored in the source project/target project” message.

In my case, even with the KD WIBU AreaMaps configured and the target area existing, the path is still reported as “not anchored”.

What I’ve tried so far
Configured AreaMaps using both simple literal mappings and regex patterns as shown in the docs, e.g.
"AreaMaps": { "KD WIBU\inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop": "D365 Projekt TST\KD WIBU" } and the regex version shown above.

Used NodeBasePaths and then removed it based on recent guidance that AreaMaps alone should be sufficient.

Disabled the FieldMappingTool completely to ensure that FieldMaps don’t interfere.

Verified that the target area paths exist exactly with the names used in the mappings (KD WIBU, inh P090001 WIBU - Microsoft Funding_ Pilot _ Envisioning Workshop).

Increased log verbosity and confirmed that all WorkItemType/field validations pass before the node error.

The fatal node error persists in all variants.

Questions / request for guidance
Is there a known issue in 16.3.3 where certain area path forms (e.g. KD WIBU with spaces/underscores, or the \KD WiBU\Area... form shown in the log) are not correctly matched by AreaMaps, so they still get flagged as “not anchored”?

Does the combination of LanguageMaps.AreaPath = "Area" and the TfsNodeStructureTool cause the path string seen by the node validator to differ from the path used in AreaMaps (e.g. prefixed with “Area” or process name), and if so, how should the mapping be written so it actually applies?

For a catch‑all scenario (all KD WIBU areas → D365 Projekt TST\KD WIBU), what is the recommended configuration pattern in 16.3.3 to ensure that the node validation passes and work items can be created, without having to manually recreate the full KD WIBU area tree in the target?

I plan to migrate all KD WIBU work items (several thousand Requirements, Bugs, Tasks, etc.), so I’d like to make sure this node anchoring issue is resolved before attempting a full migration.

If helpful, I can attach:

• The full log file from the latest run (including the “Migrating all Nodes” section).
• Screenshots of the source and target area structures.
• The complete configuration.json used for the run.

Thanks in advance for any guidance or workarounds.

The following is my last used configuration.json:

{
"$schema": "https://devopsmigration.io/schema/configuration.schema.json",
"Serilog": {
"MinimumLevel": "Information"
},
"MigrationTools": {
"Version": "16.3",

"Endpoints": {
  "Source": {
    "Name": "Source",
    "EndpointType": "TfsTeamProjectEndpoint",
    "Collection": "https://dev.azure.com/InwaySystems/",
    "Project": "KD WIBU",
    "Authentication": {
      "AuthenticationMode": "AccessToken",
      "NetworkCredentials": {
        "Domain": "",
        "UserName": "",
        "Password": "***"
      },
      "AccessToken": "XXX"
    },
    "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    },
    "ProductVersion": "OnPremises"
  },

  "Target": {
    "Name": "Target",
    "EndpointType": "TfsTeamProjectEndpoint",
    "Collection": "https://dev.azure.com/WiBU-Gruppe/",
    "Project": "D365 Projekt TST",
    "Authentication": {
      "AuthenticationMode": "AccessToken",
      "NetworkCredentials": {
        "Domain": "",
        "UserName": "",
        "Password": "***"
      },
      "AccessToken": "XXX"
    },
    "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    },
    "ProductVersion": "OnPremises"
  }
},

"CommonTools": {
  "TfsNodeStructureTool": {
    "Enabled": true,

    
    "ShouldCreateMissingRevisionPaths": true,
    "StopMigrationOnMissingAreaIterationNodes": true,

    
    "AreaMaps": {
      "^KD WIBU\\\\.*$": "D365 Projekt TST\\KD WIBU"
    },

    
    "IterationMaps": { }
  },

  "FieldMappingTool": {
    "Enabled": false,
    "FieldMaps": [ ]
  }
},

"CommonEnrichersConfig": [ ],

"Processors": [
  {
    "ProcessorType": "TfsWorkItemMigrationProcessor",
    "Enabled": true,
    "WIQLQuery": "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = @TeamProject AND [System.ID] IN (120728,120726,120727,120724,120722,120723,120725,67222,74995)",
    "LinkMigration": true,
    "AttachmentMigration": true,
    "FixHtmlAttachmentLinks": true,
    "FilterWorkItemsThatAlreadyExistInTarget": false,
    "GenerateMigrationComment": true,
    "SourceName": "Source",
    "TargetName": "Target"
  }
]

}
}