Three Strategies for Dealing with Legacy Applications: Rip & Replace vs. Lift & Shift vs. Move & Improve

19 November 2019

LzLabs recently sponsored a survey of 650 of the world's largest organizations. The selected organizations have significant applications still running on mainframes. In this survey 94% of the respondents said they were considering modernization of these applications in some way.

Most organizations consider three key strategies, which have emerged over the past few years, to support such modernization. These strategies are known, rather colloquially, as Rip & Replace, Lift & Shift and Move & Improve. This article expands on the differences between the strategies and their likelihood of success. It goes on to explain why organizations could undertake any combination of these approaches, if they choose the correct future platform on which to modernize their legacy application portfolio.

All three strategies have a similar objective: the business requirements, currently sustained by legacy applications, are to be implemented in a modern computing model that supports the highest availability of staff, lower running costs, and the maximum support for agile future development and exploitation.

Rip & Replace

Rewriting a legacy application using modern languages, methods and infrastructure is a compelling intellectual proposition. This model is referred to by many as Rip & Replace.

Replacing a legacy system, written decades ago, with something entirely new, relevant and modern can be a cathartic release from the problems of legacy maintenance. Using modern development methods and pipelines positions organizations for the digital transformation initiatives almost all of them are undertaking.

But if ever there was a strategy where the ‘devil is in the detail’, then it is Rip & Replace. Legacy applications often support significant and complex business processes. These processes are enshrined within a great deal of legacy application code. It is not uncommon for lines of code to be measured in the millions for applications targeted for Rip & Replace.

It is highly unlikely that any one person, or even group of people can agree how these processes really work. The result is either an extensive and time-consuming discovery process, where the code is analyzed to ensure its behavior is fully understood, or a total abandonment of the existing processes, with a fresh start.

Achieving the former in any timeframe that matters to an organization is extremely challenging. If nothing else, it assumes that valid source-code for these old applications can be found. Perhaps certain fringe elements of the application can be understood, but they will likely remain dependent on a rump of application that cannot be modernized easily, so the likelihood of success is low.

The latter method is equally challenging as it is no longer just a technical exercise. The organization’s associated internal process will need to be changed, assuming that a full understanding of the new process can be agreed upon.

Both methods for Rip & Replace almost always suffer extreme budget overruns before being abandoned altogether.

Except for edge-case or small applications, Rip & Replace as the sole model for legacy modernization is the least likely to succeed.

Lift & Shift

Lift & Shift is probably the most widely implemented legacy modernization approach, largely since it has been around the longest. It works well for certain classes of legacy application, but very quickly runs into significant issues where the applications under consideration are complex and critical; for many of the same reasons as Rip & Replace.

Lift & Shift involves recompiling, and in many cases modifying, application source-code such that it can run on a platform other than a mainframe.

Lift & Shift technologies usually include a compiler and runtime specifically designed to support the unique aspects of mainframe application operation.

The biggest drawback with Lift & Shift is that it requires all the source-code and copybooks for all artefacts in the application to be available, which may include mainframe assembler code written many years ago. Also, depending on the nature of the application, significant source-code modification, and regression testing may be required. LzLabs explores some of these challenges in more detail in the white paper Why Source Code Dependency is a Challenge for Mainframe Workload Rehosting.

Due to the challenges with Lift & Shift, most of the successful implementations have been for non-core systems; small mainframe environments; recently developed mainframe applications or testing environments.

Move & Improve

Move & Improve is the most recently introduced model. It has the potential to be the most all-embracing as it solves many of the problems associated with Lift & Shift and Rip & Replace, but can be used well in conjunction with both of them.

Move & Improve requires a binary-compatible runtime environment (essentially a mainframe VM) on the target Linux computer that enables mainframe applications to run without changes or recompilation. These runtime environments are often referred to as a Software Defined Mainframe, and LzLabs has developed such a technology.

Move & Improve is based on two fundamental ideas:

  1. It is easier and less risky, to incrementally improve upon an existing, working solution, than abandon it entirely, for some new ground-up implementation.
  2. Incremental improvements are far easier to achieve within a modern, Linux-based environment.

The binary-compatible runtime environment enables the entire application to be moved to the Linux environment without any of the challenges associated with Lift & Shift; i.e. the Move part of the strategy. Once here, all the development tooling that has emerged in recent years can be pressed into action to ensure that the incremental improvement happens at the same speed as other non-mainframe applications; the Improve element.

LzLabs has developed compilers, optimized for Linux and cloud implementations, that operate naturally within a modern development pipeline. The LzLabs runtime environment ensures perfect and seamless interoperability between any modernized program, and those dependent programs not yet requiring modernization.

As such, organizations who are considering Rip & Replace or Lift & Shift approaches, can achieve the combined benefits of both as part of a Move & Improve strategy. Applications can run just as they did before; only now on modern cloud architectures where they can be updated or transformed to new languages progressively, without compromising the integrity of the wider system.

As Gartner recently stated in its research note, Use Continuous Modernization to Build Digital Platforms From Legacy Applications, organizations should seek to “transform your legacy application into a platform by identifying, prioritizing and removing obstacles for digital business one by one.”

This capability is at the core of a Move & Improve approach. Legacy applications can now be progressively and incrementally improved to meet the need of today’s digital business - once they have been moved into a modern Linux environment.




White Paper

LzLabs Mainframe Modernization Survey 2019

LzLabs Mainframe Modernization Survey 2019The future of mainframe applications remains a concern for IT leaders. Skilled application owners continue to retire and take knowledge of crucial business processes with them. Companies seek greater application agility and cloud elasticity to help support more efficient digital processes and remain competitive. Can they achieve this on the mainframe?

Download the 2019 LzLabs Mainframe Modernization Survey to discover why IT leaders feel that:

  • 3 years is the average time until retiring staff will significantly impact organizations’ mainframe workforce.
  • 63% say mainframe staff retirement presents a major risk to their business.
  • 69% believe the inflexibility of their mainframe applications limits innovation.
  • 52% say migrating off the mainframe means better cloud elasticity and/or increased development agility.
  • 91% of IT leaders say their organization has moved, or plans to move, to a containerized testing model in the next 5 years.

Download the White Paper

Popular Articles

Related Topics