Application Modernization – 3 Common Pitfalls to Avoid

Avoid application modernization pitfalls like the old "left and shift" mistake
Moti Rafalin February 26, 2021
First published on DevOps.com – see original article

Application modernization has been a consistent theme for organizations year after year. Businesses today still rely on their legacy applications for a majority of their revenue generation, from mainframes to Java EE. New digital transformation initiatives and mandates have pushed application modernization back to the forefront as a new generation of automation platforms and best practices are helping these organizations avoid the pitfalls of the past and accelerate their journey to cloud native architectures.

Here are the three most common application modernization pitfalls and how to avoid them:

1. Lack of a clear organizational destination

Application modernization journeys need a North Star – a guiding destination that development, infrastructure, and DevOps teams can rally around. In order to establish a clear, unified direction, everyone must share a precise understanding of where it wants to get to. That journey starts by defining a set of business goals you are trying to accomplish (such as cost savings, business agility, resiliency, and/or competitive advantage) that can guide and prioritize the technical decisions.

Next, you need to decide which application modernization technologies, platforms, and infrastructure will help you deliver on those business goals (e.g., Red Hat OpenShift, Kubernetes, Serverless, hybrid or private or public cloud, etc.).  Setting common architectural standards will help avoid disparate future stacks and ensure a common shared platform for microservice architectures. For example, if an application starts with Java WebSphere, should the goal be to move to a modern container framework like Spring Boot or a specific microservice Java framework like Quarkus? To avoid analysis paralysis and internal drag, tangible objectives and targets should be set that prescribe how teams are expected to prioritize, select, and modernize these applications and how their progress should be measured, communicated, and shared.

2. Taking shortcuts – don’t fall for the old ‘lift and shift’

The more one modernizes, the more value one gets from the cloud, but not all modernization efforts are created equal. For example, ‘lift and shift’, putting a monolith into a container, and application refactoring into microservices are all called “modernization.” But only refactoring allows enterprises to realize the true benefits of the cloud that include elasticity, regained engineering velocity and cost savings. Don’t fall into the quick and easy modernization temptation with lift and shift or brute force containerization. You will still have a monolith in the end and simply end up paying more and trading one set of monolithic problems for another.

3. Not bringing everyone along with you – no developer left behind

Modernization is never just about technology. Modernization requires that your team’s processes (e.g., agile practices), structure (vertical domain teams as opposed to horizontal teams – e.g., UI team) and skills must adapt. The organizational culture needs to grow to adopt DevOps and cloud native best practices in order to take advantage of the deep development, build, deployment, and operational benefits that are available. Take the time to train and educate so everyone is brought along. Modernizing legacy applications can bring a whole new set of technologists who are responsible for those applications and the supporting infrastructure into the cloud native world.  This is a win-win for everyone.

In other words, the organization needs to have crystal clear answers to the where (destination), why (path) and how (team) to ensure success and avoid the three most common pitfalls of application modernization.