Each organization is unique, with specific applications portfolios and reasons to modernize, which means there is no one-size-fits-all solution or strategy. Nevertheless, there are four main groups of solutions to choose from and to adapt to each company’s context.
The selected solution, together with the characteristics of your legacy applications, will determine the project’s duration, cost, and risk. Let’s have a look into each group’s promises and challenges.
This group of solutions is usually the first choice and it consists of implementing new applications either via redevelopment, custom coding, or via the implementation of a package solution.
Although it offers an attractive promise, the number of failed projects from this category in the past thirty years indicates that, in many cases, this strategy makes the modernization process too costly, too risky, and too lengthy.
When to consider this approach:
The rebuild or replace solutions should be considered only when two conditions are fulfilled:
The second choice is to change as little as possible. This can be done either by:
> Discontinuing the use of the application, which in many cases means losing valuable resources
> Staying as close as possible to the current solution through encapsulation
It goes without saying that these are not real solutions if the applications are still critical to the business.
With this group of solutions, legacy applications can be modernized either by redeploying to a distributed architecture without even recompiling (Rehost) or migrating, making minimal changes and recompiling (Replatform), also called a “Lift-and-Shift”.
Nevertheless, these approaches do not offer a long-term solution: the legacy technologies remain the same: at the end of the project COBOL remains COBOL, and JCL will still be JCL. With a whole generation of architects, DBA’s, developers and operators that master the legacy technologies about to retire, this is not a long-term viable solution for organizations looking for a future-proof approach.
When to consider this group of solutions:
The fourth possibility consists in moving the legacy artefacts (e.g. sources, data) natively to the new environment. Mainframe refactoring overcomes all legacy issues and can even be executed in a two-phase process where the fully automated mainframe refactoring is followed by an additional modernization phase that can target full object-oriented refactoring or rearchitecting.
Without any extra costs, this process solves the skills issue, allows for continuous new functionality, and offers full flexibility and native support for desired modern enhancements, in the cloud if desired.
You want to consider this group of solutions if:
"There are a number of vendors out there with great technologies, great solutions, and good references, and luckily mainframe users start to find them and embrace the Refresh approaches, which in most cases solve all their challenges with minimum cost and effort." - Mario Mees, Managing Director Astadia
Meanwhile, get a copy of our Mainframe Migration Playbook for Successful Transformation Projects to explore the most common questions about legacy application modernization.
When organizations consider the case for large application modernization initiatives, presenting both pros and cons of the exercise in money can help attract the attention of decision-makers.
Migrating COBOL to Java creates an opening for innovation that simply doesn’t exist with legacy platforms. Here's how to make the transition.
For nearly a decade, IBM’s z14 family of mainframes have served as a reliable IT workhorse for numerous enterprises. But like all good things, the z14 will eventually come to an end.
Get in touch with our experts and find out how Astadia's range of tools and experience can support your team.contact us now