RPA Platform Migration: Do’s And Don’ts
While RPA migrations are becoming increasingly commonplace, organizations often have a difficult time determining what automated processes should be moved to their new intelligent automation platform and in what order. Should businesses start with simple automations, enabling them to learn on the fly so they will be better positioned to migrate more complex automated processes easily later in the project? Or is it preferable to tackle the most complex automated processes first, get them out of the way, and then work their way down to the low-hanging fruit?
Before doing anything, companies should start with the basics by doing their due diligence, creating a solid business case for RPA migration, and performing feasibility assessments. With those steps out of the way, they can begin to plan strategically for an efficient RPA migration that will limit the amount of time needed for two RPA platforms to execute parallel runs as the migration takes place. Doing so will save money and provide an opportunity to thoroughly assess the existing RPA estate to determine which processes are generating sufficient business value and, therefore, worth migrating and which should be retired because they are redundant or delivering insufficient returns.
The importance of this assessment phase cannot be overstated. All too often organizations shortcut this step and simply migrate every process to the new RPA platform – a move that is both costly and time-consuming. One company considering an RPA migration, for example, recently found that more than 600 of its automations were high-cost, redundant, or just poor quality. By retiring those processes instead of migrating them, the company saved over $5 million in licensing fees and migration costs, not to mention numerous maintenance headaches in the future.
Once each automation has been assessed, organizations will need to define the scope for the automated processes to be migrated and determine the waves or sprints of the actual migration. This is the point at which prioritization becomes an issue. While every business should take into account the quality and quantity of its own automated processes, there are four simple considerations that can be followed to determine how to prioritize those processes to be migrated to the new destination RPA platform.
- First and foremost, companies should consider business criticality. While those automations that are critical to the business operation are typically among the first processes identified for early migration, it is actually a good practice to migrate those automations during the last phases of the project. Why wait if these processes are so important?
Generally speaking, if a business-critical automation is running well in the legacy RPA environment and not experiencing any costly issues or time-sensitive dependencies (such as license expiries), then waiting until the later stages of the migration project to move this process simply constitutes a sound business decision. Migrating those processes which are not as critically important to the overall business operation early in the project enables organizations to stabilize the destination environment and operations without running into the kinds of issues which could cause unexpected delays or bring the entire migration to an abrupt halt. It also allows companies to keep business-critical processes and key operations up and running longer.
- Next, organizations should consider the size and complexity of the processes to be migrated. Large, complex automations are often prioritized to be migrated earlier in a project because they typically are more challenging to migrate and, therefore, less predictable. By migrating such automations earlier, organizations can significantly reduce the risk of projects experiencing delays. Tackling complexity early on and ramping up later with simpler automated processes also vastly improves the odds for the project to remain on schedule.
- Companies should also take into account the number and nature of applications. If an automated process interacts with numerous applications or if those applications are complex or novel, migration can be extremely complex, making the entire effort much less predictable. With that in mind, organizations may want to migrate these kinds of processes earlier in the project. By doing so, they can substantially reduce the risk inherent in such migrations, keeping the entire project on track and on time.
- Finally, organizations need to gauge the degree to which an automation can be migrated automatically. Automated processes with a low degree of automatic migration are typically more challenging to migrate to the destination RPA platform because significantly more manual coding and effort is required. In the same way that large, complex automations should be migrated earlier in the project, these processes should be prioritized to be completed sooner because they are likely to be more challenging and less predictable.
Clearly, organizations have a lot to consider in planning and implementing any RPA migration project. Beyond assessing current processes to determine which are still delivering sufficient business value and which should be retired to cut costs and unwanted future issues, applying the correct criteria to prioritize when each automation will be migrated is an absolute necessity.
Tony Higgins is the Chief Product Officer at Blueprint Software Systems and is responsible for the vision and evolution of Blueprint’s platform, a powerful solution that helps large enterprises understand their RPA estates and automatically migrate them to intelligent automation platforms quickly and efficiently. Tony has a broad base of software delivery skills and experience ranging from start-ups to global enterprises, and is passionate about building technology that helps organizations optimize their automation practice.
Source: RPA Today
What's Your Reaction?
