Legacy Application Modernization Approaches: What Architects Need to Know

Bob Quillin

February 9, 2022

7 Approaches To Legacy Java Modernization for Architects

The need for new technology to replace legacy software applications isn’t new. Back in 2003, Microsoft did an ad campaign called “evolve.” Television screens had lots of commercials that showed dinosaurs in business suits. These dinosaurs talked about the need to upgrade to the latest version of Microsoft Office. 

Older versions, Microsoft argued, had become dinosaurs. This was especially true since most people ran versions of Office written before the year 2000. Sadly, more than 15 years later, IT departments still struggle with the problem of dinosaur programs. Fortunately, various legacy application modernization approaches provide an alternative to completely starting over.

Of course, most of these approaches depend on moving legacy systems into the cloud. And according to Deloitte, security, and cost are among the biggest reasons for this overall shift. Applications stored in the cloud often benefit from the best available security, especially since cloud computing providers emphasize security. In addition, costs depend on usage rather than the right of access generally. This way, businesses don’t pay for what they don’t use.

Using one of these legacy application modernization approaches helps your business

Here’s the thing: While the Microsoft ads of 2003 were offbeat and even offensive to some, the company was making an important point. For most companies, having modern applications and computer systems fosters efficiency. 

Most of us know what it’s like to swear at our computers because it is running slowly or run out to the tech repair store because it’s malfunctioning. These misadventures waste our time and often cost money we’d rather not spend. At the same time, owning a newer computer and keeping it updated reduces our overall risk.

If your business has custom computer programs that predate modern programming languages, then you face similar problems to the owner of an antique laptop or desktop. There is a good chance that your IT department spends a lot of time fixing these programs because they malfunction.  Worse, you likely need to hire a highly experienced tech professional who understands those old languages, creating a high maintenance cost. Combined with other factors, legacy applications can lead to significant amounts of tech debt over time.

Luckily, modernizing your legacy applications lets the business reduce costs. And, if you choose the best legacy application modernization approach for your tech stack, it’ll make your business more agile overall. With that in mind, let’s look at the options.

Here are 7 legacy system modernization approaches

The best modernization approach should make your systems easier to operate and maintain no matter what kind of business you’re running. At the same time, you’ll want to avoid confusing users or exposing your business to excessive risk. Selecting the right approach should help on both fronts, but each has different strengths and weaknesses.

1. Encapsulate the legacy application

One of the easiest legacy application modernization approaches is encapsulation. With encapsulation, you essentially take the legacy code and break it into pieces. This approach preserves much of the code and all of the data. However, each segment now operates independently and talks to other pieces through an API. By breaking the old, monolithic architecture into pieces, you’ll let the entire system run more efficiently.

At the same time, an encapsulated application is much easier to fix when there are problems. Your employees can often work in unaffected areas of the program. For instance, if the database section works fine but the payment processing won’t operate, employees might still perform other customer service functions. They wouldn’t be able to take payments over the phone, but at least they could solve some customer inquiries.

In addition, encapsulating programs into microservices helps preserve much of the old user experience. It would shorten the employee learning curve and reduce the chances of bugs from unfamiliar functionalities. Plus, the old database information typically doesn’t change, so you don’t risk losing very much if your company is heavily reliant on customer data or something similar. This can be a major advantage.

2. Change the legacy application’s host

Another relatively simple legacy application modernization approach is rehosting. Here, you essentially move the old system into new architecture without changing the overall code. Essentially, you change the place where the application runs. Often, this means migrating your application to the cloud. However, you can move it to shared servers, a private cloud, or a public cloud. The option you choose depends largely on who will use the modernized application.

Where you rehost, the legacy application will depend on different factors. For instance, if your business is a high-security operation, you’ll need a high-security cloud partner or physical server. Examples include AWS, Azure, or Google Cloud or a super modern server.

Of course, this approach has one main weakness: it doesn’t eliminate antique code. This code can still cause problems through bugs and other breakdowns. Likewise, the existing code isn’t as agile as fresh or adapted coding.

3. Change the legacy application’s platform

More complicated is a runtime platform change. Here, you’ll take a newer runtime platform, and insert the old functionality codes. You’ll end up with a mosaic that mixes the old in with the new. From the end user’s perspective, the program operates the same way it was before modernization, so they don’t need to learn much in the way of new features. At the same time, your legacy application will run faster than before and be easier to update or repair.

On the flip side, though, much of the old code remains. That means that, on occasion, you may still need to make changes in those ancient programming languages. The overall applications will be more secure, but much of the tech debt remains even as your program runs on ever-newer operating systems.

4. Refactor your legacy application

Among legacy application modernization approaches, refactoring is one of the more complicated because it fundamentally changes your original code. Basically, what you do here is take the best parts of your code, then remove what doesn’t work for you anymore. For instance, you might have a payment portal that only works with PayPal, but not with Square or other, more modern, options. In this case, you’ll keep the PayPal functionality but also add support for the other options. Or you’ll remove a widget that no longer works so that it doesn’t affect your tech stack anymore.

Here’s the thing with refactoring: because you’re removing the dead wood, you will modernize the system in ways that make it work much better. At the same time, the modernized system will work the same as the old one did, at least on the front end. 

On the other hand, you’re fundamentally altering the code. With this comes the risk that the changes will upset other parts of your tech stack. Refactoring needs to happen very carefully and with consistent compatibility checks. But if it works well, you’ll remove the old tech debt. From there, you can innovate further as needed.

5. Rearchitect your application for better functionality

Beyond refactoring, there’s rearchitecting your legacy application. This legacy application modernization approach essentially takes the best of your old application, then makes it better with new technologies. 

In other words, you change the programming architecture while stopping short of a complete rewrite. Essentially, this is like a full home renovation, where the house is stripped to the rafters and rebuilt inside. What remains is the basic structure. From here, contractors rebuild something that’s better inside and only looks the same on the outside.

Rearchitecting has two disadvantages.  First, you’ll lose much of the old application architecture. If the existing architecture works for your company on the back end, then this could represent a significant loss. In addition, this option might not work very well for companies with complicated databases. Databases are relatively simple software, but it’s easy to “scramble” the data when you change the code. That could be a problem.

Second, if you rearchitect the legacy application, it’ll significantly change the user experience. This can be a good thing in some situations, such as when the system runs slowly, or people find it frustrating to use. But as the saying goes, if something isn’t broken, then don’t fix it. Leaving a practical user experience in place can be quite advantageous.

6. Rebuild the application

Among legacy application modernization approaches, this is the most complicated. Simply put, you’ll scrap everything and rebuild the application from scratch. The new program will have the same function as the old one. 

Often, your IT staff will create the new application to have a similar user experience as the old program. And at the same time, the scope and specifications will be the same. Basically, the entire back end will be new, but the front end won’t be much different. Front-end changes tend to be cosmetic.

By far, the most significant advantage of rebuilding is that there isn’t any old code for your IT department to maintain in the future. Since everything is brand new, it should also run like new and not have compatibility problems with other applications in your stack or with company hardware.

On the other hand, a complete rebuild means that your IT department will need to test your new software for bugs. And after you’ve started using the new tool, bugs will continue to show up for a while. As a rule, this means that you can have operational disruptions while tech support diagnoses and fixes those problems. Sometimes, it can take a bit for everything to be perfect.

7. Replace the old system

Finally, you can replace the old application with a completely new one. While this isn’t a legacy application modernization approach per se, it does move your business out of the obsolete software. 

Unfortunately, this also means you’ll need to migrate all your old data to the new system. And as some of us have learned the hard way, data doesn’t always want to move. Incompatible applications sometimes can’t share data without conversion. You can lose valuable data that might not be easily replaceable in the process.

For most, encapsulation and migration are the answer.

Some legacy application modernization approaches can be performed together. In particular, it’s possible to encapsulate an old, monolithic application into microservices, then migrate these to the cloud. Many companies use this approach because it’s relatively easy to perform and achieves the dual purpose of moving to the cloud while preserving what has worked well for decades.

Another advantage to this holistic approach is that it’s relatively simple, safe, and inexpensive.  Because the programmers won’t significantly alter the underlying code, there’s little risk that you will lose key functions or important customer data. The process preserves the best of your existing tech stack while making it easier to operate and maintain.

At the same time, the encapsulate and migrate approach lets you move to the cloud easily. During the encapsulation process, your staff will write the API and other coding extras to fit well within the cloud. Then, you can operate more securely and use the optimal number of resources in real-time.

Modernization is easy with vFunction

Want an easy way to modernize your legacy applications through encapsulation and migration? You need to check out vFunction. This is a program that, when installed, automatically analyzes your legacy application. Then, it determines which functionalities should be broken down into microservices without your team needing to put sticky notes on the wall. By doing this, the program saves time. Once your team approves the microservices, the program automatically performs the transition and links them via API. Finally, the application helps perform the cloud migration to your service of choice. Ready for the easiest way to modernize your legacy applications? Contact us for a free demonstration.

Bob Quillin

Bob Quillin is the Chief Ecosystem Officer for vFunction, responsible for developer advocacy, marketing, and cloud ecosystem engagement. Bob was previously Vice President of Developer Relations for Oracle Cloud Infrastructure (OCI). Bob joined Oracle as part of the StackEngine acquisition by Oracle in December 2015, where he was co-founder and CEO. StackEngine was an early cloud native pioneer with a platform for developers and devops teams to build, orchestrate, and scale enterprise-grade container apps. Bob is a serial entrepreneur and was previously CEO of Austin-based cloud monitoring SaaS startup CopperEgg (acquired by IDERA in 2013) and held executive and startup leadership roles at Hyper9, nLayers, EMC, and VMware.

Get started with vFunction

See how vFunction can accelerate engineering velocity and increase application resiliency and scalability at your organization.