Legacy Java Applications: Refactor or Discard?

Bob Quillin

March 7, 2022

When it comes to migrating legacy Java applications to the cloud, for the most part, your choices may boil down to just two options: refactor it or discard it entirely. For that, it’s important to understand: what is refactoring in cloud migration?

The ground reality is that many enterprises employ a host of Java applications and have Java developers on board, which Gartner calls the language of the enterprise. These enterprises need to transition these apps to the cloud as part of their digital transformation efforts.

Modernizing your technology infrastructure is no longer a luxury but a necessity for businesses to survive. At the same time, you cannot just kill legacy applications and spend exorbitant amounts of money on new applications and infrastructure. For some enterprises like banks or airlines, it’s not even about money but about the complexity and delicacy of operations and infrastructures.

Whether an application is worth integrating into the cloud comes down to the right judgment and the right options.

So what to do if you inherit a legacy Java app? The first order of business is assessing the feasibility of modernizing the legacy Java application in question.

If the assessment shows that it is worth cloud migration, it’s time to decide how to go about it. There are several ways to integrate such applications into your modern infrastructure, including refactoring, rehosting, re-platforming, or rebuilding.

Java Legacy Application Assessment for Cloud Migration

Before you initialize the process of modernizing a legacy Java application, it’s vital to assess the particular application to measure its suitability for migration. Regardless of the steps, you take for migration, it will cost the enterprise money and time.


What value does the application bring to the enterprise? What impact does it have on day-to-day operations? How integral is it for the overall technology infrastructure of the organization?

These questions help you gauge the value of the legacy application for your enterprise and help you decide whether it’s worth the migration efforts.

Many enterprises can create even more value by modernizing legacy applications into microservices that offer more flexibility than traditional application architectures.


Traditional, monolithic applications lack the flexibility to update and add features rapidly. When it comes to modernizing applications, it’s not just about simply moving an application to the cloud– this also means adding better features to boost functionality and efficiency by extension.

Is the application too complex to decouple and modify the features? If yes, it may be worth looking into other options.


The cost of migrating the Java application should ideally result in long-term cost savings. That’s because modern applications leveraging microservices and containers cost only for the resources they use.

However, the migration costs may be too high for some applications to justify the move. There should be a detailed analysis of migration costs and projections for the future to make the final decision.


Security is undeniably a major concern for any enterprise at this moment, thanks to the growing sophistication in cyber attacks. Does the legacy application match the security infrastructure requirements of your enterprise?

Cloud security is likely much more modern and robust than your legacy application’s security features and arrangements. If the application’s security is not as robust and may leave loopholes for the attackers, it may make sense to abandon it altogether.


Besides security, there may be other risks with both using the legacy application or migrating it to the cloud. Any enterprise considering modernizing a legacy Java application needs to evaluate the pros and cons of both possibilities and go with the one that has fewer risks.

Cloud Migration Options for Java Applications

What are the options for refactoring in cloud migration? Like for any other legacy application within your enterprise, Java legacy applications also have several options for cloud migration. Here’s what you may want to consider:

  • Encapsulation: This process integrates the legacy application with other modern applications and infrastructure via APIs. The application is pretty much the same, except the interface is modernized in line with the overall cloud infrastructure. This approach makes it easier for other applications to work with legacy Java software, but the latter does not truly benefit from the cloud.
  • Rehost: Rehosting an application refers to moving it to a new host, in this case, the cloud. There are no changes in the code or the interface whatsoever. As you can guess, this approach does not always work because the legacy code may not work properly and may even result in problems, from compatibility to bad user experience.
  • Replatform: Replatforming refers to moving a legacy application to a new platform with minimal changes to make it more compatible. The main benefit of this approach is that the migration can be separated by workloads, allowing you to test each workload before moving on to the next. Unlike rehosting, this method can use the cloud’s efficiency to some extent but not fully.
  • Refactor: So, what is refactoring in cloud migration? It is essentially code transformation that preserves application behavior. In other words, it reorganizes and optimizes the existing code of the application without modifying the functions of the code. The application does what it does, but the code at the backend is more modernized. It’s the most cost-effective and rewarding methodology for the cloud migration of legacy applications.
  • Rearchitect: The Rearchitect approach calls for new application architecture as a direct result of incompatibility. This approach goes a little deeper than refactoring because the whole application needs a new architecture. As a result, it’s also time-consuming.
  • Rebuild: Rebuilding legacy applications from scratch is a good option when it’s a proprietary application that the enterprise has spent a lot of resources on. The app is rebuilt with newer technologies and a more modular architecture (namely, microservices). However, it retains most of the same business logic and functionality with fewer additions or modifications as necessary for integration or improvement.
  • Replace: Replacing a legacy application may involve building a new application with a bigger scope and different technology stack or using Software as a Service (SaaS) instead. Many enterprises take this approach to save time and use the best service in the industry in lieu of legacy applications.

Why is Refactoring the Best Option for Moving Legacy Java Apps to the Cloud?

Now, with all the options considered for modernizing your legacy Java applications, refactoring is the most viable option for a variety of reasons.

Options like rehosting or re-platforming come under the “lift and shift” approach. This approach does move the application to the cloud, but it does not fully leverage the many benefits cloud has to offer. That raises the question, why move to the cloud if you’re not going to reap its most promising benefits?

On the other hand, rebuilding or replacing an application can be an incredibly resource-hungry process. Not every enterprise may have the financial flexibility or time to take on a giant project like that.

Refactoring legacy Java applications allows enterprises to make fundamental changes to applications to move them to the cloud and integrate it into the system completely. At the same time, since there are no changes in the functionality or features, the code changes are not overly significant or complicated.

Another reason why you may want to refactor a legacy Java application is that Java is a highly relevant language in the IT world. Cloud technologies use more languages like JavaScript, Python, and PHP, but Java remains the most popular coding language overall.

This means you can still continue to use Java resources in your enterprise while the applications are turned into microservices that are not only more efficient but also help save money.

Steps to Refactoring Legacy Java Applications

You wouldn’t want to throw away all of your Java code because, despite being dated, it’s still useful to your enterprise. Refactoring it to microservices is easy, time-efficient, and lets you integrate the best of your code into the cloud.

Here’s how you can go about it:

Repackage the Application

The first step is to analyze the packaging structure of the legacy Java application code and implement cloud-native packaging practices. This would involve splitting up traditional EAR files into different web application resources (WARs). Each service the application offers should be packaged independently into one container. Each of the WARs changes, which involves refactoring the code. With independent WAR or services, it becomes easier to make granular changes to the code to optimize it. Here’s what you may need to refactor:

  • REST or JMS Services
  • SOAP or EJB Service
  • JSP interface

Refactoring Databases

This is by far the most challenging task in refactoring Java applications as it involves restructuring the very data structures the application is based on. This will depend highly on how the database is structured and the complexity of the relation between different database tables.

Modernize Java Applications Seamlessly with vFunction

What is refactoring in cloud migration, and when should you consider it? Refactoring requires deeper analysis of the existing application architecture and code to determine how best to repackage the application and alter its code without compromising the functionality, reliability, or security of the application.

With vFunction, you can turn monolithic Java applications into modern cloud-native applications with independently managed microservices. It automates the analysis and extracts microservices that can be tested and deployed quickly. The result? Quicker migration to the cloud and seamless integration with other modern apps in your technology infrastructure. Contact vFunction today to learn more.

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.