Rehost or Refactor: Modernizing Legacy Applications
Nothing happens in a vacuum. No one wakes up one morning and decides to embark on a digital transformation strategy because it’s nice to have newer technology. No: There are very real business drivers that lead companies and institutions to make this journey. All of these business drivers can be categorized as relating to either reducing cost or reducing risk (and sometimes both).
Here are some examples of cost drivers that businesses face:
- Becoming more efficient (operational and development)
- Managing IT budget cuts
- Controlling rising hardware and software costs
- Reducing the need for expensive skills
Here are some examples of risk drivers that businesses face:
- Protecting valuable assets
- Reducing technical debt
- Implementing new business functions faster
- Finding larger talent pools
- Improving availability
What makes these drivers difficult to manage is that there are usually several that you must balance, and they often seem to conflict. For example, reducing technical debt to be more agile (reducing risk) can often increase costs in the short term. The challenge is for businesses to find the right approach to balance these drivers for their specific environment.
Legacy Modernization Styles
As businesses embark upon their digital transformation journey, they find there are many decisions that must be made on which legacy environments get modernized and what the best modernization method is. Unfortunately, there is no one-size-fits-all answer to those questions.
Legacy modernization is one of the most often used terms in digital transformation, but it has several different meanings that often conflict and become confusing. Simply stated, legacy modernization is the process of modifying existing applications to exploit newer technology. “Newer technology” can be exploited in many ways, including conversions in one or more of the following areas:
- Modern languages or databases
- Modern development processes such as DevOps
- Modern deployment such as containers
- Modern architectures such as microservices
- Modern environments such as public or private cloud
Not only are there many ways in which new technology can be exploited, but there are also many approaches to modernization. The common view is that you choose one of the following approaches from Figure 1 for each application in your portfolio.
| Approach | Brief Description |
| Rehost | Move the existing application to an emulated environment off the mainframe |
| Refactor | Convert the existing application to newer languages and databases |
| Rewrite | Develop the application from scratch using the existing business knowledge |
| Replace | Migrate to a commercial off-the-shelf (COTS) package |
| Retire | Remove the application and possibly archive the data |
| Retain | Sometimes called “do nothing,” it can also mean modernize on the mainframe. |
Figure 1. Application modernization approaches
Rewriting an application can be very expensive and filled with risks that you may not get all the business logic duplicated, but if you are successful in the long run, retiring the technical debt may give you more supportable applications that are more agile. Replacing applications with a commercial off-the-shelf alternative is often more expensive and takes longer to implement, which increases your short-term risk as well.
As with any critical digital transformation decision, you must weigh the cost and risks to arrive at an acceptable approach. Rehosting or refactoring can often represent the best balance between cost and risk when a company desires to migrate off the mainframe. Both approaches help you preserve the business logic you have accumulated over many years without the risk of trying to manually duplicate it.
We’ll focus on the first two and the several variations of each to help inform your decision-making.
Rehosting
Rehosting can be thought of as moving the applications and databases off the existing platform and onto a newer environment, such as the cloud, without making substantial changes. Sometimes we refer to rehosting as “lift-and-shift” because the amount of change to the application and database is minimized by using a software emulation layer in the new environment. There are hardware emulation options, but these are becoming scarcer due to intellectual property challenges in courts.
The software emulation layer mimics the mainframe OS and several subsystems. While this sounds like a simple way to reduce the risk of requiring changes to the code, it still requires the code to be updated to use emulator interfaces instead of the original. In addition, the code continues to be maintained and updated in the legacy language. If you are struggling with getting legacy language skills, this is probably not your best option.
If you have legacy applications that are rarely, if ever, changed, rehosting can be a suitable option for migrating those applications off the mainframe. Be aware, however, that software emulation is not free, and you will be paying extra for that layer even if running it in the cloud.
Refactoring
Refactoring comes in several variations, but what they all have in common is that the legacy code is converted to a modern language such as Java or C#. How and when the conversion is done is what differentiates various refactoring options.
Transcoding
Conversion to the new language is typically done through automated tools. Tools that are highly automated typically perform a line-by-line conversion from legacy to modern languages called transcoding. While this can be less labor intensive on the front-end conversion, the resulting modern language code is usually very difficult to maintain since it does not look like well-written Java or C#. It is often termed “JOBOL” because it is structured procedurally like COBOL but uses Java syntax. COBOL programmers don’t understand the Java syntax and Java programmers don’t like the COBOL structure.
Translating
A variation of this line-by-line transcoding is one that is done through a just-in-time translator and re-performed whenever the code changes. Like rehosting but unlike transcoding, the code is maintained in the legacy language. The executable is created from the translated code, making it difficult to debug should problems arise. Mapping from the executable back to the original legacy code is a challenge. Some vendors provide tools to help make this a little easier.
Structured refactoring
This variation is not as highly automated as the first two, but still achieves automation in the 70-80% range. Instead of line-by-line conversion, this option uses intelligent token-based parsing to understand the legacy code and convert it to a well-structured object-oriented modern language. The manual activity in this style is reviewing the new code to make sure the conversions were properly applied and making minor adjustments. Java and C# programmers can easily understand the source code and start making changes more rapidly.
Should I Rehost or Refactor?
A common question for companies deciding to migrate applications off the mainframe into the cloud is: Should I rehost or refactor? Rehosting has traditionally been more popular for two reasons:
- Reduced risk. Moving to an emulator does not require converting all of the legacy code to a new language. Many companies went this route as the first step in their digital transformation strategy.
- Automated tool maturity. The development of tooling to perform automated conversion tooling has lagged the emulation support. That has changed as more vendors are touting the ability to perform the various styles of refactoring and the technology has matured.
Cloud providers often recommend rehosting to get you off the mainframe and into their infrastructure more quickly and then do the refactoring over time. However, rehosting is not much faster or cheaper than refactoring, and you are still left with legacy languages to support.
Structured refactoring has been gaining in popularity because it gets you to well-structured modern languages more quickly and with lower costs than a two-step process of rehosting and then refactoring over time. It also has advantages over transcoding and translating since it is easier to maintain and enhance with new business functions. As structured refactoring matures, the amount of automation should increase and that should lower the time and cost for legacy modernization projects.