Use Continuous Modernization to Optimize Legacy Applications

10 January 2024
- ID G00772826 - 12 min read
By Stefan Van Der Zijden, Deacon D.K Wan, and 1 more

Legacy applications often impede continuous delivery of value, but rip-

and-replace efforts are costly, risky and time-consuming. Applications and
software engineering leaders should instead use continuous
modernization to minimize the cost, risk and impact of legacy-application
optimization.
Overview
Key Findings
 A rip-and-replace approach to modernizing applications can be
highly disruptive to the organization in terms of cost, risk, time and
impact. These factors often outweigh the potential benefits.
 Legacy applications are not designed to support continuous
delivery, as some components within these applications create
obstacles — or friction points — that negatively impact business
operations.
 Poor coordination between product and modernization teams — and
lack of engagement with business leaders — will undermine
continuous modernization efforts.
Recommendations
To effectively optimize the organizations’ legacy applications, applications
and software engineering leaders should:
 Use continuous modernization as an alternative to rip-and-replace
programs by focusing on specific business obstacles caused by the
legacy application (instead of treating legacy applications as a
problem to eliminate).
 Implement continuous modernization by identifying, prioritizing and
removing the most severe friction points — business capabilities
with poor application support.
 Establish a continuous modernization culture by working with
product and platform teams to create and align a backlog and
cadence for iterative, just-in-time removal of friction points.
Introduction
The digital transformation is still underway. In the 2024 Gartner CIO and
Technology Executive Survey, respondents, on average, said that in 2023,
about 40% of enterprises’ processes have been optimized through digital
means, and about 25% of the enterprise’s total revenue is attributed to
digital products and services.1
Applications and software engineering leaders need to support these
ongoing digital initiatives and must provide continuous delivery of digital
products. Existing legacy enterprise applications create friction points that
negatively impact agility and velocity — and modernization is essential for
digital initiatives. In the 2024 Gartner CIO and Technology Executive
Survey, 47% of the respondents selected “integrate, innovate and
modernize enterprise applications” as a focus for the next 12 months,
making it the third highest priority overall. 1
Modernizing legacy applications using a big-bang or rip-and-replace
approach is often not an option. Organizations are not willing to go
through the cost, risk and impact of these large modernization programs;
nor can the digital initiative wait that long.
How can you minimize the cost, risk and impact of modernizing legacy
applications and enable continuous delivery? Instead of rip-and-replace
efforts, applications and software engineering leaders should use a
continuous modernization approach. Rather than viewing legacy
applications as a problem, you should manage the legacy application
portfolio as an asset, and use it as a springboard to support desired
business capabilities. Your teams should iteratively identify, prioritize and
remove obstacles that impede continuous delivery of value (see Figure 1).
This approach allows legacy systems to become more composable by
replacing a component with more appropriate technology or by
encapsulating, reusing and extending a current function.
Figure 1: Continuous Modernization Minimizes the Cost, Risk and Impact of
Optimizing Legacy Applications

Analysis
Use Continuous Modernization as an Alternative to Rip-and-
Replace Programs
For most organizations, legacy applications are still the center of gravity
within their application portfolio. These applications contain important
data, and they provide valuable functions to digital products and services.
However, these aging, custom and package-based applications impose
obstacles that negatively impact business agility and velocity. Four
common obstacles include:
  They were not designed and built to match the pace of digital
business demand.
 They may contain functions that other, more modern platforms and
technology are now better-suited to deliver.
 They are closed systems. Functions and data are not easily
accessible.
 They are aging. They have deteriorated over time due to
mismanagement. Their business fit, business value and agility have
declined while cost, complexity and technical risk have increased.
That being said, these obstacles do not always require you to discard
legacy applications entirely. In many cases, the 80/20 rule holds true —
20% of the functions and features of an old application are causing 80% of
the pain; and thus, 80% of the application is still fit for purpose.
Think of legacy applications in the same way you would think of an old
car. When it is time to overhaul the car, you look at the individual
components and assess their health and fitness. If the vast majority of its
components are worn out or bad, you have a total loss. But in many
cases, most of its components are good enough. In these cases, you
would be best served to clean, repair or replace the defective components
— thus extending the life of the car and making it a valuable, safe and
comfortable asset to own.
In short, applications and software engineering leaders should view legacy
applications as assets to manage — not merely problems to eliminate.
Applications and software engineering leaders should not ask, “how can
we get rid of these old applications?” They should instead ask, “how can
we optimize applications by addressing technical debt, improving the
business fit or modernizing their platforms?”
A gradual, continuous approach to modernizing legacy applications is
superior to rip-and-replace efforts due to:
 Cost, risk and impact — In many cases, a rip-and-replace
approach for whole systems is too costly, too risky and too time-
consuming. Rip-and-replace efforts have a significant, disruptive
impact that most organizations are unwilling to accept.
 Urgency — Even if you are willing and able to go through a rip-and-
replace approach, it will probably take a year or longer to execute.
Digital business cannot wait that long. It needs support as soon as
possible.
 Uncertainty — It is difficult to predict what kind of services and
data will be required for upcoming digital business initiatives. New
and changing demands will challenge your rip-and-replace project.
There’s another reason why application modernization should be a
continuous process — you are never finished. Applications and software
engineering leaders often conceptualize legacy applications as those old
mainframe applications from the 1970s and 1980s. But when we are done
modernizing those applications, new legacy applications will emerge —
such as client/server applications from the 90s, and early Java and .NET
applications from the 2000s. Technology ages quickly and requirements
change constantly, which creates new legacy applications over time.
Implement Continuous Modernization
Continuous modernization is an iterative approach for identifying,
prioritizing and removing obstacles to digital business from legacy
applications. These obstacles — or friction points — are points at which
the technology platform and development ecosystem are not able to
provide satisfactory support for a business capability or keep up with
demand.
Continuous modernization is a multistep process, split out across three
key stages.
Assess and prioritize
 Step 1 — Identify the business capabilities that are supported by
the legacy application. Assess how business capabilities contribute
to business value streams and customer value. Use value-stream
mapping or business-capability-impact mapping to highlight the
impact of change or opportunities for optimization.
 Step 2 — Identify which components or parts or the legacy
application are supporting each business capability.
 Step 3 — Assess the support for each business capability and
identify any modernization drivers, such as poor business fit, value
or agility, or high complexity, risk or cost. This assessment can be
performed using Gartner’s fitness and value review process (see
How to Assess the Fitness of Your Application Portfolio). In this case,
however, we are assessing support for each business capability and
not the whole of the application.
 Step 4 — Identify and prioritize the friction points with TIME
analysis (see Using TIME for Application and Product Portfolio Triage:
Data From the Field). Discuss these friction points with business
stakeholders to create a backlog of modernization activities.
Transform
 Step 5 — For each selected modernization activity, analyze the
cause behind the problem and select the appropriate modernization
approach to remove the friction point. These approaches include
encapsulating, replatforming, refactoring or replacing application
components.
 Step 6 — Execute the modernization to remove the friction points
or obstacles and improve business support.
Refine and repeat
 Step 7 — Reevaluate the backlog to include any new or changed
priorities.
 Step 8 — Select the next activity from the backlog and go back to
Step 5.
Continuous Modernization Enables Composability to Improve
Business Support
Composability is a design approach that enables systems (for example, IT
systems, organizations and products) to adapt quickly to changes while
staying resilient. At the heart of composability is modularity. Basic
elements are partitioned into a system of building blocks that can easily
be configured into a solution.
Continuous modernization gradually enables legacy systems to become
more composable by replacing a component with more appropriate
technology or by encapsulating, reusing and extending a current function.
Figure 2 shows a legacy application that supports business capabilities in
the context of sales and marketing. In this example, we have assessed
how well these business capabilities are supported. The green capabilities
are fine, but the red ones have issues. These issues can be a combination
of any of the modernization drivers mentioned earlier — poor business fit,
value or agility, or high cost, complexity or risk.
Figure 2: Identify, Prioritize and Remove Friction Points to Optimize
Legacy Applications

Each capability is supported by particular parts of the same legacy

application. Instead of replacing the whole application, we can:
 Focus on modernizing parts of the application that are the root
cause of a friction point to improve business support.
 Create services and add APIs to make particular functions and data
accessible.
 Replace parts of the application or extend it with new functionality
using more appropriate technology.
Replacing a Component With More Appropriate Technology
Consider the pricing capability in Figure 2. Let’s assume that pricing is a
differentiating capability, and that the legacy application is not able to
keep up with the rate of required change (for example, it does not allow
users to quickly add new pricing models). Changing pricing schemes
requires substantial effort, time, risk and cost. A better solution might be
to replace that functionality with a rule engine that is more flexible. This
rule engine could be implemented outside of the legacy platform on a new
technology platform, or by using a SaaS service, and integrated back into
the legacy application via APIs.
It is not only the technology platform that is causing friction here. The
whole ecosystem for this legacy application also poses an obstacle. The
technology, governance, testing, methods, tools, processes, people and
culture can all be part of the friction. Basically, the pricing capability is
supported by software that is implemented on the wrong technology
platform, which is supported by the wrong ecosystem. Moving this
capability to a modernized technology platform and ecosystem — for
example, a rule engine managed by an agile team — will improve support
drastically.
Encapsulating, Reusing and Extending a Current Function
Another example from Figure 2 is the requirement for an order-tracking
function on the customer portal. We can support that requirement by
implementing an API on the order tracking part to reuse the data and
functions, and extend it by building a web graphical user interface (GUI)
on top of it. The web GUI part is implemented in a suitable technology
platform and supported by a development ecosystem that allows
continuous improvement of that capability. Encapsulation also allows us to
eventually replace that part of the legacy system with minimal impact of
extended function.
Bottom Line
By using the continuous modernization approach, applications and
software engineering leaders will not only improve support for the
business capabilities, they will also relieve the burden and pressure on the
legacy application. Continuous modernization focuses on reusing the
functions for which the application is well-suited, instead of trying to make
it do something that it was not designed to do.
Using continuous modernization, applications and software engineering
leaders can gradually transform a legacy application into a platform for
digital business. These platforms will play a foundational role in the
application portfolio, providing services via APIs that can be consumed by
other applications.
Establish a Continuous Modernization Culture
Applications and software engineering leaders must create a continuous
modernization culture. Every product or platform team must manage their
technical debt, develop a modernization strategy and continuously
modernize their products and platforms — including the ecosystem.
Teams must ensure that they don’t fall victim to “drift” over time.
The modernization strategy must be an integral part of the overall
application strategy. The goal is not only to cure technical debt in the
current application portfolio with modernization and rationalization, but
also to prevent technical debt by setting principles and guidelines for the
teams.
A continuous modernization culture is not only about IT — it must include
the business as well. Ultimately, business leaders are the owners of these
applications. They should manage their applications as assets during their
life cycle. Applications and software engineering leaders can help business
leaders to understand the role of applications in the delivery of value to
customers, and how that flow can be optimized by updating, upgrading
and removing constraints.
The work of modernization will fall on different teams in different
circumstances. In some cases, a platform team will inherit and absorb
legacy components as part of their transactional platform. Platform teams
maintain and enhance these platforms to provide timely support for the
product teams. The modernization of these components should be
managed by the same group responsible for the platform. A portion of
every release cycle should be allocated to modernization or refactoring.
In other cases, a dedicated modernization team will be required. This
could be due to the size of the effort involved, or a result of the
requirement for specific skills, knowledge or experience (such as in the
case of a mainframe application). A modernization budget must be
allocated to allow such a team to create transactional platforms from
legacy applications, and to remove obstacles and provide ample support
for product teams. Applications and software engineering leaders should
collaborate with the modernization team to define, prioritize and deliver
work based on the requirements from the product and platform teams.
These teams must coordinate their backlogs and align their delivery
cadences. Applications and software engineering leaders should ensure
that the modernization or platform team will provide timely support for
product teams (see Figure 3). This continuous coordination will also allow
all teams to quickly respond to changes in business demand, new
requirements and newly discovered obstacles.
Figure 3: Implement Continuous Modernization by Fostering Collaboration
Between Product and Platform Teams
Evidence
1
2024 Gartner CIO and Technology Executive Survey. This survey
was conducted online from 2 May to 27 June 2023 to help CIOs determine
how to distribute digital leadership across the enterprise and to identify
technology adoption and functional performance trends. Ninety-seven
percent of respondents led an information technology function. In total,
2,457 CIOs and technology executives participated, with representation
from all geographies, revenue bands, and industry sectors (public and
private). Disclaimer: The results of this survey do not represent global
findings or the market as a whole, but reflect the sentiments of the
respondents and companies surveyed.