For many software modernization projects, it’s all about learning to love, lift, and shift. No, wait. It’s all about learning to love lift and shift. The basic idea behind lift and shift is to modernize how an existing application is packaged and deployed. Because it’s not about rewriting the application itself, lift and shift is typically quick to implement.
Modern development environments rely on containers for packaging and deployment. A modern environment also uses a continuous integration / continuous deployment (CI/CD) system that automatically builds, tests, and deploys an application whenever its source code changes.
As an example, consider an application built on J2EE and running as a set of virtual machines. Repackaging the application as a set of containers and deploying them in a platform-as-a-service lets you use tools like Red Hat OpenShift, Kubernetes, and Istio service mesh to manage those containers. Within that architecture, a modular app server like Red Hat JBoss Enterprise Application Server (JBoss EAP) is perfect for container and cloud deployments. In addition, you can set up a CI/CD pipeline so that any future changes to the application are built and deployed automatically. Finally, you can use modern techniques such as canary deployments or blue/green deployments to roll out the changes into production.
Or, let’s say you’ve got a multi-tiered application, with each tier running on a different physical server. With lift and shift, you create a container for each tier. Those containers have the code for the tier (the presentation layer, the business logic, the database, and so forth), configuration information, and the runtime libraries and other dependencies that the code needs. Once the containers are built and configured to work together, you can deploy them to a public, private, or hybrid cloud. As with the previous example, lift and shift lets you take advantage of new technologies by repackaging the application, not by changing it.
Lift and shift gives you access to state-of-the-art technologies when you deploy the application today and when you make changes to the application in the future.
An aside: the selfish perspective
Although moving your enterprise forward is the goal of your team, one of your most important personal responsibilities is keeping your skills current. Whether you’re trying to get ahead in your current job or trying to move ahead to a new one, you want your brain and your resume loaded with the latest technologies.
When you think about modernizing a legacy application, you probably envision long nights going through ancient code, learning the old languages and techniques that keep that legacy application running. With lift and shift, however, you don’t change the code of the app, you change how it’s packaged and deployed. You’ll actually build modern skills as you master containers and CI/CD. So if you’ve been assigned to a lift and shift project, be of good cheer.
(By the way, show that trusty enterprise app some respect. Legacy code is what makes sure your paycheck doesn’t bounce, your flight arrives safely, and that the sun comes up in the morning.)
Other approaches to application modernization
Before we go, we’ll take a quick look at two other approaches to modernization: Augmenting an application with new layers and Rewriting the application.
Augmenting the application, as the name implies, doesn’t involve changing the existing application. Instead, new layers are added on top of legacy code. For example, say you have an accounting system that includes credit card processing. It was developed in the early 2000s and works exactly as designed. If you wanted to use that same functionality in a new application (a mobile app, for example), you could create a layer that sits between the existing app and the new one. The added layer is typically nothing more than an adapter between the two applications, although in some cases the layer has business logic as well. The result of the new layer is that your legacy code effectively becomes part of the new application even though you didn’t make any changes to the legacy code.
Rewriting the application is the most extreme form of software modernization. The goal of rewriting is to create new components that replace and ultimately retire the existing application. This is the most expensive and time-consuming option, and replacing a critical legacy application can be extremely risky. For those reasons it can be difficult to justify this approach. Despite these drawbacks, there are times when rewriting is the best option, particularly if the legacy application is keeping your organization from being competitive. If your legacy application runs on an operating system or a hardware platform that is no longer supported, rewriting is probably your only option. Rewriting doesn’t happen in isolation, however. It is often used as the final phase of modernization after augmentation and/or lift and shift.
Getting started
A great way to get started is with the Red Hat Application Migration Toolkit, a collection of open-source tools that simplify application modernization and migration. It automatically analyzes your code and gives you actionable suggestions for moving your code from a legacy app server to a more modern architecture like JBoss EAP. See An introduction to Red Hat Application Migration Toolkit for an overview.
For more information
At this point, you’re no doubt tingling with excitement and wanting to know more about application modernization. Fortunately, Red Hat has years of experience and lots of resources based on the lessons we’ve learned helping customers move their organizations forward.
If you’d like to read more, the article Making old applications new again delivers an overview of modernization techniques, how they work, and how they’re best applied.
Last updated: May 31, 2024