Team members are not migrated

[tbergstedt]

When using TfsTeamSettingsProcessor to migrate teams, no team members are migrated, and one single administrator is set, namely me (as in the person doing the migration).

[MrHinsh]

There is currently no facility for Team Members to migrate, only the Team with its configuration. This would make an awesome pull request!

[ridhvi]

I second the necessity of this feature

[MrHinsh]

@ridhvi, @tbergstedt how would you like it to work?

We can likely easily do this where the source and target user are the same. But what if they are different?

[tbergstedt]

I have only experimented with scenarios where we migrate to team projects in the same Collection, and therefore can assume that the users are same/available. This is currently the only situation we would be using it. (We have a much more crude "team migrator" with this functionality, and I started trying to merge these two, but had to put that aside).

I think for my part that we - at least for a start - might just skip team members that are not available in the target project, with a log warning. Trying to convert user names using input like those for e.g. work items opens up for a lot of tricky situations.

[ridhvi]

@tbergstedt I like this idea "where the source and target user are the same" and I think this is certainly enough for the migration.
Atleast in my case; i am trying to migrate a project from one organization to another and I know for sure the user id's are going to be the same as both the DevOps orgs have the same Azure AD.

[damayantiazure]

I am facing the same issue. I want to migrate the teams to another new project and want to migrate the team members from source project teams. Also The team iterations are getting migrated(with states & sprint board), but the capacity planning and other details are missing in target project after migration. Any suggestion for both the issues?

[anish2808]

is there an update on this?
Any functionality added to the TfsTeamSettingsProcessorOptions" processor maybe?

[MrHinsh]

We would love a PR from someone to set this up.

Generally, moving between collections/organisation will require a mapping of user accounts as they are often not the same. How would you tackle that?

[anish2808]

For my use case, user accounts are all part of the same AD.
Work items get assigned to the correct person like they were in the source collection/project. So populating team members also should be possible, correct?

[MrHinsh]

Yes, in your case it would be possible.

[MrHinsh]

I have added things that will help us move towards this.

1. TfsUserMappingEnricher - this allows you to create a mapping for the accounts from the source to the target. When enabled, it will stop you if there are any missing and ask for a mapping file.
2. ExportUsersForMapping - This new processor will create the mapping file from your Source and try to map all the users to the target.
3. TfsTeamSettingsEnricher - Moved the Team Settings to an enriched so that it can be added to many processors.

Next step would be to add the ability to copy users to groups (which is what a team is) but we have never touched that part of the system, until the ExportUsersForMapping!

---

Funding for us doing work on this tool is generally through 1) customer funding, or 2) donated free time.

Sponcer a Feature | Hire us directly

[GeorgeB-RIB]

There used to be a way to create the users and teams in the target project using version 13 configuration. What happened to this? Where can I find a full version 16 compatible example? PS: config conversion fails with exception.

{
  "ChangeSetMappingFile": null,
  "Source": {
    "$type": "TfsTeamProjectConfig",
    "Collection": "https://dev.azure.com/orgA/",
    "Project": "projA",
    "ReflectedWorkItemIDFieldName": "Custom.ReflectedWorkItemId",
    "AllowCrossProjectLinking": false,
    "AuthenticationMode": "AccessToken",
    "PersonalAccessToken": "<PAT>",
    "PersonalAccessTokenVariableName": "",
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    }
  },
  "Target": {
    "$type": "TfsTeamProjectConfig",
    "Collection": "https://dev.azure.com/orgB/",
    "Project": "projB",
    "ReflectedWorkItemIDFieldName": "Custom.ReflectedWorkItemId",
    "AllowCrossProjectLinking": false,
    "AuthenticationMode": "AccessToken",
    "PersonalAccessToken": "<PAT>",
    "PersonalAccessTokenVariableName": "",
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    }
  },
  "FieldMaps": [],
  "GitRepoMapping": null,
  "LogLevel": "Information",
  "CommonEnrichersConfig": null,
  "Processors": [
    {
      "$type": "TfsTeamSettingsProcessorOptions",
      "Enabled": true,
      "MigrateTeamSettings": true,
      "UpdateTeamSettings": true,
      "PrefixProjectToNodes": false,
      "Teams": ["*"],
      "ProcessorEnrichers": null,
      "SourceName": "TeamSettingsSource",
      "TargetName": "TeamSettingsTarget"
    }
  ],
  "Version": "13.1",
  "workaroundForQuerySOAPBugEnabled": false,
  "WorkItemTypeDefinition": {
    "sourceWorkItemTypeName": "targetWorkItemTypeName"
  },
  "Endpoints": {
    "InMemoryWorkItemEndpoints": [
      {
        "Name": "Source",
        "EndpointEnrichers": null
      },
      {
        "Name": "Target",
        "EndpointEnrichers": null
      }
    ],
    "TfsTeamSettingsEndpoints": [
      {
        "Name": "TeamSettingsSource",
        "AccessToken": "<PAT>",
        "Query": {
          "Query": "SELECT [System.Id], [System.Tags] FROM WorkItems WHERE [System.TeamProject] = @TeamProject AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan') ORDER BY [System.ChangedDate] desc"
        },
        "Organisation": "https://dev.azure.com/orgA/",
        "Project": "projA",
        "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
        "AuthenticationMode": "AccessToken",
        "AllowCrossProjectLinking": false,
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        },
        "EndpointEnrichers": null
      },
      {
        "Name": "TeamSettingsTarget",
        "AccessToken": "<PAT>",
        "Query": {
          "Query": "SELECT [System.Id], [System.Tags] FROM WorkItems WHERE [System.TeamProject] = @TeamProject AND [System.WorkItemType] NOT IN ('Test Suite', 'Test Plan') ORDER BY [System.ChangedDate] desc"
        },
        "Organisation": "https://dev.azure.com/orgB/",
        "Project": "projB",
        "ReflectedWorkItemIdField": "Custom.ReflectedWorkItemId",
        "AuthenticationMode": "AccessToken",
        "AllowCrossProjectLinking": false,
        "LanguageMaps": {
          "AreaPath": "Area",
          "IterationPath": "Iteration"
        },
        "EndpointEnrichers": null
      }
    ]
  }
}

[MrHinsh]

@GeorgeB-RIB as far as I am aware we have never created users... only teams... which is done automatically when Work Items are migrated or with the TfsTeamSettingsProcessor.

I just ran the upgrade with 16.0.5-Preview.2 with no errors. What exception are you seeing?

FYI: There have been 190+ releases since 13.1!

---

Funding for us doing work on this tool is generally through 1) customer funding, or 2) donated free time.

Sponcer a Feature | Hire us directly

[GeorgeB-RIB]

Apologies MrHinsh. I must have been mistaken. Somehow thought that when I did the previous migration, I used the file from TfsExportUsersForMappingProcessor to export the user mappings and then used that user-mapping.json file with the WorkItemMigrationConfig processer as follows: "UserMappingFilePath": "C:\\Temp\\user-mappings.json"
I must have done that work manually via ADO or PowerShell scripts.
FYI: I was also able to upgrade the configuration using version 16.0.
Thanks for the assistance.