This post is currently in a preview version and will be further updated in the near future.
TL:DR
UiPath is based on a code platform provided by Microsoft. This code platform has been evolved by Microsoft and support for older versions will be phased out in the future. This creates the need to migrate existing code projects to a more recent version of the code platform - often referred to as Legacy-to-Windows migration.
Migrations can cause uncertainties that should be planned for from the very beginning. A migration project blueprint can help in planning and executing the resulting migration of code projects from Legacy (old) to Windows (new). Although every migration is different, some issues can be avoided if decisions are made with their consequences in mind.
About the Legacy-to-Windows Migration
The need for Legacy-to-Windows migration is driven by the continuous evolution of the Microsoft .Net platform and the phasing out of support for older versions (legacy, Framework 4.5.X, 4.5.1). The relationship with other parts (e.g. Windows Workflow Foundation) and general issues caused by ongoing developments are other factors that necessitate the migration.
In simple terms, the Legacy-to-Windows migration can be seen as a code conversion. This can be done manually, semi-automated or tool-supported. A Legacy to Windows migration is particularly technically driven. It is not guaranteed that for every part from the left side (migration source) there is a direct counterpart on the right side (migration target). In this case, appropriate variants are to be searched for, which realize a mapping of the same output, behavior or functionality.
A Migration Project Blueprint
The project blueprint for a Legacy-to-Windows Migration presented here proposes several main blocks that can be individually designed. The individual blocks structure the migration plan. The further definitions and implementations of the main blocks realize the individual steps in a migration project. Another typical feature of a migrating project is the need to create a common understanding between the various parties involved. With the use of a project blueprint, a common view can be developed and the joint discussion can be supported.
Overview
The following blocks are proposed as a main structure:
| Block | Intention/Function |
|---|---|
| Registration | Formal initialization of the migration project |
| Inventorisation | Gaining an initial understanding of the migration volume |
| Prototyping | Reaching the first understanding by an initial hands-on trial |
| Formalisation | Defining a migration strategy |
| Packaging | Defining migration sets |
| Processing | Execution of the migration using the migration strategy |
| Finalisation | Formal completion of the migration |
The steps listed above represent an approach that specifically addresses expected uncertainties that may arise during migration. A quick start to gaining practical experience helps to identify technical problems during migration at an early stage. Further planning is thus based on verified findings and can be fulfilled more realistically. Particular importance should be attached to defining the migration strategy. It addresses the individual points of the respective RPA implementation and reconciles other factors such as project planning, technical migration realizations or special quality plans into line.
Registration
With an early registration of the migration project, it becomes necessary to plan it for the long term and to reconcile it with other projects. The urgency of action can be checked and controlled, and the transition to the ported platform version can be strategically prepared.
Examples of typical activities
- Preparation of explaining the need and drivers for the Legacy-to-Windows migration
- Connect project sponsors / stakeholders
- Checking chances and risks given by the migration topic
- Initiate the next steps
Inventorisation
The goal of an initial inventory of the artifacts to be migrated is to get a first overview of the migration volume. The focus here is not on analyzing the artifacts in detail, but on forming a cross-section of the various artifact types. It is also recommended to take a look at the artifacts and automation projects to be implemented in the future, as this can be taken into account later during planning and prioritization.
Examples of typical activities
- listing existing implemented automation projects
- listing upcoming to implement automation projects
- checking for used process pattern and its customizations
- analyzing the usage of own implemented / 3rd Party Artifacts e.g. Packages, Libraries
- cross-checking bug lists / feature request lists
- checking the RPA automated system release plans on system changes
Prototyping
For prototyping, an initial migration package is sent into an initial hands-on trial to run through the migration once and find additional technical blockers early on. This does not ensure that all occurring blockers have been found. But it offers a chance that unexpected blockers had to be handled, which in turn helps to identify further possible technical blockers. The choice of the test migration package can be based on many criteria and is project specific. Furthermore, it is recommended to take a log of the migration/conversion process in such a way that these key figures can be used for later effort estimations and project planning.
Examples of typical activities
- exploring and evaluating the Legacy-to-Windows conversion tool from UiPath Studio
- examine scenarios where with a pre/post migration action a conversion issue can be handled
- find triggers that can be used for detecting unhandled conversion issues e.g. particular code statements
- explore approaches for mass handling e.g. search & replace on XAML base
- define the project’s individual style of specifying a migration mapping
Examples of criteria used for the initial migration package slicing
- dependent artefacts e.g project process pattern + core custom libraries
- important unclear artifacts
- A set of artifacts that allows implementing upcoming automation projects directly on Windows compatibility
- hard/easy to migrate artifact to control the migration progress
Formalisation
A very important building block is the definition of an overall migration strategy. In this migration strategy, different aspects of migration/conversion are defined and brought together in sub-strategies. On the one hand, these are more technical definitions of what e.g. the migration mapping ( mapping set ) looks like for a specific conversion case. On the other hand, organizational-strategic approaches are also defined, such as migration package priorities, rollout/rollback plans, or handling migration blockades, to name a few examples. When defining the migration strategy, the focus should be on keeping the migration/conversion volume as low as possible and not mixing it with other projects or initiatives (e.g. conversion from classic design to modern design). It is also advisable to record the progress of the migration and to constantly check that the targeted timetables are being adhered to.
Examples of typical activities
- Definition of mapping sets for conversion cases
- Compiling migration packages
- Definition of in-scope / out-of-scope parts of the migration/conversion
- Definition of Quality & Test plans
- Specifying a migration result reconciliation procedure
- Specifying a migration workbench and its integration into other development and organizational systems
Examples for migration sub-strategies
- technical migration mapping principles
- go Live milestone buildings
- regulation of other ongoing project parallelizations
- technical block onHold / Continue setting principles
- Migration progress tracking
Packaging
The formation of migration packages is driven on the one hand by the above-mentioned overall migration strategy and on the other hand, is subject to project planning factors. The handling of unknown technical blockers that occur during conversion is firmly anchored in the migration strategy. As a result, the packaging plans must be adjusted during the migration in order to implement the migration progress focused on by the migration strategy. For the formation of migration packages, the result of the inventory block is used and further elaborated in detail.
Processing
In this block, the individual migration packages are processed using the defined migration strategy.
Finalisation
The formal completion of the migration project is determined by the meeting of the requirements of the applied project management. A migration project should be organized in such a way that the flexible reactive handling of expected unknown blockers is specially planned for. However, this should not lead to the undermining of generally set project management guidelines. Evaluations and a formal review of the final results are recommended so that the difference to a never-ending project is also marked.
Conclusion
The further development of the .Net platform leads to the phasing out of support for older versions and necessitates the Legacy-to-Windows migration of UiPath RPA code projects. In a migration, unknown technical problems are to be expected during the conversion. The presented Migration Project Blueprint approach addresses these specific characteristics by foreseeing an early practical experience generation. The individual project characteristics are taken into account in the design and implementation of the individual Building Blocks. At the heart of this approach is the migration strategy, which sets the direction of the migration project and also reconciles contradictory strands of action. In conclusion, there are risks involved in migration. But there are also opportunities to successfully implement the code renewal with positive side effects if the migration strategy is well designed.
Avoidable disturbing factors - an incomplete listing
- Rate code conversion as successful without having executed it once
- No fall back plan / missing backups
- Set up effort estimates and migration planning without first practical experience
- Underestimation of possible migration mapping blockers
- Statements like: “our automation project is quite simple”
- Never-ending project risk due to migration & new/continuing development in one go
- No decoupling of migration and ongoing RPA developments & dependencies on RPA PROD operation
Potential problems and avoidable misjudgments were critically pointed out. Nevertheless, it remains to be said that migration projects can be carried out successfully, especially if problems and technical blockers are anticipated and addressed from the beginning.
About this [InfoSet] - LegacyToWindows Migration series
The [InfoSet] series summarise a topic and offer information resources of different kinds. The topic of legacy-to-Windows migration was chosen for the [InfoSet] series to provide initial help.
References
Questions
For questions on your specific case or migration topic open a new topic and get individual support.
ashokkarale
Yoichi
pikorpa
JenJen
dokumentor
A_Learner
michael.db.1990
Jaeyoung_Jung
Ashutosh.Gupta
Phenyo