Legacy Application Modernization

Many organizations use applications that perform critical day-to-day operations, but are suboptimal in terms of accessibility and speed of execution, or run on an outdated platform. Fortunately, there are several ways to modernize legacy applications with the use of various framework and technologies, such as Laravel or OutSystems.

What is a legacy application?
Examples of legacy applications
Disadvantages of using legacy apps
Problems caused by outdated apps
Legacy apps & security
Resistance to modernization
Reasons for updating legacy apps
What is technical debt?
Methods for modernizing legacy apps
Legacy apps & cloud migration
Legacy apps & integration
What is refactoring?
Considerations when updating
Get started

What is a legacy application?

A legacy application is usually defined as an old application that still performs critical business functions but needs to be replaced in the short to medium term. Often times, a legacy application was designed for a specific operating system, device or environment that has fallen into disuse, and its continued operation is being threatened by often insurmountable technical limitations.

Since such an application is necessarily the product of older technologies, it may be too slow or too difficult to use. The working method for which it was created may have disappeared. It may be based on an outdated language or piece of software that requires scarce, expensive expertise for maintenance.

It may also be incompatible with modern software, preventing data sharing and system integration. Lastly, it may simply reach the end of its vendor’s maintenance period, leaving it vulnerable to security issues.

Note, however, that while the term “obsolete” evokes a very old application, this isn’t always the case. Sometimes it’s simply an application for which no technical support is provided, or which no longer meets an organization’s evolving needs.

What are some examples of legacy applications?

Legacy applications exist on several types of platforms. For database applications, for example, think of MS Access.

The coming death of Microsoft Access, a piece of database software for small and medium-sized businesses, has been foretold for almost 20 years, including by Microsoft itself. Despite this, the application, which is offered with the MS Office suite, is still going strong, and Microsoft has confirmed that it will continue to provide technical support for it until at least 2025.

Yet it’s considered obsolete by many, as it isn’t a cloud application. However, it can be adapted to modern needs with the addition of web interfaces and the possibility for cloud migration.

SAP is another application headed for obsolescence. Although powerful on its own, it often needs to be supplemented by web and mobile interfaces to get the most out of it. Inversely, internal management classic Lotus Notes, which is almost 30 years old, should be replaced entirely because its architecture is so difficult to adapt to modern realities.

What are the disadvantages of using legacy applications?

As you can probably imagine, by continuing to use legacy applications, your organization may eventually run into various issues.

The least of these issues is a relative slowdown of your operations. Computers are constantly evolving, and execution times keep getting faster accordingly, but you can’t take advantage of this if your applications aren’t compatible with the latest hardware.

There’s also the fact that managing applications that need constant monitoring, rebooting, adapting and so on involves catastrophic costs and maintenance time.

What problems are caused by outdated legacy apps?

For example, in the United States, problems in the 40-year-old unemployment management system have caused payment delays for 13 percent of unemployed workers. The Internal Revenue Service was unable to process the tax returns of five million Americans in time due to an outage. In both cases, the scarcity of COBOL programmers was an obstacle to quick service restoration.

Banking is also vulnerable to this kind of problem—the Royal Bank of Scotland, for instance, has had its connection and payment processing services fail. Its systems still run on IBM mainframes from the 1990s.

Not surprisingly, a study[1] found that keeping legacy applications in banks can consume up to 78% of their IT budget, and 70% of these banks say that those systems are the bottleneck to modernization. Similarly, chief information officers (CIOs) surveyed say that 40 to 60 percent of their time is spent managing legacy applications.

Legacy Apps & Security Issues

Even worse is the issue of vulnerability to hacking.

While it may seem safe to use applications that feel too old and obscure to be hacked, this isn’t always the case. Some of them have stopped receiving security updates, or literally never got any. Generally speaking, the older a system is, the more documented its vulnerabilities are.

For example, in 2015, due to computer vulnerabilities in aging systems, a breach at the National Background Investigations Bureau leaked data about federal employees and their families, as well as details about their security clearances.

More than 22 million people were affected, and we still don’t understand the precise consequences of the leak. Theoretically, hostile nations known for cyberattacks, such as Russia and China, could exploit this data to their advantage, and nothing could really stop them.

So why are companies resisting modernizing their legacy applications?

Challenges resulting from outdated legacy applications

Among other things is the fear of failure. Companies that use legacy applications often do so not by choice, but simply because they’ve developed their operational flow around a specific application. Under those circumstances, any change, however necessary, becomes a direct risk to immediate profitability.

The costs of modernization are often unknown absent a thorough analysis, but can turn out to be astronomical if the documentation is not up to date or the application in question is especially difficult to modernize.

Thus, modernizing enterprise applications hinges on a careful calculation: what are the costs and risks of maintaining the status quo, or of setting change into motion? And how fast should change happen?

Why should legacy applications be updated?

Since these applications, by definition, can no longer be adapted to current standards, you need to find ways to keep them compatible with the rest of your equipment as it continues to evolve.

The kind of “solutions” you may deploy to that end are necessarily temporary and suboptimal, and they increase what’s known as your “technical debt.”

What is technical debt?

Technical debt is the amount of time and money you’ll have to “pay back” eventually when putting off a change you need to make sooner or later. In other words, the longer you let things fall behind, the more work it’ll be to catch up.

In addition to this debt, there are the security risks inherent to outdated applications. A recent application benefits from ongoing technical support that can keep you safe from threats or simply provide support when you need it.

That’s why choosing stability may not pay off in the long run, and you need to rigorously calculate the overall cost of the options available to you. Modernization is inevitable, especially when the cost of it approaches the cost of your technical debt, but you can choose the method and degree of modernization that works for you.

Methods for Modernizing Legacy Apps

Modernizing legacy applications makes them more extensible, efficient and effective, and reduces maintenance costs.

There are essentially three ways to modernize your legacy applications: extension, where you add functionality to meet your new needs; refactoring, where you rebuild a few components for modularity and interoperability; and replacement, where you start from scratch to develop a new application that’s fully adapted to your business needs.

If your application were a house, the extension would be like just adding windows and doors. The interior of your home remains the same, but it can be seen and used in more ways, such as on the web and on mobile devices.

Refactoring is similar to renovation. You rebuild and rearrange some elements to make them more efficient, easier to use, more fashionable, easier to maintain, more welcoming… In short: a refurbishment that doesn’t destroy the original structure.

Replacement, of course, is like building a new home, one that fully meets your needs. The cost of each of these options can vary.

Can legacy applications be migrated to the cloud?

Migrating legacy applications to the cloud

Absolutely. In fact, even the venerable MS Access can be transferred to the cloud. However, you have to make sure that the applications concerned can function properly in that context.

There are several methods available to migrate your data to the cloud:

Rehosting: The entire application is simply copied to the cloud. Since all your data remains unchanged, everything works exactly as before, but is hosted on external servers.

The step-by-step approach: Only the elements you consider essential are migrated to the cloud, and you keep some components in-house.

Refactoring: Involves modifying your application to take full advantage of the benefits the cloud offers.

Not all legacy applications can be easily migrated to the cloud; you’ll need to think carefully about the specifics of yours.

Will it function properly in a multi-server environment? Will the data need to be encrypted? Will your code be able to receive and process the increased number of requests? Your answers to these questions will guide your choice.

Can legacy apps be integrated with newer applications?

Absolutely—it’s actually one of the main objectives of a modernization process.

While legacy applications, by definition, are not designed to interact with newer ones, there are ways to force them to do so, including by adding third-party applications, such as APIs, or through an integration platform as a service (IPaaS).

These solutions allow you to “translate” the different languages of your legacy and newer applications so that they understand each other and interact smoothly.

If you only have a few synchronization interactions to perform, you can also schedule them yourself without using third parties, but this method is harder to apply on a large scale.

What is legacy application refactoring?

Halfway between extension and replacement, refactoring an application involves restructuring and optimizing its source code without changing its basic functionality. This is the preferred solution when you have the option to keep what’s useful and upgrade the rest at your own pace.

For example, the code can be modified to make it more readable, less complex, easier to maintain and develop. Functionalities can be changed to optimize their execution. As with the extension method, no changes are made to the back-end of your application.

To return to the house renovation analogy: walls are redone or knocked down to create a new, optimized way to enjoy the same environment.

Refactoring an application can lead to better speed of execution, reduced costs and maintenance time, simplified addition of new features, and a better user experience.

What factors should be considered when updating legacy applications?

Performance – Does your application currently meet your business needs?

The application must currently meet your needs, and be able to do so in the near future. If it doesn’t, simply modernizing it may not be the best solution compared to outright replacing it. You need to conduct a brief assessment of your needs at this stage.

Compatibility – Is your application reasonably compatible with third-party software?

Modernization usually involves the addition of third-party software to implement new functionality. If your application’s code is too limited, this may not be possible.

Cost – Is the projected cost of modernization worth it?

Several modernization methods exist, from simple rehosting to an almost complete overhaul of your application architecture. You’ll have to perform a cost analysis of each option.

Scalability – Will your application be able to meet increasing demand?

In its modernized form, could your application adequately accommodate the growth you’re hoping for?

Risk – Is there a chance your data could be compromised during the modernization process?

A migration is a transfer of data from your servers to those of a third party. Are you able to manage this type of risk? Of the various modernization methods available, have you determined which one best suits your risk tolerance?

Timeline – Do you have enough time to achieve your plan?

A modernization that only requires rehosting can be performed very quickly compared to a refactoring. The more complex your application and the more elaborate your requirements, the longer the process will take.

And as with any programming exercise, the time required can be much longer than expected. It’s crucial that your needs are defined as precisely as possible at this stage.