Companies today depend on legacy applications for some of their most business-critical processing. In many cases, those apps still do what they were designed to do quite well. But to retain or expand their value in this age of accelerated innovation, they need to be fully integrated into today’s dominant technological environment, the cloud. That’s why legacy application migration has become a high priority for so many organizations. A recent survey reveals that 48% of companies planned to migrate at least half of their apps to the cloud within the past year.
Yet for many organizations, the ROI they’ll reap from their legacy application migration efforts will fall short of expectations. According to PricewaterhouseCoopers (PwC), “53% of companies have yet to reap substantial value from their cloud investments.” And McKinsey estimates that companies will waste approximately $100 billion on their application migration projects between 2021 and 2024.
Why Legacy Application Migration Falls Short
Why does legacy application migration so often fail to provide the expected benefits? In many cases, it’s because companies believe the quickest and easiest way to modernize their legacy apps is to move them to the cloud as-is, with no substantial changes to an app’s architecture or codebase.
But that methodology, commonly called “lift and shift,” has proven to be fundamentally inadequate for fully leveraging the benefits of the cloud. Yet companies often adopt it as the foundation for their app modernization efforts based on some widespread but fallacious beliefs about the advantages of that approach.
In this article, we want to examine some of the most pernicious lift and shift fallacies that frequently lead companies astray in their efforts to modernize their legacy app portfolios. Let’s start with an issue that’s fundamental to the inadequacy of lift and shift as a company’s primary method for moving apps to the cloud: technical debt.
The Role of Technical Debt
The greatest hindrance to a company fully benefiting from the cloud is the failure to modernize their applications . Monolithic applications carry a large amount of architectural technical debt that make integrating them into the cloud environment a complex, time-consuming, risky, and sometimes nearly impossible undertaking. And that, in turn, can negatively impact a company’s long-term marketplace success. A McKinsey report on technical debt puts it this way:
“Poor management of tech debt hamstrings companies’ ability to compete. The complications created by old and outdated systems can make integrating new products and capabilities prohibitively costly.”
But what, exactly, is technical debt? Here’s a concise yet informative definition:
“Technical debt is the cost incurred when poor design and/or implementation decisions are taken for the sake of moving fast in the short-term instead of a better approach that would take longer but preserve the efficiency, maintainability, and sanity of the codebase.”
By modern design standards, legacy apps are, almost by definition, permeated with “poor design and/or implementation decisions.” For example, such apps are typically structured as monoliths, meaning that the codebase (perhaps millions of lines of code) is a single unit with functional implementations and dependencies interwoven throughout.
Such code can be a nightmare to maintain or upgrade since even small changes can ripple through the codebase in unexpected ways that have the potential to cause the entire app to fail.
Related: Eliminating Technical Debt: Where to Start?
Not only does technical debt make legacy code opaque (hard to understand), brittle (easy to break), and inflexible (hard to update), but it also acts as a drag on innovation. According to the McKinsey technical debt report, CIOs say they’re having to divert 10% to 20% of the budget initially allocated for new product development to dealing with technical debt. On the other hand, McKinsey also found that by effectively managing technical debt, companies can free their engineers to spend up to 50% more of their time on innovation.
The Fallacies of Lift and Shift
Because it involves little if any change to an app’s architecture or code, lift and shift normally moves apps into the cloud faster and with less engineering effort than other legacy application migration approaches. But the substantial benefits companies expect to reap from that accomplishment rarely materialize because those expectations are usually based on fallacious beliefs about the true benefits of simply migrating legacy apps to the cloud.
Let’s look at some of those fallacies.
Fallacy #1: Lift and Shift = Modernization
Companies often migrate their legacy apps to the cloud as a means, they think, of modernizing them. But in reality, simple as-is migration (which is what lift and shift is all about) has very little to do with true modernization. To see why, let’s look at a definition of application modernization from industry analyst David Weldon:
“Application modernization is the process of taking old applications and the platforms they run on and making them ‘new’ again by replacing or updating each with modern features and capabilities that better align with current business needs.”
Lift and shift migration, which by definition transfers apps to the cloud with as little change as possible, does nothing to update them “with modern features and capabilities.” If the app was an opaque, brittle, inflexible monolith in the data center, it remains exactly that, with all the disadvantages and limitations of the monolithic architecture, when lifted and shifted to the cloud. That’s why migration alone has little chance of substantially improving the agility, scalability, and cost-effectiveness of a company’s legacy apps.
True modernization involves refactoring apps from monoliths to a cloud-native microservices architecture. Only then can legacy apps reap the benefits of complete integration into the cloud ecosystem. In contrast, lift and shift migration only defers the real work of modernization to some future time.
Fallacy #2: Lift and Shift Is Faster
It’s true that lift and shift migration is usually the quickest way to get apps into the cloud. But it’s often not the quickest way of making apps productive in the cloud. That’s because cloud management of apps that were never designed for that environment, and that retain all the technical debt and other issues they had in the data center, can be a complex, time-consuming, and costly process.
The ITPro tech news site provides a good example of the kind of post-migration issues that can negate or even reverse the supposed speed advantage of lift and shift:
“Compatibility is the first issue that companies are liable to run into with lift-and-shift; particularly when dealing with legacy applications, there’s a good chance the original code relies on old, outdated software, or defunct libraries. This could make running that app in the cloud difficult, if not impossible, without modification.”
To make matters worse, the complexity and interconnectedness of monolithic codebases can make anticipating potential compatibility or dependency issues prior to migration extremely difficult.
Fallacy #3: Lift and Shift Is Easier
In the past, architects lacked the tools needed for generating the hard data required for building a business case to justify complex modernization projects. This made lift and shift migration appear to be the easiest path toward modernization.
But today’s advanced AI-based application modernization platforms provide comprehensive analysis tools that enable you to present a compelling, data-driven business case demonstrating that from both technical and business perspectives the long-term ROI of true modernization far exceeds that of simple migration.
Fallacy #4: Migration Is Cheaper
Because lift and shift migration avoids the costs associated with upgrading the code or structure of monolithic legacy apps, it seems to be the least expensive alternative. In reality, monoliths are the most expensive architecture to run in the cloud because they can’t take advantage of the elasticity and adaptability of that environment.
Related: Migrating Monolithic Applications to Microservices Architecture
Migrated monolithic apps still require the same CPU, memory, and storage resources they did in the data center, but the costs of providing those resources in the cloud may be even greater than they were on-prem. IBM puts it this way:
An application that’s only partially optimized for the cloud environment may never realize the potential savings of (the) cloud and may actually cost more to run on the cloud in the long run.
IBM also notes that because existing licenses for software running on-site may not be valid for the cloud, “licensing costs and restrictions may make lift and shift migration prohibitively expensive or even legally impossible.”
Fallacy #5: Migration Reduces Your Technical Debt
As we’ve seen, minimizing technical debt is critical for effectively modernizing legacy apps. But when apps are simply migrated to the cloud, they take all their technical debt with them and often pick up more when they arrive. For example, some migrated apps may develop debilitating cloud latency issues that weren’t a factor when the app was running on-site.
So, migration alone does nothing to reduce technical debt, and may even make it worse.
How to Truly Modernize
In a recent technical debt report, KPMG declared that “Getting a handle on it [technical debt] is mission-critical and essential for success in the modern technology-enabled business environment.”
If your company relies on legacy app processing for important aspects of your mission, it’s critical that you prioritize true modernization; that is, not just migrating your essential apps to the cloud, but refactoring them to give them full cloud-native capabilities while simultaneously eliminating or minimizing technical debt.
The first step is to conduct a comprehensive analysis of your legacy app portfolio to determine the amount and type of technical debt each app is carrying. With that data, you can then develop (and justify) a detailed modernization plan.
Here’s where an advanced modernization tool with AI-based application analysis capabilities can significantly streamline the entire process. The vFunction platform can automatically analyze the sources and extent of technical debt in your apps, and provide quantified measures of its negative impact on current operations and your ability to innovate for the future.
If you’d like to move beyond legacy application migration to true legacy app modernization, vFunction can help. Contact us today to see how it works.
