Robotic Process Automation: Leveraging a New Tool to Transition Legacy Systems

As part of Solutions Review’s Premium Content Series—a collection of contributed columns written by industry experts in maturing software categories—Stephen Elliott, the SVP of IT Innovation and Decision Optimization at Sedgwick, explains how robotic process automation technologies can help companies transition away from their legacy systems.

The pace of change is increasing. In the world of technology and business, the applications you build today will be outdated tomorrow. CIOs are constantly talking about “legacy systems,” transformation, migration, and data conversions to move us from yesterday’s technology to today’s. 

An entire industry has grown to help address the challenges of integrating legacy systems into new applications. Sometimes these integrations are temporary, and the old systems are decommissioned; sometimes, these integrations become semi-permanent, constantly needing additional functionality, changed data models, or new environments. In either case, new systems rarely replace old systems with 100 percent functionality on Day 1. The need to be able to “reach into” legacy systems and extract critical data for use in new system functions is straightforward. 

APIs, backend programming, and custom development are often the first solutions discussed to transition to newer systems. However, robotic process automation (RPA) also represents tools companies can leverage to reuse legacy assets. In many ways, it is simpler to implement, avoids the need for specific legacy technology skills, and can be more flexible in the initial deployment and how it needs to change over the life of the new products. 

An excellent way to compare APIs with RPA is through a modern discussion around artificial intelligence (AI). With growing AI capabilities, we have often faced a decision:  computer or person? Which is better? It is increasingly clear that the answer is “both” or “it depends.” When faced with known, well-defined, and static calculations or actions, computers perform much faster and more accurately than people. However, people are more flexible, adaptable, and able to deal with new situations or changes. APIs represent the highly scalable, well-defined quick-calculation ability of computers. RPA represents a more “human” and flexible approach to complex cases that is often easier to implement in stages. 

Given these different solutions, what are the clear strengths of using RPA when transitioning to newer systems, and when should it be used? 

Where Are All the COBOL Programmers? 

Often the most significant sticking point in legacy system migrations is the availability (or lack of) of human resources with the technical skills to modify or create APIs on the legacy systems. It could be a rare skill set, or it could be that the teams supporting those applications are overbooked and unable to design and implement APIs in a timely fashion. 

RPA does not rely upon legacy programming skills, access to the code, or detailed knowledge of the backend system. RPA behaves as an end-user of the system. If a person can log in to the system and perform the tasks we need (e.g., look up a file, run a report, extract data), then RPA can use that same system interface to perform those tasks. 

Legacy systems are also often vendor owned and maintained. This means less control over changes than dealing with a custom-developed application. A vendor modifying an older, less supported system can be extremely costly. Knowledge to build an API on a vendor’s system may be unavailable or even prevented via contractual obligations. Large, complex ERP systems may offer several integration points, but the risk remains that the customizations performed or the integrations required do not currently exist.   

In contrast, RPA (robot) access (via screens) is often not restricted. This allows you to “wrap” new functionality around these legacy systems, providing a level of automation and access that otherwise would require manual data entry. This functionality can often be implemented using RPA skill sets that are much easier to learn and use than legacy programming languages. For backend API integrations, skilled, rare, and expensive application developers are required. While logic and analytical skills are extremely valuable to leverage RPA solutions successfully, that detailed programming language expertise is not. 

We Need Integration Today 

While each case is unique, the implementation of backend APIs often takes longer to schedule, develop, test, and implement than a similar front-end-driven RPA solution. This assumes that RPA is already in use at a company. If the initial RPA setup has been completed, trained resources, licensed robots, and application environments are already configured and able to be leveraged with new automation. This creates an environment where automation of legacy system functionality can be added and expanded incrementally over time, providing quick value early in a system transition and becoming more robust as required. 

The best solution may be a well-defined and highly scalable backend API. Still, RPA can be implemented now to bridge the gap and allow development teams time to schedule and execute a longer-term solution. RPA might not be the solution, but it is often the now solution. 

We Need Integration Everywhere 

The more legacy systems involved in the transition, the more complex the above factors can become. Instead of programmers for a single system, we might need programmers from several different methods and technologies. Instead of a single primary API function, we might need dozens, each with access to another system or additional components within a system. 

RPA, acting as an end-user, can interact with multiple systems without much additional complexity or challenge. RPA access across three or more systems is often a little more complex than setting it up for a single application. It is in these varied environments that RPA starts to shine. RPA can log in to multiple systems, scrape data, enter it into additional applications, and even access external vendor systems that backend programming cannot access. If a person can do it, you often have an RPA solution. 

Security for Users is Known and Trusted 

An often overlooked but significant advantage of RPA is that it leverages front-end applications and acts precisely as a system user would. This helps with validations, controls, and security being baked into your automations without requiring detailed system knowledge or coding. 

Legacy applications can be highly complicated. They have often been coded, implemented, and modified for years in a complex—but not necessarily well-documented—manner. Attempting to replicate proper validations required for system data entry, extraction, conversion, or use can be daunting. However, those applications already have validations and usage controls built into their screens and interfaces. Using those same features, all the benefits of those years of customizations can be instantly obtained with RPA. 

Additionally, no system changes occur in today’s environment that don’t fall under intense scrutiny from security. What data is being accessed? What methods are used? Can you access data using the API you otherwise would not have access to? How do we validate that no new security risks are being introduced?   

These questions are quickly answered with an RPA system that uses a user ID with system access that has been vetted and used for years by real people. An RPA robot can be provided a user ID and security profile in the system today, with known restrictions (i.e., limiting it to only the functionality it requires). This makes security teams comfortable with how the data is obtained and used, generally not providing broader system-level access that can be compromised. 

Robotic Process Automation for Everything? 

No one solution is best for all scenarios. While RPA provides many benefits, it also comes with caveats. 

Adaptability to change

While robotic process automation can be modified to handle change quickly, it is also more susceptible to breaking due to changes. If the legacy environment is constantly being revised or subject to application outages or “glitches,” the automation will be similarly impacted. Very dynamic environments may not be the best places to implement RPA. 

High Speed and Volume

Backend APIs can often be scaled to transfer massive amounts of data in small amounts of time. RPA, by contrast, is usually limited to being only slightly faster than a human counterpart would be. While scalable with multiple bots and simultaneous system interactions, its scalability cannot rival backend connectivity. 

Licensing

RPA is not without ongoing costs. This comes in the licensing for robots and, if heavily scaled, the hardware required to run those robots. This should always be a consideration and tends to re-enforce the solutions where RPA is initially used until more cost-effective and efficient solutions can be implemented (or until the legacy application is decommissioned).

Hybrid Solutions 

In addition to the benefits of using RPA to access legacy systems and transition to more modern applications, RPA allows for the direct use of APIs. Suppose APIs exist but do not provide 100 percent coverage for what is needed. In that case, modern RPA can easily access front-end systems and, using data collected, call backend APIs directly in their automations. This combines the best of both worlds.

Robotic process automation helps companies transition from legacy systems and bridge yesterday’s technology with today’s. By being able to be implemented quicker, with fewer technical resources, and using available functionality of legacy applications, RPA can often be a less expensive and more flexible short-term tool than custom development or APIs. It may be that the question is not “Why should I use RPA?” but “Why wouldn’t you?”