How to migrate from German to the English version

[ghost]

Long time ago we made a bad decision to install the German version of the TFS Server. We upgraded to every new version of the TFS and now Azure DevOps Server 2020, but had no chance to change the language. Now we want to migrate to VSTS, but therefore we need an English version. As far as i know, MS supports only a migration of English DevOps Server to VSTS. Finding this tool and reading the line "v9.0 - Added support for migration between other language versions of Azure DevOps. Developed for German -> English", we hope to have a solution for our problem. Searching the docs, I could not find any hints how to do, even start with it.
Is there any documentation how to do this?

Regards Bernhard

[MrHinsh]

You can map the different language used for Area and Iteration path to the SOurce and Target to allow you to migrate between lanuages

"Source": {
    "$type": "TfsTeamProjectConfig",
    "Collection": "https://dev.azure.com/nkdagility-preview/",
    "Project": "myProjectName",
    "ReflectedWorkItemIDFieldName": "Custom.ReflectedWorkItemId",
    "AllowCrossProjectLinking": false,
    "PersonalAccessToken": "",
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    }
  },

Use

    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    }

[dabbinavo]

@BernhardVert, we have the same issue and also want to move from our German Azure Devops Server Instance to Azure Devops Services. Were you able to manage the migration? If so, can you post your configuration.json?

[MrHinsh]

Folks, to do a language migration you need to use the language mapping in the Source and Target.

This handles "Area" and "Iterarion" being stored in the local language in the database.

[dabbinavo]

Hi @MrHinsh, thanks for your response!

Unfortunately, i do not yet have a backup of our server on which I can test the configuration/migration.

But there are some questions that came up when preparing the configuration.json.
I know, some of the questions will be answered if I can test the configuration on the server, but I have to wait for our IT administration to setup a playground copy of our production server.

1. How to know the correct german language term for AreaPath and IterationPath? Should I take the translations from the UI of a work item (marked green in the picture)?
   So, in accordance to the picture, the section of the configuraiton.json file would look like this?

{
  "Source": {
    ...
    "LanguageMaps": {
      "AreaPath": "Bereich",
      "IterationPath": "Iteration"
    }
  },
  "Target": {
    ...
    "LanguageMaps": {
      "AreaPath": "Area",
      "IterationPath": "Iteration"
    }
  },
  ...
}

2. Do values of fields need to be translated (marked red in the picture)? If so, is the correct way to go using FieldValueMapConfig?

{
  "FieldMaps": [
    {
      "$type": "FieldValueMapConfig",
      "WorkItemTypeName": "*",
      "sourceField": "System.State",
      "targetField": "System.State",
      "defaultValue": "New",
      "valueMapping": {
        "Neu": "New",
        "Bestätigt": "Approved",
        "Zugesichert": "Commited",
        "Fertig": "Done",
        "Entfernt": "Removed",
        ...
      }
    },
    {
      "$type": "FieldValueMapConfig",
      "WorkItemTypeName": "*",
      "sourceField": "Microsoft.VSTS.Common.Severity",
      "targetField": "Microsoft.VSTS.Common.Severity",
      "defaultValue": "4 - Low",
      "valueMapping": {
        "1 - Kritisch": "1 - Critical",
        "2 - Hoch": "2 - High",
        "3 - Mittel": "3 - Medium",
        "4 - Niedrig: "4 - Low"
      }
    },
    ...
  ]
}

3. Is it needed to also create a translation map for the field names (marked yellow in the picture)? From what I understand, this should not be neccessary, as these are stored language neutral in the database (like System.State, System.ChangedBy, ...)? Or do I have to manually translate all fields, like

{
  "FieldMaps": [
    {
      "$type": "FieldtoFieldMultiMapConfig",
      "WorkItemTypeName": "*",
      "SourceToTargetMappings": {
        "Status": "State",
        "Grund": "Reason",
        "Reproduktionsschritte": "Repro Steps",
        "Schweregrad": "Severity",
        ...
      }
    },
    ...
  ]
}

4. Do the work item types need to be translated (marked blue in the picture)? For example "FEHLER" → "BUG". If so, where to define this in the configuration.json?`

[MrHinsh]

Since our tool never edits the Source I recommend that you run against production. The only impact is the single query that is run at the beginning of the migration to load the data.

1. That looks good yes... also when you run it and it cant find a match it will have the german words in the exception trace... you can always pick stuff out of there.
2. Yes the values of picklists that are in German would need to be mapped: State, and Severity are good examples.
3. Field names do not need to be translated as the underlying "Microsoft.VSTS.Common.Severity" in the German source is mapped to "Microsoft.VSTS.Common.Severity" in the target English without the need.
4. Yes, if you have different work item type names then they would need to be translated

  "WorkItemTypeDefinition": {
    "Fehler": "Bug"
  },

Use the case as it is represented in the templates