mrc's Cup of Joe Blog

Join us in exploring the world of modern development, evolving technologies, and the art of future-proof software

5 ways to rejuvenate your legacy applications

EducationMany companies face the same problem: They’re stuck to their legacy enterprise applications and systems. Sure, they’d love to upgrade their outdated system, or replace those legacy applications, but…they can’t.

Why not? Maybe their business relies too heavily on their legacy applications. Maybe past customizations have virtually locked them into their legacy apps. Maybe it’s too risky or expensive. Maybe management doesn’t see the need for modern applications. Whatever the cause, the problem is the same: They’re tied to their legacy applications.

What problems does this cause? Quite a few. While I could explain how it keeps the company from modern features and capabilities and makes them look outdated, those issues are small potatoes compared to the larger business problems caused by legacy applications. For instance, legacy applications:

1. Tie up IT budget: Since legacy applications are more difficult to maintain, they require a good portion of the IT budget. How much? I’ve seen estimations ranging from 70-80%. Think about that. If you’re spending 80% of your budget maintaining the status quo, how can you ever afford modern technology?

2. Keeps IT from innovation: Since legacy applications are more difficult to maintain, they also require much of the IT department’s attention. Of course, if the IT department spends a good chunk of its time maintaining applications, they have little left to spend on business innovation–which, as we explained in this article, is becoming more and more important.

So, what can you do? If you’re stuck with legacy applications that you can’t replace, what are your options?

In this article, let’s explore a few ways to breathe new life into your old applications. If you can’t replace your systems or applications entirely, how can you bring modern features and capabilities to your legacy apps? To help you answer those questions, I’ve outlined some methods to do just that, and touched on the pros and cons of each. Without further ado, here are 5 ways to breathe new life into your applications.

1. Lift and shift

photo credit: idogcow via photopin cc
photo credit: idogcow via photopin cc

Primarily used by those looking to move away from a mainframe environment, the “Lift and Shift” approach involves applying minimal changes to a legacy system, and then moving that system to another platform. This typically requires the use of emulation software to support the legacy system on the new environment.

What does this do for you? This approach reduces the costs and effort of maintaining the mainframe. Essentially, it lets you host your applications on a less expensive platform.

However, it doesn’t add anything to your applications, and could cause further complications. According to a quote from Bill Ulrich, President of TSG, Inc. found in this article: “Simply moving older architectures via lift and shift can be a real dead end because systems leaving the mainframe environment languish under emulation environments.”

2. Purchase bolt-on solutions or third-party software

photo credit: chefranden via photopin cc
photo credit: chefranden via photopin cc

With any well-established enterprise system, you’ll find a variety of bolt-on solutions, or third party software that brings additional features and capabilities to legacy applications. Your available options largely depend on the system or applications you’re running.

What does this do for you? Depending on your options, this approach can deliver modern features to your legacy applications. Also, because you’re using a third-party solution, you avoid the burden of coding these features yourself.

However, integrating these bolt-on packages into your existing system comes with a couple of drawbacks:

1. It further ties you into an old system
With this approach, you’re essentially investing even more time and money into your old technology. You’re spending money purchasing the software, and time integrating it with your current applications and systems. Do you really want to pour more of your precious resources into your legacy applications?

2. It complicates vendor support
Have you ever tried to resolve an issue that involves two or more companies? It’s a nightmare. They blame the problem on the other company, who in turn blames it on the first company…until you’re caught in a never-ending game of “pass the buck.” This is a risk of bolt-on software. When problems arise, the application vendor will blame the bolt-on software vendor, who will blame the application vendor, and so on. Resolving issues becomes more and more complicated with every bolt-on package added to your legacy applications.

3. Manually build new features

This approach requires that you build the necessary features and capabilities into your legacy applications by hand. Ideally, it should produce a result that’s similar to the bolt-on option, only more customized to your business.

What does this do for you? This approach gives you the features you want, custom-built for your specific needs.

However, while custom-built solutions sound nice on the surface, this approach comes with multiple problems:

1. It’s not always possible
Due to limitations found within your legacy applications themselves, certain features cannot possibly be added to some legacy apps. Building modern features into an old foundation isn’t even an option for some companies.

2. It’s expensive
This requires a developer skilled in whatever language your legacy application is built with. Since most companies don’t have the skills or the time to customize their legacy applications, it often requires outside consultants…which drives the cost up.

3. It further ties you to outdated technology
Like the bolt-on option above, this approach increases your overall investment in your legacy applications, and further ties you to old technology. For many businesses, this is seen a step in the wrong direction.

4. Give your existing applications a new face

photo credit: *n3wjack's world in pixels via photopin cc
photo credit: *n3wjack’s world in pixels via photopin cc

Better known as “screen scraping,” this approach scrapes the information off of your legacy applications, and displays it as a graphical, browser-based interface. It makes old applications look new, without actually replacing the application.

What does this do for you? It gives your users a modern-looking application, and lets you integrate some modern features into the scraped application. Since it doesn’t replace the old application, screen-scraping is relatively quick.

However, while speed and and modern interface sounds enticing, this approach creates a couple of problems:

1. It doesn’t change the underlying application
Screen scraping doesn’t free you from the restrictions found in your legacy applications. While adding standard web application features to a screen-scraped application is possible, it requires a fair amount of time and effort. In the end, you’re stuck using a legacy application, that only looks modern.

2. It complicates maintenance
It leaves you maintaining both the legacy and screen-scraped applications, which increases the amount of effort and time required for maintenance. To make matters worse, every change to the underlying legacy application requires re-scraped applications.

5. Extend and surround

This approach involves gradually extending and surrounding your legacy applications with modern web applications. The end result: truly modern applications that still integrate with your existing business logic and rules.

What does this do for you? This combines the best of both worlds. You create a modern web application (built on modern architecture) that integrates with your existing business rules and logic. It lets you call the same code as you were calling with the legacy application, but on modern architecture. This approach lets you slowly extend and surround your legacy applications with modern web apps, eventually replacing them altogether.

I’ll be honest–in my opinion, this is easily the best option. It lets you breathe new life into existing applications while slowly moving towards your goal of new, modern apps. It lets you work at your own pace, completely eliminating the risk of replacing your legacy apps altogether.

However, the challenge arises when you try to approach the “extend and surround” method manually. Building modern, well-architected applications from scratch (that integrate with your existing business logic) is time consuming without the right skills or tools.

If you’d like to read a little more on the topic of improving your legacy applications, and the options available, here’s a white paper you might want to check out: Crash course in modernization. I hope you find it useful.