The CIO Guide to Modernizing Monolithic Applications

Bob Quillin

July 8, 2022

As the pace of technological change continues to accelerate, companies are being put under more and more pressure to improve their ability to quickly react to marketplace changes. And that, in turn, is putting corporate CIOs on the hot seat.

In a recent McKinsey survey, 71% of responding CIOs said that the top priority of their CEO was “agility in reacting to changing customer needs and faster time to market.” Those CEOs are looking to digital technology to enable their companies to keep ahead of competitors in a constantly evolving market environment.

CIOs are tasked with providing the IT infrastructure and tools needed to drive the marketplace innovation and agility required to accomplish that goal.

But in many cases CIOs are facing a seemingly intractable problem—they’ve inherited a suite of legacy applications that are indispensable to the company’s daily operations, but which also have very limited capacity for the upgrades necessary for them to be effective in the cloud-native, open-source technological landscape of today.

As a recent report by Forrester puts it,

“Most legacy core software systems are too inflexible, outdated, and brittle to give businesses the flexibility they need to win, serve, and retain customers.”

But because such systems are still critical for day-to-day operations, CIOs can’t just get rid of them. Rather, a way must be found to provide them with the flexibility and adaptability that will enable them to be full participants in the modern technological age.

The Problem with Monoliths

The fundamental cause of the brittleness and inflexibility that characterize most legacy systems is their monolithic architecture. That is, the codebase (which may have millions of lines of code) is a single entity with functionalities and dependencies interwoven throughout. Such applications are extremely difficult to update because a change to any part of the code can ripple through the application, causing unintended operational changes or failures in seemingly unrelated parts of the codebase.

Because they are inflexible and brittle, such applications cannot be easily updated with new features or functions—they were not designed with that capability in mind. A much broader transformation is required, one in which the application’s codebase is restructured in ways that allow it to be upgraded while maintaining the original scope. That broad restructuring is referred to as application modernization.

Application Modernization and The Cloud

What, exactly, is application modernization? Gartner provides this description:

“Application modernization services address the migration of legacy to new applications or platforms, including the integration of new functionality to provide the latest functions to the business.”

There are two key aspects of this definition: migration and integration.

Because the cloud is where the technological action is today, most application modernization efforts involve, as a first step, migrating legacy apps from their original host setting to the cloud. As McKinsey says of this trend:

“CIOs see the cloud as a predominant enabler of IT architecture and its modernization. They are increasingly migrating workloads and redirecting a greater share of their infrastructure spending to the cloud.”

The report goes on to note that McKinsey expects that by 2022, 75% of corporate IT workloads will be housed in the cloud.

That leads to the second element of the Gartner definition: integration. If legacy applications are to be effective in the cloud environment, they must be integrated into the open services-based cloud ecosystem.

That means it’s not enough to simply migrate applications to the cloud. They must also be transformed or restructured so that integration with cloud-native resources is not just possible, but easy and natural.

The fundamental purpose of application modernization is to restructure legacy code so that it is easily understandable to developers, and can be quickly updated to meet new business requirements.

Transitioning From a Monolithic Architecture to Microservices

What does it take to transform legacy apps so that they are not only cloud-enabled, but they fit as naturally into the cloud landscape as do cloud-native systems?

As we’ve seen, the fundamental problem that causes the rigidity and inflexibility that must be overcome in transforming legacy apps is their monolithic architecture. Monolithic applications are self-contained and aren’t always easy to integration with other applications or systems. The codebase is a single entity in which all the functions are tightly-coupled and interdependent. Such an app is, in essence, a “black box” as far as the outside world is concerned—its inputs and outputs can be observed, but its internal processes are entirely opaque.

If an app is to be integrated into the cloud’s open-source ecosystem, its functions must somehow be separated out so that they can interoperate with other cloud services. The way that’s normally accomplished is by refactoring the legacy code into microservices.

Related: Migrating Monolithic Applications to Microservices Architecture

What are Microservices?

Microsoft provides a useful description of the microservices concept:

“A microservices architecture consists of a collection of small, autonomous services. Each service is self-contained and should implement a single business capability.”

The key terms here are “small” and “autonomous.” Microservices may or may not be “small”, but they should be independent, and loosely coupled with a specific functionality to cover. Each is a separate codebase that performs only a single task, and each can be deployed and updated independently of any others. Microservices communicate with one another and with other resources only through well-defined APIs—there is no external visibility or coupling into their internal functions.

Advantages of the microservices architecture include:

  • Agility: Because each microservice is small and independent, it can be quickly updated to meet new requirements without impacting the entire application.
  • Scalability: To scale any feature of a monolithic application when demand increases, the entire application must be scaled. In contrast, each microservice can be scaled independently without scaling the application as a whole. In the cloud environment, not having to scale the entire app can yield substantial savings in operating costs.
  • Maintainability: Because each microservice is small and does only one thing, maintenance is far easier than with a monolithic codebase, and can be handled by a small team of developers.

The key task of legacy application modernization is to decompose a monolithic codebase into a collection of microservices while maintaining the functionality of the original application.

But how is that to be accomplished with legacy code that is little understood and probably not well documented?

Options for Transforming Monolithic Code to Microservices

Gartner has identified seven options for migrating and upgrading legacy systems.

  1. Encapsulate: Connect the app to cloud-based resources by providing API access to its existing data and functions. Its internal structure and operations remain unchanged.
  2. Rehost (“Lift and Shift”): Migrate the application to the cloud as-is, without significantly modifying its code.
  3. Replatform: Migrate the application’s code to the cloud, incorporating small changes designed to enhance its functionality in the cloud environment, but without modifying its existing architecture or functionality.
  4. Refactor: Restructure and optimize the app’s code to a microservices architecture without changing its external behavior.
  5. Rearchitect: Create a new application architecture that enables improved performance and new capabilities.
  6. Rewrite: Rewrite the application from scratch, retaining its original scope and specifications.
  7. Replace: Completely eliminate the original application, and replace it with a new one.

All of these options are sometimes characterized as “modernization” methodologies. Actually, while encapsulating, rehosting, or replatforming do migrate an app (or in the case of encapsulation, its interfaces) to the cloud, no restructuring of the codebase takes place. If the app was monolithic in its original environment, it’s still monolithic once it’s housed in the cloud. So, these methods cannot rightly be called modernization options at all.

Neither does replacement qualify as a modernization option since rather than restructuring the legacy codebase, it throws it out completely and replaces it with something entirely new.

So, to truly modernize a legacy application from a monolith to microservices will involve the use of some combination of refactoring, rearchitecting, and rewriting. Let’s take a brief look at each of these:

  • Refactoring: Refactoring will be the first step in almost any process of modernizing monolithic legacy applications. By converting the codebase to a cloud-native, microservices structure, refactoring enables the app to be fully integrated into the cloud ecosystem. And once that’s accomplished, developers can easily update the app with new features to meet specific requirements.
  • Rearchitecting: Rearchitecting is usually employed to enable improvements in areas such as performance and scalability, or to add features that are not supported by the original design. Because rearchitecting makes fundamental changes to the structure and operation of the code, it is more complex, time-consuming, and risky than simply refactoring.
  • Rewriting: Completely rewriting the legacy code is the most complex, time-consuming, and risky of all the modernization options. It is usually resorted to when developers wish to avoid spending the time and effort required to deconstruct the existing code to understand how it works. Because a rewrite carries the highest risk of causing disruptions to a company’s business operations, it is normally used only as a last resort.

Although rearchitecting or rewriting may be appropriate for some cases, refactoring should always be the starting point because it produces a codebase that developers can easily upgrade with new features or functionality. As McKinsey puts it:

“It [is] critical for many applications to refactor for modern architecture.”

Challenges of Modernization

All of the modernization options, refactoring, rearchitecting, and rewriting, require extensive changes to the legacy application’s codebase. That’s not a task to be undertaken lightly. Legacy apps typically hold onto their secrets very tightly due to several common realities:

  • The developers who wrote and maintained the original code, which in some cases is decades old, have by now retired or are otherwise unavailable.
  • Documentation, both of the original requirements and modifications made to the code through the years, is often incomplete, misleading, or missing entirely.
  • Patches to the code to handle low frequency-of-occurrence exceptions or boundary conditions may not be documented at all, and can be understood only by a minute examination of the code.
  • Similarly, changes to business process workflows may have been incorporated through code patches that were never adequately documented or covered by tests. If such workflows are not discovered and accounted for in a modernization effort, important functions of the application may be lost.

Any modernization approach will involve a high degree of complexity, time, and expertise. McKinsey quotes one technology leader as saying,

“We were surprised by the hidden complexity, dependencies and hard-coding of legacy applications, and slow migration speed.”

Building a Modernization Roadmap

If you’re trying to drive to someplace you’ve never been before, it’s very helpful to have a map. That’s especially the case if you’re driving toward modernization of your legacy applications. You need a roadmap.

The first stop on your modernization roadmap will be an assessment of the goals of your business, where you currently stand in relation to those goals, and what you need from your technology to enable you to achieve those goals.

Then you’ll want to develop an understanding of exactly what you want your modernization process to achieve. You’ll analyze your current application portfolio in light of your business and technology goals, and determine which apps must be modernized, what method should be used, and what priority each app should have.

To learn more about creating a modernization roadmap, take a look at the following resource:

Related: Succeed with an Application Modernization Roadmap

Why Automation is Required for Successful Modernization

Converting a monolithic legacy app to a microservices architecture is not a trivial exercise. It is, in fact, quite difficult, labor-intensive, time-consuming, and risky. That is, it is all that if you try to do it manually.

It’s not unusual for a legacy codebase to have millions of lines of code and thousands of classes, with embedded dependencies and hidden flows that are far from obvious to the human eye. That’s why using a tool that automates the process is a practical necessity.

By intelligently performing static and dynamic code analyses, a state-of-the-art, AI-driven automation tool can, in just a few hours, uncover functionalities, dependencies, and hidden business flows that might take a human team months or years to unravel by manual inspection of the code.

And not only can a good modernization tool analyze and parse the monolithic codebase, it can actually refactor and rearchitect the application automatically, saving the untold hours that a team of highly skilled developers would otherwise have to put into the project.

According to McKinsey, companies that display a high level of agility in their marketplaces have dramatically higher rates of automation than those characterized as the “laggards” in their industries.

The vFunction Application Modernization Platform

The vFunction platform was built from scratch to be exactly the kind of automation tool that’s needed for any practical application modernization effort. It has advanced AI capabilities that allow it to automatically analyze huge monolithic codebases, both statically and during the actual execution of the code.

As the vFunction Assessment Hub crawls through your code, it automatically builds a lightweight assessment of your application landscape that helps you prioritize and make a business case for modernization. Once you’ve selected the right application to modernize, the vFunction Modernization Hub takes over, analyzing and automatically converting complex monolithic applications into extracted microservices.

vFunction has been demonstrated to speed up the modernization process by a factor of 15 or more, which can reduce the time required by such projects from months or years to just a few weeks.

If you’d like to experience firsthand how vFunction can help your company modernize its monolithic legacy applications, schedule a demo today.

Bob Quillin

Bob Quillin is the Chief Ecosystem Officer for vFunction, responsible for developer advocacy, marketing, and cloud ecosystem engagement. Bob was previously Vice President of Developer Relations for Oracle Cloud Infrastructure (OCI). Bob joined Oracle as part of the StackEngine acquisition by Oracle in December 2015, where he was co-founder and CEO. StackEngine was an early cloud native pioneer with a platform for developers and devops teams to build, orchestrate, and scale enterprise-grade container apps. Bob is a serial entrepreneur and was previously CEO of Austin-based cloud monitoring SaaS startup CopperEgg (acquired by IDERA in 2013) and held executive and startup leadership roles at Hyper9, nLayers, EMC, and VMware.

Get started with vFunction

See how vFunction can accelerate engineering velocity and increase application resiliency and scalability at your organization.