How to Migrate Work Items Under a Specific Area Path Without Migrating All Area Paths

[flizzer]

Greetings. First, thanks for this solution! However, I'm having difficulty with one part of a work item migration and I'm not able to resolve it from the information in the docs. Here goes:

1. We're migrating work items under one specific DevOps organization, project and area path which contains multiple clients to a new DevOps organization, project and area path just for this one client. So, for example in our source, we have the structure: Clients\Client1\Phase1 where Clients is our source project. We want our destination to follow the area path: Client1\Phase1 where Client1 is the name of the destination project. Right now, the work items are being migrated, but they have the area path Client1\Client1\Phase1. So, issue one is: How do I update the config file so that the client part of the area path isn't duplicated?

2. On top of that, we're seeing other client area paths from the source migrated into the destination project even though no work items are being migrated for that client. So, we have area paths that resemble Client1\Client2 in the destination project. I'd like for these area paths to be filtered out completely and not migrated. I've tried using the TfsNodeStructureTool's NodeBasePaths like this to resolve it, but to no avail:

"TfsNodeStructureTool": {
        "Enabled": true,
        "NodeBasePaths": ["Client1", "Sprint"],
        "Areas": {
          "Filters": [],
          "Mappings": {}
        },
        "Iterations": {
          "Filters": [],
          "Mappings": {}
        },
        "ShouldCreateMissingRevisionPaths": true,
        "ReplicateAllExistingNodes": true
      }

What should the config look like to stop the extraneous area paths from being included in the migration? My WIQL query is only pulling work items for the client that I want; so, that seems to be working properly.

3. Lastly, the iterations are being brought over mostly correctly, except it's also adding them as nested iterations under a "Clients" Iteration Path like "Clients<Date of Sprint>". Is there any way to stop this behavior?

Thanks for any help you can provide and thanks again for the tool!

[MrHinsh]

You would combine the Query, which filters the work items you want, with the TfsNodeStructureTool:Areas:Mappings to rewrite the Clients\Client1\Phase1 to Client1\Phase1.

To stop the other Area and Iteration paths from being migrated, set ReplicateAllExistingNodes to false.

You can also map your iteration in the same way that you map your areas... however if the date data is not already in the string you will not be able to access it.

[flizzer]

Ok, thanks @MrHinsh. I updated my config based on your recommendations. I'm now getting an exception when running the migration:

System.Web.Services.Protocols.SoapException: VS402485: The Area/Iteration name is not recognized: TestProject3\2024-10-11 at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.HandleReply(TfsClientOperation operation, TfsMessage mes sage, Object[]& outputs) at Microsoft.TeamFoundation.Client.Channels.TfsHttpClientBase.Invoke(TfsClientOperation operation, Object[] parameters , TimeSpan timeout, Object[]& outputs) at Microsoft.TeamFoundation.ProcessConfiguration.Client.TeamConfigurationService.SetTeamSettings(Guid teamId, TeamSett ings teamSettings) at Microsoft.TeamFoundation.ProcessConfiguration.Client.TeamSettingsConfigurationService.SetTeamSettings(Guid teamId, TeamSettings settings) at MigrationTools.Tools.TfsTeamSettingsTool.MigrateTeamSettings() in D:\a\azure-devops-migration-tools\azure-devops-mi gration-tools\src\MigrationTools.Clients.TfsObjectModel\Tools\TfsTeamSettingsTool.cs:line 162 at MigrationTools.Tools.TfsTeamSettingsTool.ProcessorExecutionBegin(TfsProcessor processor) in D:\a\azure-devops-migra tion-tools\azure-devops-migration-tools\src\MigrationTools.Clients.TfsObjectModel\Tools\TfsTeamSettingsTool.cs:line 80 at MigrationTools.Processors.TfsWorkItemMigrationProcessor.InternalExecute() in D:\a\azure-devops-migration-tools\azur e-devops-migration-tools\src\MigrationTools.Clients.TfsObjectModel\Processors\TfsWorkItemMigrationProcessor.cs:line 106 at MigrationTools.Processors.Infrastructure.Processor.Execute() in D:\a\azure-devops-migration-tools\azure-devops-migr ation-tools\src\MigrationTools\Processors\Infrastructure\Processor.cs:line 99 Error logged to Elmah.io!

The hierarchy mentioned in the exception (TestProject3\2024-10-11 )is what I want: Project<Sprint Name>. But I guess it's complaining about not finding it in the target project I'm testing with. I've not run into this before. My updated TfsNodeStructureTool looks like this:

"TfsNodeStructureTool": { "Enabled": true, "NodeBasePaths": ["Adama", "Sprint"], "Areas": { "Filters": [], "Mappings": {"Clients\\Client1":"Client1"} }, "Iterations": { "Filters": [], "Mappings": {"Clients\\*":"Client1"} }, "ShouldCreateMissingRevisionPaths": true, "ReplicateAllExistingNodes": false }
Thoughts about why the iteration wouldn't be recognized?

Thanks for your help!

[MrHinsh]

what is TestProject3 and hwo does it relate to the target and source?

[flizzer]

TestProject3 is the target project name in this case. It's like it didn't find the iteration in the target project, yet I've not had any problem with that before.