Can someone please supply a super simple WIT migration configuration file that actually works with 16.3?

[EdPerminas]

I'm using this tool since forever and its never been more exhausting to try use this for a very simple WIT migration. I know about reflectedworkitemid field, I know about impossibility of moving Test Plans, I don't need fancy regex invocations, I don't care about GIT repos - just simple TFS -> AzureDevOps work item migration.

Ok. Enough crying.

For example, https://devopsmigration.io/docs/get-started/getting-started/ the given basic configuration.json doesn't work. When you put TFS/ADO info, PAT creds, no fancy mapping - tool fails before starting:

[16:04:05 ERR] [16.3.1] Configuration file 'new.json' is not valid against the schema.

Validation errors (deduplicated & filtered):

Likely root cause missing properties (all deduped candidate sets):
Path: MigrationTools.Processors[0]
- missing SourceName, TargetName (freq 18) <--- [[[[[[[Do I need to add extra fields in default config? Why?]]]]]]]]]]

Path: MigrationTools.Processors[0]

• (Ln 31, Pos 7) Required: Required properties are missing from object: ResultFileName, SourceName, TargetName.
• (Ln 31, Pos 7) Required: Required properties are missing from object: SourceName, TargetName.
  Path: MigrationTools.Processors[0].ProcessorType
• (Ln 32, Pos 56) Enum: Value "TfsWorkItemMigrationProcessor" is not defined in enum.

Total unique validation errors after filtering: 3

Why default config simply doesn't work? What it is missing?

[MrHinsh]

Why default config simply doesn't work? What it is missing?

Things change over time, and not all the documentation keeps up.

Would love a PR with that change; otherwise, it will be updated as someone gets around to it.

---

This tool is supported by its contributors and creator with no remuneration.

[johannedin]

@EdPerminas - I just succeeded with a test migration from on prem devops server 2022 using this config... obviously used real secrets etc..

{
  "$schema": "https://devopsmigration.io/schema/configuration.schema.json",
  "Serilog": {
    "MinimumLevel": "Information"
  },
  "MigrationTools": {
    "Version": "16.3",
    "Endpoints": {
      "Source": {
        "EndpointType": "TfsTeamProjectEndpoint",
        "Collection": "https://youronpremserver/yourCollection/",
        "Project": "Yoursourceproject",
        "Authentication": {
          "AuthenticationMode": "Prompt"

        },
        "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        },
        "ProductVersion": "OnPremises"
      },
      "Target": {
        "EndpointType": "TfsTeamProjectEndpoint",
        "Collection": "https://dev.azure.com/yourtargetcollection/",
        "Project": "Your-Project",
        "TfsVersion": "AzureDevOps",
        "Authentication": {
          "AuthenticationMode": "AccessToken",
          "AccessToken": "use your own token here"
        },
        "ReflectedWorkItemIdField": "Microsoft.VSTS.Build.IntegrationBuild",
        "AllowCrossProjectLinking": false,
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        }
      }
    },
    "Processors": [
    {
      "ObjectType": "WorkItemMigrationConfig",
      "ProcessorType": "TfsWorkItemMigrationProcessor",
      "SourceName": "Source",
      "TargetName": "Target",
      "ReplayRevisions": true,
      "UpdateCreatedDate": true,
      "UpdateCreatedBy": true,
      "BuildFieldTable": false,
      "AppendMigrationToolSignatureFooter": false,
      "WIQLQuery": "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = @TeamProject AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan')",
      "Enabled": true,
      "AttachmentMigration": true,
      "AttachmentWorkingPath": "c:\\temp\\WorkItemAttachmentWorkingFolder\\",
      "FixHtmlAttachmentLinks": false,
      "WorkItemCreateRetryLimit": 5,
      "FilterWorkItemsThatAlreadyExistInTarget": true,
      "PauseAfterEachWorkItem": false,
      "CollapseRevisions": false,
	"ResultFileName": "c:\temp\result.txt"
    }
  ],
    "CommonTools": {
    }
  }
}

Quick additional comment - i ran the migration from my "on prem" server logged in as an account with solid permissions in the on prem server. I wasn't prompted for anything - and execution stopped when running right when i would expect to be prompted for something - i simply pressed enter and migration started...

This is as basic as any configuration gets i assume... (this is my first attempt with the tool - so i am about as fresh as you can get to this tool)

[EdPerminas]

@EdPerminas - Hope it works! I tried using AccessToken to access source also - but ran into problems... I think you need to add the user with the access token in source to some admin group in order for it to work (Project Administrators I think). But it worked for me when i changed to Prompt - so I didn't investigate further. The actual error message i got was "The PAT MUST be 'full access' for it to work with the Object Model API"... But I could also have had the problem i had because my test source server only has http setup... But I was just happy to get it to work. Next step is to figure out if I can migrate updates to already migrated items - i think i saw somewhere that that should be possible...

@johannedin - don't want to fork the thread, but as far as I know - as long as the PAT has permissions to edit work items + the creator of the PAT has access to do it - that should be enough. For quick tests I usually go 'god-mode PAT', but that is not best practice.

[EdPerminas]

@EdPerminas - do you have the same process type in your projects? Also - I was lazy when setting up my project and used "ReflectedWorkItemIdField": "Microsoft.VSTS.Build.IntegrationBuild", instead of setting up a custom ReflectedWorkItemIdField.. If you don't have the same process template between your projects, for example Agile in Source and Scrum or Basic in target, i guess the error you are getting is expected...

"Microsoft.VSTS.Build.IntegrationBuild" I saw that :-) and I'm surprised that did not caused you problems. So about the processes - that shouldn't be a problem. FieldtoField mapping is the whole idea to avoid 'syncing' processes. For example, in one Org project can be used with 'Scrum' templates, other org may use 'Agile'. Both cannot be edited, you can only create inherited process from it and then apply it. Thats is the reason to use FieldValueMap and FieldToField mapping.

[MrHinsh]

@johannedin, the processor setup on there is a mess of AI-generated bits that have mashed up multiple

 "Processors": [
    {
      "ObjectType": "WorkItemMigrationConfig",
      "ProcessorType": "TfsWorkItemMigrationProcessor",
      "SourceName": "Source",
      "TargetName": "Target",
      "ReplayRevisions": true,
      "UpdateCreatedDate": true,
      "UpdateCreatedBy": true,
      "BuildFieldTable": false,
      "AppendMigrationToolSignatureFooter": false,
      "WIQLQuery": "SELECT [System.Id] FROM WorkItems WHERE [System.TeamProject] = @TeamProject AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan')",
      "Enabled": true,
      "AttachmentMigration": true,
      "AttachmentWorkingPath": "c:\\temp\\WorkItemAttachmentWorkingFolder\\",
      "FixHtmlAttachmentLinks": false,
      "WorkItemCreateRetryLimit": 5,
      "FilterWorkItemsThatAlreadyExistInTarget": true,
      "PauseAfterEachWorkItem": false,
      "CollapseRevisions": false,
	"ResultFileName": "c:\temp\result.txt"
    }
  ],

Invalid things in there:

• ObjectType (was used many years ago)
• BuildFieldTable (never existed, AI hallucination)
• ReplayRevisions (removed pre version 14)
• UpdateCreatedDate (removed recently)
• UpdateCreatedBy (removed recently)
• AttachmentMigration (removed pre version 14)
• AttachmentWorkingPath (removed pre version 14)
• CollapseRevisions (removed pre version 14)
• ResultFileName (never existed, AI hallucination)

This is all documented on https://devopsmigration.io/docs/reference/processors/tfs-workitem-migration-processor/

[MrHinsh]

[15:39:07 ERR] [16.3.1] Validation of work item types failed.

This is the error that's stopping it. The validation failed. Check out https://devopsmigration.io/docs/reference/tools/work-item-type-validator-tool/

[MrHinsh]

@johannedin - don't want to fork the thread, but as far as I know - as long as the PAT has permissions to edit work items + the creator of the PAT has access to do it - that should be enough. For quick tests I usually go 'god-mode PAT', but that is not best practice.

As per the documentation, the account for both the source and target environments MUST be in the "Project Collection Administraor" group. https://devopsmigration.io/docs/setup/permissions/

[johannedin]

@MrHinsh - I am using a PAT with Full Access in both source and target. But my user was not in Project Collection Admin group on Target. I will test if it makes a difference to add the migration user to that group... Also - I aligned the config with the documentation you pointed me to. Thanks! however, it didn't help with the "not adding new items from source at follow up migrations" problem.

[MrHinsh]

Can you post your full log.

[EdPerminas]

@

@johannedin - don't want to fork the thread, but as far as I know - as long as the PAT has permissions to edit work items + the creator of the PAT has access to do it - that should be enough. For quick tests I usually go 'god-mode PAT', but that is not best practice.

As per the documentation, the account for both the source and target environments MUST be in the "Project Collection Administraor" group. https://devopsmigration.io/docs/setup/permissions/

When migration tool works, it works without giving PCA level of access (which is great!)

[johannedin]

@EdPerminas - yeah - maybe the use of IntegrationBuild is a problem... When i run the migration multiple times, i am not getting any added items from source to target... Not sure if it should be possible to get updated items, but I am at least not gettinga any...

[MrHinsh]

Yes, updates will be pulled across as long as the revision on the source is dated after the target's latest revision.

[johannedin]

@MrHinsh - really appreciate your contributions to the thread. Fantastic! I will setup a new on-prem target server (where i have full control over everything) - and see if i can get updates to work... In my real Target Azure DevOps I have to run through a gauntlet of permissions negotiations to get anywhere :) my test project has only 7 work items, but when i run the migrator it only picks up 5, i assume the five i started with before the first migration...