Cloud computing, ML models, big data analytics, automation. To many businesses, these and other “wonders of innovation” have long become an integral part of daily workflows. However, if you are still relying on legacy infrastructure, there’s a good chance these modern technologies are, for the most part, inaccessible to you. Yes, you might be using modern applications. But you can’t unlock their full potential if they are siloed off from your core systems. Luckily, you can bring things together with legacy system integration.
In this article, we’ll show how to do it right based on our team experience integrating legacy data into modern software.
What is legacy system integration?
Legacy system integration is the process of connecting legacy software with modern apps. When it’s done right, the integrated applications complement each other in a way that works for your business, bringing lots of benefits. For example:
- Less manual work. Reentering the same data over and over again inevitably hinders your performance and comes with the risk of human error. When all your critical systems are in sync, you enter the data only once. It makes you faster and much more accurate.
- Better decision-making. Integration of legacy systems with modern solutions allows you to unlock the invaluable data you’ve been collecting for decades, identify patterns in it, and use this knowledge to improve your strategic decisions. For example, you can use your historical CRM data to find more efficient ways to attract new customers and retain the existing ones.
- Access to new technologies and functionalities. Integration is a perfect way to enhance your legacy system with new features and modern technologies without building anything from scratch.
- Minimal learning curve for old employees. Replacing a legacy system with entirely new software always implies that you’ll need to train your staff to use it, which can be challenging, especially if you used the system for your core processes. When you connect a legacy system with modern apps, the process is (in most cases) about bridging together tools your staff knows well.
- Minimal learning curve for new employees. In terms of usability, many legacy systems are not as intuitive as their modern counterparts, and new employees might have a hard time getting a grasp of them. Integration makes your company less reliant on such solutions, which decreases the learning curve for your newcomers and makes their onboarding easier.
Due to these and other benefits, the integration of legacy systems with modern applications can help businesses optimize their core processes and improve the bottom line. But it isn’t a panacea. Like medication, integration is “prescribed” only in particular cases. Let’s find out what these cases are.
Read also: Best legacy software modernization approaches.
When is legacy system integration relevant?
Do you know what the main problem with legacy system integration is? Your old system with all its limitations isn’t going anywhere. And sometimes, the scope of these limitations is so huge that a complete system overhaul is the only way out. So, before embarking on your integration journey, you’ll have to conduct a thorough audit of your system.
At Acropolium, we recommend considering integration in particular cases, such as:
- Your system houses large volumes of critical legacy data, and its migration might cost you a lot more than dealing with the drawbacks of old software. At the same time, integration with a newer system would allow you to unlock the full value of this data.
- Your system has unique functions that are critical to your business continuity. It still brings value to your company and seamlessly performs the tasks it was designed for.
- You are planning to merge with another company, and you can’t just migrate to a newer solution because of at least one of the reasons listed above.
- Your system performs seamlessly, and/or it has large amounts of valuable data, but you are looking to expand it with a couple of new features.
- Your system performs seamlessly and/or has large amounts of valuable data, but it needs a more intuitive interface.
- Your system performs seamlessly, and/or has large amounts of valuable data, but you need to share its data with other systems for compliance.
Now that you know about some of the common cases for legacy system integration, let’s explore the main challenges the process implies.
What are the key challenges of legacy system integration?
At first glance, it seems like it should be easy to integrate legacy software with modern IT infrastructure, especially when compared to modernizing such a system or, even worse, building a new one from scratch.
However, if we take a closer look at the nuances of legacy system integration, we’ll see that it’s not smooth sailing at all. In fact, 44% of financial service companies consider the difficulty to connect new technologies to existing IT structures the main barrier to successful digital transformation (as Accenture’s research reveals).
Let’s face it: legacy system integration is a herculean task. And here are some reasons why:
- The lack of expertise. Legacy systems integration will require people that specialize in obsolete technologies. And if you don’t have such experts in-house, you’re out of luck. For example, many colleges stopped teaching COBOL—one of the most common legacy coding languages—back in the 1980s. This means that most COBOL experts are retired, and you’ll have a hard time finding them.
- Insufficient documentation. More often than not, legacy applications are poorly documented. This means that if the programmers who built your legacy system are now retired, its underlying logic and decades of patching are shrouded in mystery (or “spaghetti code,” to be more exact). This makes the integration process even more daunting.
- Low quality of data. The legacy data format and structure are too far from modern standards. To perform integration, you’ll need to clean up the mess in your data first and then find the way to give it the “modern look.”
- Resistance to change. Yes, you got it right. Despite the complexity of your legacy system, your employees (who have been working with it for years and know the ins and outs of it) might be unwilling to introduce “the unknown” into their working routine. If this is the case, your task will be to communicate the importance of integration and make the learning curve as painless as possible.
- Security issues. Legacy apps are vulnerable to cyber threats. For example, one survey revealed that 74% of healthcare organizations faced at least one serious cyber incident in 2018; and that about 70% of these organizations had legacy systems in place. The integration will put your legacy system at even greater risk. So, you’ll need to have a robust strategy on how you are going to protect your legacy data during and after integration.
These factors can pose a serious obstacle to connecting your legacy software to newer technologies. However, it doesn’t mean that the “mission” is impossible.
Read also: Complete guide to software reengineering.
How to integrate legacy systems with modern software: main approaches
There’s no one-size-fits-all “recipe” for connecting legacy systems with modern applications. To help you get your head around your options, we’ve cherry-picked the most popular legacy system integration methods, from the most challenging to the most straightforward.
Point-to-point (P2P) integration
Simply put, P2P integration is a way to connect two apps using custom code. Though this method might seem an obvious solution to integrating your legacy systems with modern ones, it’s actually worth the effort only when:
- Your team doesn’t have expertise in other integration methods, and you’re dealing with a single integration
- Your integration will perform a basic action (for example, you want your CRM to update information about a customer every time there’s a respective change in your ERP system)
- You are dealing with two home-grown systems, not third-party ones
- These systems are running on your premises
At the same time, if you need to sync your legacy system with multiple apps, it’s better to look for other ways to put them together. Why?
To operate efficiently, businesses rely on dozens—if not hundreds—of third-party applications that evolve continuously. This means that you’ll need to build multiple integrations and modify them every time an app working in sync with your legacy system issues an update. Given that building just one integration “by hand” is a complex process that can take you months, there’s little chance you’ll be able to keep up with all those changes, let alone scale.
Enterprise service bus (ESB)
If you are looking to connect your legacy system with more than one app, an ESB might be your solution. It’s a centralized software component that integrates multiple applications into a single ecosystem. Basically, an ESB acts as a “translator” that allows different systems to understand each other. It consists of a message queue, message transformers, and applications “plugged” into it.
But how does it work? Let’s consider a hospital administration system comprising several apps that expect information in different formats, such as XML, CSV, JSON, and TXT. Here’s what the information flow in the system looks like if there’s an ESB in place:
1) A physician enters their prescription into the doctor’s app. The app needs to share lab tests that must be performed, dietary restrictions, prescribed medications, and the cost of medical service with lab, dietary, pharmacy, and billing apps, respectively, in a format each application understands.
2) Instead of sharing information directly with each app, it sends all the prescription information to a message queue, and at this point, the responsibility of the doctor’s app ends.
3) Applications that need the prescription details register with the message queue.
4) The message queue checks whether each of the apps is live and “eligible” to receive the information and forwards the requested details to the message transformers (converters).
5) Each piece of the prescription information is converted into the expected format and sent to the receiving app. If any of the apps are down, the ESB saves the requested message and sends it to the receiver as soon as it is available.
Though an ESB seems to offer everything that P2P integration doesn’t, this method has significant limitations. For example, an ESB doesn’t limit the number of message calls and doesn’t offer load balancing, so crashes are not uncommon in busy environments.
Besides this, most ESBs run on-premises and aren’t suited for microservices architectures. Lastly, they are designed more for internal systems than third-party apps and can hold large volumes of data. For these and other reasons, ESBs are considered to be a legacy integration method that rarely works with modern applications.
Application programming interface (API)
An application programming interface is a collection of rules that define how an app should “behave” to access data or a feature of the other app. At its most basic, it’s a “messenger” that accepts requests and returns responses using a language that both systems understand. For example, a hotel management system (App A) needs information from the weather app (App B) to define the optimal room prices for tomorrow. App A reaches out to the API of App B, and if the request is performed according to the protocol, App B returns the requested data to App A.
The same flow applies when one application needs to access the functionality of the other software. So, for instance, whenever App A needs to define suitable hotel room rates based on a variety of factors (including weather), it reaches out to the API of App C for predictive analytics capabilities.
As you can see, App A and App B, as well as App A and App C, never expose all of their data or functionalities to each other—instead, they share only what’s necessary. You could, of course, argue that APIs and ESBs share the same capabilities. However, application programming interfaces outperform the latter in many aspects. For example:
- Using APIs, you can integrate hundreds of applications into a single system without overwhelming it. With an ESB, your ecosystem is much more fragile, allowing you to connect only a limited number of applications.
- Unlike ESBs, APIs fit into the cloud and microservices architectures and are compatible both with internal and third-party apps.
- Most modern applications support API connectivity, so there’s no need to tinker with other integration methods.
- APIs are reusable. This means that you don’t need to design a new API every time you want to expose data or functionalities of your service to a new system.
- Using APIs will allow you to take advantage of the API gateway functionalities, such as monitoring and analytics features to access the performance of your APIs, limiting the number of calls to prevent crashes, allowing authentication to prevent unauthorized access, and more.
- Since you can expose your API to third-party customers, it’s a perfect way to monetize the data or functionalities of your solution.
Currently, an API is the most common method to connect technologies with one another. This means there’s a great chance that all services you want to integrate with your legacy environment support API connectivity and using other integration methods might pose an additional challenge. In some cases, APIs are your only choice: for example, there are countries where banks are required to share data with financial service providers through APIs.
So, if your legacy system offers an API, you are in luck. If it doesn’t, well… things are a bit more complicated. The main caveat is that your legacy application was probably designed before the advent of APIs. Given that, building an API for such a system will be a time-intensive process, requiring considerable financial investments and expertise in both designing robust APIs and working with the technologies this system uses. And don’t forget that this process might involve refactoring your legacy system to make it API-friendly.
Still, the end result will be worth the effort: APIs offer advantages that neither P2P nor ESB integrations do.
Integration platform as a service (iPaaS)
If you don’t have expertise in building APIs for legacy systems from scratch, and if you feel that you are not ready to spend months finding the missing talent to design such solutions, an integration platform as a service (iPaaS) might be your way out.
An iPAAS is a suite of SaaS offerings designed to connect applications with varying integration capabilities. Packed with an array of pre-configured adaptors, connectors, APIs, and even ESBs, it allows businesses to easily build and manage integrations of various types. When it comes to legacy systems integration, an iPaaS offers the following benefits:
- It allows you to implement integrations in a couple of hours with little to no coding
- You don’t even have to bother with maintenance of your integrations—that’s the vendor’s responsibility
- There are iPaaS solutions that can work with legacy programming languages and data formats like X12, EDIFACT, or COBOL, transforming them into formats that modern systems can understand
- In most cases, integration platforms take care of your compliance needs, too, providing you with everything you need to adhere to a variety of standards, such as GDPR, HIPAA, SO2, and beyond
- Integration platforms allow you to integrate applications both over the cloud and on-premises. And best-in-class solutions provide the connection between cloud and on-premises systems
But there’s another side to the coin. And that’s the dependence on the iPaaS provider. For example, it might not provide the connectors or ESBs you need. Or it might not work with the formats your legacy system uses, making it “invisible” to the integration platform. Whatever the reason, you simply won’t be able to enjoy the ease of use offered by an integration platform.
This takes us back to our starting point: the necessity of hand-coding.
As you can see, each legacy integration method requires expertise you might not have in your organization. But how do you find the necessary talent? Let’s unpack this below.
Why Acropolium?
Though integration with modern software is considered to be one of the least challenging ways to breathe life into an old system, it isn’t an easy one. You’ll have to consider everything, from the most suitable integration method (or a combination of methods) to the technologies you should use. Without a well-thought-out strategy, failure is imminent.
But fortunately, you don’t have to fill your head with the intricacies of legacy systems integration. Especially if it’s too far from your area of expertise. We’ll take care of everything. At Acropolium, we’ve been working with legacy systems for years and have numerous successful projects under our belt in healthcare, banking, logistics. A HIPAA-compliant medical app, a hotel chain management system, and automotive company powertrain software are just a few of them.
First of all, we’ll scan your system for bottlenecks (that might hinder successful integration), conduct a thorough audit of your code, and assess all the risks. We’ll listen to your needs, too. After that, we’ll decide on an integration strategy that perfectly suits your case. Eventually, if you ask us to, our team of legacy system experts will implement the integration and maintain it after project completion.
Final thoughts
Legacy system integration is real. Despite “spaghetti code,” poor documentation, and the lack of developers specializing in technologies that are only a bit younger than your grandma, it’s real. What’s more, if you can’t afford modernization or replacement for some reason, integration with modern software is the only way to breathe life into your old tech. And the right strategy is all you need to do it correctly.
At Acropolium, we’ve brought myriads of legacy systems back to life. Just contact us, and we’ll be happy to answer all your questions on the topic.
