[InfoSet] - LegacyToWindows Migration # Demo of a prototypical migration

This post is currently in a preview version and will be further updated in the near future.

In this part of the [InfoSet] - LegacyToWindows Migration series, a prototypical legacy-to-Windows migration is demonstrated. For this purpose, a legacy modeling is converted with the automatic converter tool. Afterward, the conversion result will be post-processed in order to get it executable.

Initial scenario

An existing implementation is used for a prototypical code conversion to evaluate the feasibility of the migration and the work steps in practice. Typical for such a scenario is that the modeling was done in the past (2019) and the code conversion is done with a newer UiPath Studio version (2022.10.X).

Implementation in Legacy


  • A text file with JSON text is read in.
  • The text content is used for a JSON deserialization


  • Text is encoded in Windows-1252
  • Deserialisation into a dictionary (Key=string, Value=String)


Prototype Migration Steps


The artifacts / UiPath Studio projects used for the prototypical migration are backed up in such a way that the practical evaluation can be aborted at any time and started from scratch.

Furthermore, it is ensured that the migration result can be transferred to the source code management without mixing with previous versions or productive artifacts.

Conversion pre-processing

In this case, no pre-adjustments or code adjustments are made

Conversion processing

In a first step, the automatic conversion is triggered and care is taken that the result is a new UiPath Studio project. Then the result is further inspected and checked for its executability.

Conversion with the conversion tool

  • Click convert to Windows


  • Ensure that “Create a new project” is activated
  • Edit Name, Location according to the preparations and definitions
  • Click Convert

Conversion Result Inspection



At first glimpse, the result seems to be valid and does not show any warnings. In a more in-depth review, the following is noted:

Legacy Windows Comment
Upgraded to Version 21.10.6 Upgrade due to non-Windows compatible source package version
Upgraded to Version 21.10.9 Upgrade due to non-Windows compatible source package version
Upgraded to Version 1.9.2 Upgrade due to non-Windows compatible source package version
Deserialize JSON activity
offers TypeArgument within the activity properties
is missing reduced advanced property display support by the combination of particular UiPath Studio and Package Version

Execution Test

When debugging the conversion result, the following error occurs:

Error Message

Read Text File: One or more errors occurred. ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name')) ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name')) ('windows-1252' is not a supported encoding name. For information on defining a custom encoding, see the documentation for the Encoding.RegisterProvider method. (Parameter 'name'))

Conversion Result

With UiPath.System.Activities Version Level 2019.10.1
The conversion

  • has not been successful
  • needs follow-up work.

UiPath.System.Activities Version Level 2023.X.Y - PREVIEW
There are several indications that the revised Read Text File Activity will use the customized encoding without having to perform an CodePagesEncodingProvider registration beforehand. The conversion would therefore have been successful.

:warning: Do not perform a careless package update, as this may lead to other problems

Conversion post-processing

The conversion was not successful and needs to be reworked. A first cross-check with the information on code conversion mapping sets offers the chance to find an already known case and to get assistance.

Fix unsupported encoding name

Similar as described here the following fixing will be done:


Fixing Steps:

  • Add an Invoke Method activtiy above the read text file activity
    • TargetType: System.Text.Encoding
    • Method: RegisterProvider
    • Parameter: IN | EncodingProvider | System.Text.CodePagesEncodingProvider.Instance

Result Validation

The revised result of the migration conversion is debugged and tested for executability. A breakpoint at the very bottom of the comment activity will pause the execution and the result can be tested further.

Check fixed runtime exception:

Check Deserialisation Result:


Conversion Result

The conversion has been successful.

Final steps

After the successful completion of the prototypical migration, the result / UiPath Studio project is saved according to the previously defined conventions. This source code should be clearly separated and distinguishable from all subsequent developments.


The following conclusions can be gained from this exemplary migration prototype:

  • The provided automatic conversion tool performs part of the conversion.
  • Pre- and/or post-processing may be necessary.
  • The result of the migration conversion can only be meaningfully evaluated after successful execution, as some problems only occur at runtime.
  • Since solutions/workarounds exist for some conversion mapping problems, these can be dealt with directly in the post-processing and do not require further problem analysis.
  • Strict management of the different partial results of the migration conversion should always be given so that a step back or a step repetition is possible at any time.
  • When converting older artifacts, it should always be ensured that code migration and code renewal do not mix and lead to uncontrollable blockers.

The migration prototype allows for initial practical experience at a controllable scale. This approach provides a way to get familiar with potential problems in conversion mapping.

Side note
In this particular demo case, it would have been possible to update the referenced package UiPath.WebApi.Acitvities to a higher version in a subsequent code renewal. The Deserialize JSON activity would then also offer the TypeArgument again.


Upgraded to UiPath.WebAPI.Acivities V 1.16.2

Due to the strict separation of code migration and code renewal, the various referenced packages were not upgraded to higher versions, and no additional redesigns were made. In other situations, changing package versions can lead to side effects or unresolved activities. Therefore, it is recommended to check this separately and rather limit the scope of a prototypical migration at the beginning


Fortunately, during the development of this prototype migration demo, it was discovered that an expected conversion blocker no longer occurs, as it is now handled by UiPath. Many thanks to @Yoichi for his collaboration in cross-checking this finding.

Also thanks to @Roman-Routinuum for a review and collaboration in pointing out package upgrades by the conversion tool.



For questions on your specific case or migration topic open a new topic and get individual support.