How-to: Migrating Plans and Suites

[MrHinsh]

This discussion is for questions, feedback, and community support related to the How-to: Migrating Plans and Suites.

Quick Reference

• Documentation: How-to: Migrating Plans and Suites

How to Use This Discussion

• Ask Questions: If you need help configuring or using this component
• Share Examples: Post your configuration examples or use cases
• Report Issues: Describe any problems you encounter (though bugs should be reported as GitHub Issues)
• Request Features: Suggest improvements or new features

Related Documentation

Please refer to the official documentation for detailed configuration options and examples.

[code-on-git]

Great article!
I tried to follow it and it works fine. But I have a question just to understand what happens.
What is actually the difference between step 1 and 2? I see that step 2 has the config for FieldtoFieldMapConfig and it also include Test Case in the filter.
In my test migration, step 1 took about 2 hours and step 2 took about 1 hour.

First I thought that step 2 would only migrate test cases, but in the logs it looks like it goes through all work items again.

[MrHinsh]

Yea, the query is not right... check https://nkdagility.com/learn/azure-devops-migration-tools/howto/migrating-plans-and-suits/

[YuriVanZieks]

Hi,

May I ask how did you make it work on Step 4 ? That part seems outdated because I keep getting the consistent message

Likely root cause missing properties (all deduped candidate sets):
  Path: MigrationTools.Processors[0]
    - missing WIQLQuery (freq 4)

Path: MigrationTools.Processors[0]
  - (Ln 49, Pos 7) Required: Required properties are missing from object: ResultFileName, WIQLQuery.
  - (Ln 49, Pos 7) Required: Required properties are missing from object: WIQLQuery.
Path: MigrationTools.Processors[0].ProcessorType
  - (Ln 50, Pos 66) Enum: Value "TfsTestPlansAndSuitesMigrationProcessor" is not defined in enum.
Path: MigrationTools.Processors[0].TestPlanQuery
  - (Ln 53, Pos 29) Type: Invalid type. Expected String but got Null.

Total unique validation errors after filtering: 4

NOTE: A single missing property can trigger multiple branch (anyOf/allOf) mismatches. Fix the root cause lines above first.

And when we check the processor for TestPlans and Suites : https://blue-river-093197403-preview.westeurope.5.azurestaticapps.net/docs/reference/processors/tfs-test-plans-and-suites-migration-processor/
the template isn't quite the same (and I notice that this line on the step 4 here ""ProcessorType": "** removed as a secret ***" seems to be an error)

What type of Query is needed here ? What is the object ResultFileName and where is it mentioned ?

My processor as of now looks like this :

        "ProcessorType": "TfsTestPlansAndSuitesMigrationProcessor",
        "Enabled": true,
        "OnlyElementsWithTag": "",
        "TestPlanQuery": null,
        "RemoveAllLinks": false,
        "MigrationDelay": 0,
        "RemoveInvalidTestSuiteLinks": false,
        "FilterCompleted": false,
        "SourceName": "Source",
        "TargetName": "Target"

Thanks a lot

[thaiknguyen]

Hello MrHinsh,
I'm curious to know if there are any plans to add support for migrating test runs as well in order to fully migrate all the test artifacts. If this would require funding, what are we looking at for costs, and timeframes?

[MrHinsh]

We currently use the TFS Object Model (original SOAP API's for compatibility), which do not give access to creating or saving test runs. It would require a complete rework of the current version to the rest API.

It's a significant piece of work but not overly significant. It's on the backlog (the rewrite to the REST API) but usage is not statistically significant if test plan migrations in lue of funding. Moving to the REST API then makes other artifacts possible.

As for costs, I'd think we would need something on the order of £50k as a fixed price including test runs. If we can find a few folks interested we can split the cost

[sanc001997]

I am migrating my test plans suites and variables while migrating the test plans (suppose I have 1 test plan but I do not want 2 test plans )using below query it is taking all test plans but do not want two test plans which i mentioned in below query

"WIQLQueryBit": "AND [System.WorkItemType] = 'TestPlan' AND [System.Title] NOT IN ('plan name 1', 'Plan name 2')"

How can i Update the query please let me know.

[sanc001997]

same error using below query

"TestPlanQueryBit": "AND [System.WorkItemType] = ('TestPlan') AND [System.Title] NOT IN ('Plan 1','plans2')",

[sanc001997]

Hi Team,

Can you please help me

[potatojaisiladki]

Does this help?

"ProcessorType": "TfsTestPlansAndSuitesMigrationProcessor",
      "Enabled": true,
      "PrefixProjectToNodes": false,
      "OnlyElementsWithTag": null,
      "TestPlanQueryBit": "SELECT [System.ID] FROM (TestPlan AND TestSuite) WHERE [System.TeamProject] = @TeamProject AND [System.WorkItemType] IN ('Test Suite','TestPlan') AND ( [System.State] <> ' ') ORDER BY [System.ChangedDate] desc",
      "RemoveAllLinks": false,
      "MigrationDelay": 0,
      "UseCommonNodeStructureEnricherConfig": false,
      "NodeBasePaths": [],
      "AreaMaps": null,
      "IterationMaps": null,
      "RemoveInvalidTestSuiteLinks": false,
      "FilterCompleted": false,
      "SourceName": "Source",
      "TargetName": "Target3"

[potatojaisiladki]

I mean the query is for my own requirement, but you might want to use the syntax

[MrHinsh]

WIQL does not work for Test Plans & Suits. Please see sample query in the TfsTestPlansAndSuitsProcessor documentation.

[sanc001997]

@MrHinsh Please help and give me the correct query or a sample file how to exclude test plans

[MrHinsh]

Have you checked the samples on https://nkdagility.com/learn/azure-devops-migration-tools/Reference/Processors/TfsTestPlansAndSuitesMigrationProcessor/

[potatojaisiladki]

Question - Do we have to run these steps one by one or all of these setps can be configured in order? I intend to test the scenario anyways but it would be good to know : TIA

[potatojaisiladki]

Update - We can migrate everything in a single run if we use the configurations/mapping in order with more than one endpoint configurations. I declared more than one source and target endpoints. I hope this helps.

Source": {
        "EndpointType": "TfsTeamProjectEndpoint",
        "Collection": "SOURCE COLLECTION/ORGANIZATION URL",
        "Project": "SOURCE PROJECT",
        "Authentication": {
          "AuthenticationMode": "Prompt",
          "NetworkCredentials": {
            "Domain": "YOUR ORG DOMAIN",
            "UserName": "USER NAME",
            "Password": "PASSWORD"
          },
          "AccessToken": ""
        },
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }
      },
      "Target": {
        "EndpointType": "TfsTeamProjectEndpoint",
        "Collection": "TARGET COLLECTION/ORGANIZATION URL",
        "Project": "TARGET PROJECT",
        "Authentication":{
          "AuthenticationMode": "AccessToken",
         "AccessToken": "GENERATED TOKEN"
        },
        "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }
      },
      "Source2":{
        "EndpointType": "TfsEndpoint", #For Shared "Queries"
        "Collection": "SOURCE COLLECTION/ORGANIZATION URL",
        "Project": "SOURCE PROJECT",
        "Authentication": {
          "AuthenticationMode": "Prompt",
          "NetworkCredentials": {
            "Domain": "YOUR ORG DOMAIN",
            "UserName": "USER NAME",
            "Password": "PASSWORD"
          },
          "AccessToken": ""
        },
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }
      },
      "Target2":{
        "EndpointType": "TfsEndpoint", #For Shared Queries
        "Collection": "TARGET COLLECTION/ORGANIZATION URL",
        "Project": "TARGET PROJECT",
        "Authentication":{
          "AuthenticationMode": "AccessToken",
         "AccessToken": ""
        },
        "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }
      },
      "Target3": {
        "EndpointType": "TfsTeamProjectEndpoint", 
        "Collection": "TARGET COLLECTION/ORGANIZATION URL",
        "Project": "TARGET PROJECT",
        "Authentication":{
          "AuthenticationMode": "AccessToken",
         "AccessToken": ""
        },
        "ReflectedWorkItemIdField": "Microsoft.VSTS.Build.IntegrationBuild", #For Testcases,TestPlans & Test Suites
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }

[sanc001997]

@MrHinsh After test plans, suites migration can we execute the test case using naked agility version 16.0.9 or do we need to execute manually

[MrHinsh]

Please follow the "how-to" in the documentation for migrating Test Cases, Plans & Suits.

[sanc001997]

@MrHinsh I am facing an error like sequence contains more than one element while migrating test plans below are the examples.

suppose I have one test plan name with DEV and inside DEV we have two test suites DEV1 and DEV2
inside same test plan we have PROD inside prod we have two test suites DEV1 and DEV 2

error --

2025-04-04T04:44:48.3934243Z [04:44:47 FTL] [16.0.9] Error while running TfsTestPlansAndSuitesMigrationProcessor
2025-04-04T04:44:48.3934808Z System.InvalidOperationException: Sequence contains more than one element

Please help.

[MrHinsh]

I've never seen this error with Test Suits, only Test Plans.

Can you provide the full log?

[sanc001997]

@MrHinsh Previous issue resolved now .
Can you please let me know like after the test plan and suites migration can we execute the the case through tool or we need to run them manually.

[MrHinsh]

I'm sorry, I don't understand the question.

[sanc001997]

Ok below are the steps.
1- Test case migrated
2- Test Plans and suites migrated.
3-After the both migration can we execute the test cases through tool or only we can execute manually

[MrHinsh]

For 3 that sounds like an Azure DevOps question.

Test Cases are generally for manual testing, unless they have been automated and connected to that automation.

What do you mean by "tool" in this context?

[rjoe66]

I assume if you only want to migrate Test Plans/Suites/Cases, you can skip step 1 "Migrating Basic work items". Correct?

[MrHinsh]

Sure.

[potatojaisiladki]

I am facing the issue while migrating test suites which are orphaned/independent of any test cases. Is this the expected behaviour?

[MrHinsh]

Have you migrted the test cases first?

[potatojaisiladki]

Yes, I've migrated in below order:

1. Migrate Test Cases
2. Migrate test variables and configurations
3. Migrate test plans & test suites

In the third step, some of the test suites (nested under test plans) are getting migrated. But the test suites which were removed & rendered orphaned from test plans do not get migrated.

[djbyrd]

How does this field map in step 1 work? The Custom.ReflectedWorkItemId from the source either doesn't exist, would be blank, or may have old data from some previous migration.

          {
            "FieldMapType": "FieldToFieldMap",
            "sourceField": "Custom.ReflectedWorkItemId",
            "targetField": "Microsoft.VSTS.Build.IntegrationBuild",
            "defaultValue": "",
            "ApplyTo": ["*"]
          }

[MrHinsh]

You make a valid point. I need a Target to Target mapp.

[MrHinsh]

K, a cahnge is heading to preview with fieldMapMode as an aditional property with SourceToTargetor TargetToTarget as options.

[djbyrd]

Nice! I can see where TargetToTarget could be very useful. Thank you!