Challenges and Results

Challenges

  1. UiPath Studio had to be upgraded from version 2020 to 2025, an unusual jump of five years at once
  2. It became clear that five years of specification changes would cause a large number of errors and defects requiring remediation
  3. The existing maintenance team could not absorb the sheer volume of fixes, so an intensive short-term development team was needed

Results

  1. Systematically remediated robots for 28 business processes and 158 projects one process at a time, making steady progress
  2. Prevented the risk that the accounting operations platform could stop if the upgrade were not carried out, securing business continuity

Before

An unusual upgrade leaping five years at once, just before support ended

The accounting department faced a highly unusual task: upgrading UiPath Studio from version 2020 to 2025 in a single step. RPA development tools are generally upgraded every one to two years. This is because support periods for major development tools are roughly three years, and the normal practice is to upgrade before support ends. The exact circumstances are not clear, but in this case the tools had been operated for five years without an upgrade, and five years of specification changes now had to be absorbed at once.

Upgrading would bring five years of specification changes to the surface all at once as errors and defects. Judging that the existing maintenance team alone could not absorb this enormous volume of remediation work, the client set up a new team for an intensive short-term development project. The team consisted of five people: one manager and four engineers.

Figure: An upgrade leaping three to four times the usual span at once

Redesign

The deliberately redundant structure of 28 business processes and 158 projects

The robots in scope covered 28 business processes and 158 projects. Their role is to bridge two systems used by the accounting department: a request system that receives applications, and a database system that consolidates various data. The robots automate the full flow: reading the content of each application, registering it in the database, and, once registration is complete, going back to the original request system to update its status.

Of the 28 business processes, only six have core base robots. A key feature of the design is that these six base robots can be rolled out to all 28 processes simply by changing parameters for each one. In addition, each process consists of an average of six to eight robots, and the work is divided finely by step, with each robot handling a single task such as “only referring to a system” or “only updating Excel.” Each project averages around 1,000 steps, a scale that reflects a design philosophy balancing this reusability with robustness, so that if an error occurs, the process can be recovered manually from an intermediate checkpoint.

Figure: The structure of 28 business processes and 158 projects

Remediation by business process, and a pace recovered from delays

The project is running as a short, four-month effort. Rather than testing everything at once, the team proceeds systematically, dividing remediation and testing by business process, such as “process 1 this week, process 2 next week.”

For a time, some processes fell behind schedule. The cause was that the actual number of fixes needed was far greater than estimated in advance, and that more latent defects than expected were found that had nothing to do with the upgrade itself and had long gone unnoticed. Recent focused work has brought progress back on schedule, and remediation is moving forward steadily.

Figure: Progress over the four months

After

The value of keeping things running outweighs quantitative results

Upgrade and remediation projects like this are different in nature from “offensive” initiatives that create efficiency by cutting something new. Without the upgrade, the system would eventually stop working, so this is a “defensive” project that has to be done, and one whose quantitative benefits are hard to present in simple terms.

The flip side, however, is that neglecting it could have stopped the very platform that supports accounting operations, which gives the project great significance for business continuity. Systematically remediating a broad set of robots spanning 28 business processes and 158 projects, and protecting the continuity of the operational platform, is the essential value of this project.

If your organization has postponed upgrades for a long time, or is concerned about maintaining and operating a large number of RPA robots over the long term, we hope this case offers useful insights.