Prioritizing Processes in RPA Migration

Frustrated by the high level of technical complexity and aggressively rising prices legacy systems require, more and more businesses are migrating their existing robotic process automation (RPA) estates to next-generation intelligent automation platforms.

Sounds simple enough, but in truth, RPA migrations can be extremely challenging, primarily because RPA platforms specify automated processes differently. As a result, an automation in one RPA tool typically won’t work in another tool, requiring automated processes to be completely rebuilt so they can function in the destination platforms. While historically this needed to be done manually – which was both expensive and labor-intensive – newer, purpose-built technologies capable of handling most of the conversion and mapping work are dramatically reducing the manual effort and extensive timelines for RPA migrations.      

Before making the decision to migrate and selecting a migration solution, though, it is first necessary to recognize when the time has come for RPA migration. Some warning signs organizations should be on the lookout for include the following:

• Are you underwhelmed with the return on investment your automation practice is currently delivering?
• Are automation costs and licensing rising dramatically?
• Are you having difficulty scaling your automation practice across the business?
• Are you relying too heavily on technical resources to develop and deliver automated processes?
• Is your legacy RPA tool too complex (and could you benefit from having business users design and deliver automations with a simplified, intuitive platform)?

If a business finds itself answering one or more of these questions in the affirmative, it is likely worth taking the next step by performing a feasibility study to better understand how much effort would be involved in migrating the current RPA estate to another platform, how much of the current estate is already compatible with the destination tool of choice, and what optimization or retirement opportunities exist which will allow total ownership costs and maintenance/support issues to be reduced in the future.

After doing their due diligence and creating a solid business case for RPA migration, organizations will be in a good position to begin planning strategically for an efficient RPA migration which will limit the amount of time needed for the current and new RPA platforms to run simultaneously while the migration takes place. Obviously, doing so will save money. But just as important, it will enable the organization to thoroughly evaluate its current RPA estate to determine which processes are worth migrating and which are redundant or delivering insufficient returns.

With this information in hand, organizations will be able to define the scope for the automated processes to be migrated – retiring those that are high-cost, redundant, or just poor quality – and determine the waves or sprints of the actual migration. They will also be able to decide in what order those processes that are to be migrated should be transferred to the new destination RPA platform.

There are four key factors organizations need to consider when prioritizing automated processes for migration into the new destination platform.

Business Criticality – Business critical automations are normally the first processes earmarked for early migration. There is an argument to be made, however, for migrating less business-critical processes first in the RPA migration project in order to troubleshoot and stabilize the destination environment and operations. If a business critical automation is running well in the legacy platform with no issues or time-sensitive dependencies, then waiting until the latter stages of the migration to shift it to the new destination simply represents a sound business practice.   

Size and Complexity – Large, complex automations are often more challenging and less predictable to migrate. As a result, many organizations prefer to migrate these automations earlier in the project. By tackling complexity early on, businesses can deal with any issues that arise upfront and ramp up later with simpler automated processes. This approach increases the chances for the overall migration project to remain on track and finish on time and on budget.

Application Quantity and Quality – Based on the assessment done before prioritization is assigned and the migration begins, organizations should know if an automated process interacts with multiple applications, as well as whether those applications are complex or novel – all of which can make the migration less predictable. Migrating these kinds of processes earlier in the project tends to reduce risk and keep the project on schedule.

Degree of Automatic Migration – How much manual coding work and effort will be required depends to a large extent on the degree to which an automation can be automatically migrated. Processes with a high degree of automatic migration are typically relatively simple to migrate to the destination RPA platform. Conversely, a low degree of automatic migration can be less predictable and more challenging. With that in mind, it is a good business practice to complete automated processes with a low degree of automatic migration earlier in the project in order to tackle any potential problems upfront.

Obviously, there is a lot to consider when planning an RPA migration. While that doesn’t seem to have discouraged organizations from migrating their RPA tools – a new report indicates nearly 60% of the 500 senior executives surveyed are considering, in the process of, or have already migrated their RPA estates to new RPA platforms – it should give them pause to consider the need to carefully plan all phases of the migration, from determining whether the time to migrate is now to prioritizing the order in which the processes are to migrate to the new destination platform.