Category: Uncategorized

For many companies today, modernizing their legacy apps is a top priority. They recognize that although those apps are critical to their business operations, they’re also major hindrances to the organization’s ability to keep pace in its marketplace. 

That’s because legacy apps, which are typically structured as monolithic architectures, are very difficult to update to meet the rapidly changing market and technological demands that characterize today’s commercial landscape.

In response to that challenge, companies are mounting projects to modernize their legacy software. But modernizing a suite of legacy apps is not a quick and easy process, and finding workers with the requisite skills and expertise to staff such projects can be difficult. 

In fact, two recent surveys found that a shortfall of skills and expertise was one of the top reasons why application modernization had failed at their organization. What are the skills required for building an effective app modernization team? To answer that question, let’s start by looking at the application modernization process.

What Application Modernization is Really All About

The goal of application modernization is to restructure a monolithic legacy app from an isolated, stand-alone codebase that doesn’t interact easily, if at all, with the modern cloud-centric ecosystem, into a microservices architecture that is cloud-native in its capabilities. How is that restructuring accomplished? A report from Capgemini describes the process this way:

Modernizing means transforming existing software, taking an agile approach to development across people, processes, and technology, and embracing cloud-native development, including microservices and containerization, hybrid cloud- integration, and agile and DevOps methodologies.

The key phrase in this description is “taking an agile approach to development across people, processes, and technology.” A legacy app modernization team should be organized according to the Agile/DevOps methodology that characterizes the modern approach to software development.

Deciding Your App Modernization Objective

Application modernization involves refactoring or rearchitecting the monolith into a set of small, autonomous microservices.

Companies have sometimes attempted to gain the benefits of modernization by simply migrating their legacy apps, with minimal changes, to the cloud. That approach is simply migration not modernization and has proven to be ineffective: as a report from Google explains,

“Although CIOs have successfully migrated some applications to the cloud, according to a McKinsey study, around 80 percent of them report that they have not achieved the agility or business outcomes they sought from application modernization.”

Migrating an app to the cloud can, by itself, provide some benefits, such as DevOps improvements in deployability and security along with shutting down data center resources. The problem is that the migrated monolithic application remains monolithic and continues to suffer from all the deficiencies of that architecture. Migration alone achieves little in terms of achieving cloud benefits such as increased scalability, development velocity, and reduced technical debt.

That’s why full modernization is accomplished by refactoring the app into microservices. The app is thereby transformed into a cloud-native architecture that’s easy to update and that can integrate with and take full advantage of the technologically advanced resources available in the cloud.

Related: Cloud Modernization Approaches: Rehost, Replatform, or Refactor?

App Modernization Team Requirements

The fact that microservices are designed to operate independently of one another has a major impact on how application modernization teams are structured. That’s because of Conway’s Law, which was first articulated by software expert Melvin Conway in 1967:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

The implication of Conway’s Law for app modernization is that an organization that aims at producing small, autonomous, independent microservices ought to be structured as small, autonomous, independent teams. 

If the organization adopts a different structure (like, for example, the large integrated teams normally used with monolithic apps), the product they produce will reflect the way the team is organized, whatever the intent for that product may have been. As software engineer Alex Kondov emphatically warns,

“You can’t fight Conway’s Law… Time and time again, when a company decides that it doesn’t apply to them they learn a hard lesson… If the company’s structure doesn’t change the software will slowly evolve into something that mirrors it.”

Domain-Driven Design (DDD) in App Modernization

Application modernization teams formed in compliance with Conway’s Law will each take full ownership of one or more microservices. But what should be the scope of each of those microservices, and therefore of the team that supports it? Tomas Fernandez of Semaphore provides a useful answer to that question:

“Domain-Driven Development allows us to plan a microservice architecture by decomposing the larger system into self-contained units, understanding the responsibilities of each, and identifying their relationships.”

DDD helps you to identify the functional domains and subdomains in a monolithic codebase and draw boundaries around each function that will be implemented as a microservice. It also allows you to employ key modernization best practices such as the Strangler Fig Pattern to carefully shut off old functions and domains in the monolith as new microservices replace them.

Related: Organizing and Managing Remote Dev Teams for Application Modernization

Key Roles in Modernization

Jason Smith, Chief User Experience Officer at dotCMS observes that,

“Agile Development, which some refer to as ‘DevOps’, means having a number of small teams working on individual, smaller projects so that those projects are able to get a team’s undivided attention. This enables the individual projects to be completed quicker. Microservice architecture fits into this development model perfectly, as each small team can own and focus on one service.”

Because the process of restructuring a monolithic codebase into microservices fits “perfectly” into the Agile model, we’ll look to that model to identify the roles you’ll need to fill for your app modernization dream team.

1. Corporate leadership – May include an Executive Sponsor who will provide both the budget and overall guidance for the project, as well as other leaders such as the CIO.
2. Product Owner – Sets requirements for the project from the viewpoint of the customer. This role, which typically is filled in-house, assigns team roles and tasks and takes full responsibility for the success of the project.
3. Project Manager – Responsible for the day-to-day operation of teams. Provides leadership for team members, defines goals, oversees progress, and ensures that budget and schedule milestones are met.
4. Modernization Architect – Translates business requirements into technical deliverables. Responsible for defining the microservice architecture the team will implement and for ensuring effective integration of the modernized app into the cloud environment.
5. Legacy App Expert – Has the skills needed to analyze the app to understand its functionality and the internal and external dependencies that must be accounted for when it is restructured into microservices.
6. Senior Developers – Individuals who have the normal range of software development skills that allow them to function as, for example, front-end or back-end developers or UI/UX designers.
7. QA Engineer – Responsible for defining comprehensive test coverage to ensure that each microservice and the restructured app as a whole function as intended.

Each microservice team won’t necessarily have all of these roles—some, such as corporate leaders or developers who analyze legacy apps, may work with several or all of the teams. Also, on small microservice teams, several roles may be filled by one person.

How Do You Find the Talent You Need?

The first question is, to what degree can you tap into your existing staff to fill the roles required for your modernization project? To answer that question, you’ll need to assess what skillsets are available in-house and whether any that are lacking can be supplied through training.

If you do have to go outside to find the skills or expertise you need, be prepared to face some challenges. The U.S. is currently experiencing a shortage of more than a million software developers, and even if you can find them, they’re hard to keep. One recruiter, DaedTech founder Erik Dietrich, declares that,

“The only way to find software developers is to go prying them loose from other firms.”

And there’s an additional challenge when you’re staffing an app modernization project: many developers just don’t want to work on legacy code. According to one survey, 78% of developers say that “Spending too much time on legacy systems” has a “negative impact” on their personal morale.

Automation Can Minimize Your Need to Hire

Legacy monoliths may contain tens of millions of lines of code and thousands of classes. Having developers manually conduct the comprehensive static and dynamic analyses necessary to uncover all of the app’s functions and dependencies can be extremely time-consuming, error-prone, costly, and from the developer’s point of view, boring. And the process of decomposing the codebase into services and reimplementing them as microservices is similarly fraught.

But an AI-enabled, automated modernization platform can perform those chores accurately and comprehensively in a fraction of the time a human would require. With that kind of assistance, not only will you need fewer new hires for your modernization efforts, but you’ll also boost the morale of your existing workers by releasing them to spend more of their time on exciting innovations rather than on decidedly unexciting legacy code.

The vFunction platform employs sophisticated AI capabilities to quickly and comprehensively analyze complex monolithic applications to uncover hidden functionalities and dependencies. Plus, it can automate about 90% of the process of restructuring a monolithic codebase into microservices.

To see first-hand how vFunction can help you build an effective modernization team while minimizing the need to hire new development talent, request a demo.

Companies today must be highly agile to meet ever-evolving marketplace demands. But the legacy applications many still depend on for much of their business-critical processing are ill-equipped to support that kind of agility. That’s why identifying and overcoming app modernization challenges is critically important.

The Consortium For Information & Software Quality (CISQ) highlights the necessity for app modernization in this way:

After decades of operation, they [legacy apps] may have become less efficient, less secure, unstable, incompatible with newer technologies and systems, and more difficult to support due to loss of knowledge and/or increased complexity or loss of vendor support. In many cases, they represent a single point of failure risk to the business.

CISQ notes that companies now spend 75% of their IT budgets on their legacy systems. That’s money that’s not being spent to provide the innovations that are critical for success in today’s market environment.

For that reason, modernizing legacy systems and applications so that they can fully participate in today’s cloud-centric ecosystem is critically important. Yet according to a 2022 survey of senior IT professionals, 79% of app modernization efforts fail, and those failures represent an enormous waste of time and resources. In this article, we want to examine the particular app modernization challenges that may give CIOs sleepless nights as they contemplate upgrading their legacy applications.

Why Overcoming App Modernization Challenges is Critical

More than half (56%) of the respondents to a survey of corporate CIOs say that their legacy applications are significant obstacles to their efforts toward digital transformation. But because those applications still perform functions that are critical for day-to-day business operations, they can’t simply be eliminated.

Rather, to gain the technological agility that’s necessary for meeting ever-changing marketplace demands, companies must find ways to integrate their legacy apps into today’s cloud-centric ecosystem.

That’s what application modernization is all about. Industry analyst David Weldon puts it this way:

“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.”

When done well, application modernization not only provides the flexibility and agility that enables companies to react quickly to changing marketplace conditions, but it also yields better application performance, increased efficiency for developers, and reduced overall costs.

Challenges of Application Modernization

The app modernization challenges most likely to keep CIOs awake at night fall into three major categories: costs, time, and risk. Let’s take a closer look at each.

1. Costs

There’s no question that any significant legacy app modernization effort will require a substantial investment of both money and time. According to one survey, the average application modernization project costs $1.5 million and takes 16 months–and still, 79% of these initiatives fail.

Obtaining the necessary budget commitment is often the biggest obstacle CIOs face in initiating a legacy app modernization project. That’s especially the case when a company’s legacy apps seem to still be functioning as intended and providing value to the organization. That perception may cause senior management to take an attitude of “if it ain’t broke, we can’t afford to fix it.”

Yet, the risks and costs of doing nothing are substantial. Using a standardized metric it calls the Cost of Poor Software Quality, CISQ calculated that in 2020 it cost businesses $520 billion to maintain legacy software.

In addition, as the technological context for which they were designed recedes further and further into the past, legacy apps become more brittle (easily breakable) and may constitute, as CISQ notes, a “single point of failure risk” that could trigger huge unexpected costs if a breakdown should occur.

How can a CIO deal with the inevitable budget limitations that could seriously curtail any effort at legacy app modernization? First, costs must be contained; second, senior management must be shown the positive ROI that legacy app modernization can yield.

Containing Legacy App Modernization Costs

Legacy application modernization, which normally involves refactoring monolithic legacy codebases to convert them to a cloud-native microservices architecture, requires a high level of expertise within the development team. Not only must developers understand the legacy app itself (and its technological framework), but they must also be skilled in navigating the open-source environment of the cloud.

That presents a two-fold problem. First, the developers who were most familiar with the legacy app are usually no longer available, and finding equally knowledgeable replacements is nearly impossible. Second, while developers who are at home with cloud technologies are available, they come at a cost that is often beyond what companies can pay to staff a modernization project.

The answer is to not try to do everything yourself. Instead, you’ll want to work with partners that already have the skills and experience required for efficiently modernizing monolithic codebases.

Related: The CIO Guide to Modernizing Monolithic Applications

Making the ROI Case for Legacy App Modernization

Getting the budget commitments needed for an app modernization effort requires getting buy-in from the executive team. You’ll need to present quantitative information that establishes the ROI that can be expected from such a project. That data can be acquired by use of an AI-enabled automated tool that can help you assess the technical effort required, the associated costs, and the savings that will ultimately be gained.

2. Time

Refactoring legacy apps to give them an essentially cloud-native architecture is a highly complex task. A monolithic codebase is basically a single unit that has function implementations and dependencies woven throughout the code in non-obvious ways.

Manually unraveling millions of lines of code to expose those functions and dependencies requires both a high degree of technical expertise and the investment of many months or even years of developers’ time. A report by McKinsey quotes one IT leader as saying,

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

But the key word in this scenario is “manually.” The degree of complexity, and the time required to manage it, can be substantially reduced by employing the kind of AI-enabled, automated analysis tool we mentioned before. The use of such a tool can allow developers to accomplish in just weeks what would take many months if done manually.

3. Risk

Perhaps the scariest of the app modernization challenges that may keep a CIO up at night is the potential that after a significant investment of time and money, the project might fail to deliver the expected benefits. Even worse is the risk that faults might be inserted into a business-critical legacy app, causing significant disruptions to company operations.

Those risks are real. As we’ve seen, almost 80% of legacy app modernization efforts end in failure. And there are risk factors inherent in the process of refactoring monolithic codebases into microservices that can rarely be avoided.

For example, there’s often a knowledge gap caused by the fact that the original developers of a legacy app are no longer available, and written documentation is often incomplete or outdated. In its many years of service, legacy code will usually have been modified, adapted, and patched to meet specific needs of the moment, but such changes are rarely adequately documented. As a result, developers engaged in a modernization effort might overlook important functions that are hidden in the code.

Minimizing the Risk Factor

How can such risks be mitigated? The key is good planning and taking a step-by-step approach that allows you to fully test changes before they are incorporated into the application.

Start by assessing your legacy app portfolio to identify and prioritize those apps that need immediate modernization to meet current or future business goals versus those that can be left alone for now or simply migrated to the cloud (via rehosting or replatforming) with minimal changes. This is another area in which having an automated, AI-based analysis tool is critical.

In a microservices architecture, each service embodies a single function that can be implemented and thoroughly tested without impacting the application as a whole. Your modernization plan should be based on adding or replacing functionality one at a time with their microservice implementations. The plan should also include a process for quickly and seamlessly backing a microservice out if problems arise when it’s incorporated into the application.

Related: Succeed with an Application Modernization Roadmap

How vFunction Helps CIOs Overcome App Modernization Challenges

We’ve seen how having an AI-based, automated tool can make a huge difference in minimizing the cost, time, and risk factors of legacy app modernization. And that’s exactly what the vFunction Platform provides.

The vFunction Assessment Hub can automatically analyze legacy apps and generate quantitative measures of code complexity and interdependence. It produces hard numbers that quantify the amount of effort required to modernize each app, providing the information you need to prioritize your modernization efforts and estimate ROI for the project.

The vFunction Modernization Hub automatically transforms complex monolithic applications into microservices. It uncovers hidden process flows and dependencies in applications, thereby minimizing the chance that important functions will be overlooked or incorrectly implemented.By making use of such automated features, vFunction accelerates modernization projects by 10-15x, saving hundreds of thousands of dollars per application. To see first-hand how vFunction can help you overcome app modernization challenges and sleep well at night, schedule a demo today.

Many companies still depend on legacy applications for some of their most business-critical processing. But those apps typically don’t support the kind of technological agility that’s needed for continuing success in today’s ever-changing marketplace environment. That’s why modernizing legacy apps is an accelerating trend among leading companies.

But app modernization is not easy—it requires highly skilled developers who understand both the legacy app and the modern cloud ecosystem. Assembling such a team on-site can be difficult. It’s often easier to find the needed skills and organize the team for maximum effectiveness if team members can work remotely. According to Forbes, which declares that remote work is the new normal,

“When it comes to the tech workforce, it takes more than simply offering remote opportunities to get employees motivated. Employers must embrace flexibility and build (or reinforce) a strong, supportive remote work culture to ensure teams are engaged and high-performing.”

That’s why understanding how to assemble and manage remote legacy app modernization teams is vitally important.

The Goal of App Modernization: From Monoliths to Microservices

Legacy apps are often a severe drag on a company’s ability to innovate at the pace required in today’s fast-changing marketplace and technological environments. That’s because such apps are typically monolithic, meaning that the codebase is organized as a single unit.

Because various function implementations and dependencies are interwoven throughout the code, an attempt to change any specific behavior could impact the entire application in unexpected ways, potentially causing it to fail.

When legacy apps are used for a company’s most important operational processes, such failures cannot be tolerated. When they occur, development teams may be required to stop work on the innovations that are so necessary to a company’s continued marketplace success and take an all-hands-on-deck approach to fixing the problem as quickly as possible.

In contrast to the typical legacy app, software based on a cloud-native microservices architecture can be updated far more easily and safely from remote locations. Microservices are small units of code that perform a single task. Because they are designed to function independently of one another, changes made to one microservice can’t ripple through the rest of the application. That’s why restructuring a legacy app from a monolith to a microservices architecture gives it a much greater level of adaptability.

The goal of legacy application modernization is to substantially improve an app’s adaptability and maintainability by restructuring its codebase from a monolith to microservices.

Related: Application Modernization and Optimization: What Does It Mean?

How System Architecture Correlates With Organizational Structure

In 1967 Melvyn Conway formulated what’s come to be known as Conway’s Law:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Software engineer Alex Kondov highlights the practical implications of Conway’s Law:

Imagine a small company with a handful of engineers all sitting in the same room. They will probably end up with a more tightly coupled solution that relies on their constant communication. [In other words, a monolith].

A large company with teams in different time zones working on separate parts of the product will need to come up with a more distributed solution. That will allow them to work autonomously, build and deploy without interfering with each other… An organization in which teams need to operate in a fully autonomous manner would naturally come to an architecture like microservices.

The organizational structure of your legacy app modernization team will determine the kind of software it ultimately produces. Although you may aim at creating a microservices-based application, if your team is organized in the tightly-coupled manner of Kondov’s first example, it will be more predisposed towards a monolithic application architecture rather than a microservices architecture.

Optimizing Your Team’s Structure to Support Microservices

The principles of Domain-Driven Design (DDD) provide a useful framework for organizing legacy app modernization teams. As Tomas Fernandez explains,

“Domain-Driven Development allows us to plan a microservice architecture by decomposing the larger system into self-contained units, understanding the responsibilities of each, and identifying their relationships.”

According to María Gómez, Head of Technology for ThoughtWorks, examples of domains include broad business areas such as finance, health, or retail. Each domain may contain several sub-domains. The finance domain, for example, might have sub-domains of payments, statements, or credit card applications.

The DDD paradigm allows developers to identify the domains and subdomains that exist in a monolithic codebase, and draw the boundaries that delineate each service that will be implemented as a microservice. Every microservice embodies a single business goal and has a well-defined function and communications interface. This allows each microservice to run independently of any others.

Each team is fully and solely responsible for the microservices that they develop, and functions, to a considerable degree, independently of other teams. Once a team is made aware of the communications interface defined for each microservice, it can work independently and asynchronously without needing to interact with other teams about how their microservices are implemented.

This organizational pattern favors remote development teams. Each team needs a high degree of internal asynchronous communication as they work out the design of the microservice for which they are responsible. But less communication is needed between teams.

For that reason, remote, loosely-coupled development teams are perfect for converting monolithic legacy apps to microservices. But there are some potential pitfalls tech leaders should be aware of.

Related: What is a Monolithic Application? Everything you need to know

Challenges of Remote Teams

With all of the advantages remote development teams provide for the application modernization process, there are some definite challenges that IT leaders will have to overcome to make their use of such teams effective. Let’s take a brief look.

1. Work-Life Balance

Working remotely can affect work-life balance both positively and negatively: while ZDNet reports that 64% of developers say that working remotely has improved their work-life balance, 27% say that it’s difficult for them to unplug from the job.

Leaders must proactively help remote developers in this area. A big part of doing that is ensuring that goals and deadlines are realistic and that workers aren’t encouraged to spend what should be family or personal time on job-related activities.

2. Assessing Productivity and Progress

Because personal contact with workers is more constrained, leaders have less visibility into the productivity or progress of remote teams. Gaining that visibility may require more formal reporting arrangements, such as daily check-ins where workers report progress on their KPIs. Project management tools such as Trello or Asana can also help.

3. Communications

In the office, developers naturally consult and collaborate informally. That’s more difficult when they are working remotely. In fact, in Buffer’s 2022 State Of Remote Work survey, 56% of respondents identify “how I collaborate and communicate” as a top remote work issue, while 52% say they feel less connected to coworkers. Scheduling regular virtual team meetings using tools like Zoom or Google Chat can help.

4. Work Schedules Across Time Zones

It’s 9 am in San Francisco, and your West Coast team members are starting their workday, but team members in Europe are finishing theirs. How can a team collaborate across time zones? One approach is to focus on asynchronous communication methods, such as group chats and emails, that don’t require individuals to be online at the same time.

5. Company Culture

Company culture is absorbed most easily through face-to-face interactions with leaders and peers. The isolation inherent in remote work makes instilling that culture among team members difficult. John Carter, Founder of TCGen, offers this suggestion:

“Make the unconscious cues in the company culture conscious. Refer to them often and reinforce them. Company culture can follow your team members home, but only if it is made explicit and constantly reinforced.”

Why Remote Teams are the Future

Not only is the distributed nature of remote teams ideal for implementing distributed, cloud-based microservices applications, but they represent a trend that may redefine the IT landscape well into the future.

The COVID-19 pandemic accelerated the use of remote software development teams. As companies learned how to onboard, train, and manage a remote workforce, they realized that disregarding geographical limitations in their hiring allowed them to lower costs and increase quality by tapping into a wider developer talent pool. Bjorn Lundberg, Senior Client Partner at 3Pillar Global describes the trend this way:

“Contract workers, freelancers, and outsourced teams have been on the rise for a while now… As remote collaboration becomes a fixture of the modern workplace, American companies increasingly view outsourcing software development as an opportunity to extend their development talent without exhausting their budgets.”

Even full-time employees want to work remotely: according to the 2022 State of Remote Engineering Report, 75% of developers would prefer to work remotely most of the time.

How vFunction Can Empower Your App Modernization Teams

As we’ve seen, the ideal application modernization team should be relatively small. vFunction helps small teams maximize their effectiveness by providing an AI-enabled, automated platform that reduces the legacy app restructuring workload by orders of magnitude.

vFunction can automatically analyze complex monolithic applications, with perhaps millions of lines of code, to reveal hidden functionalities and dependencies. It can then automatically transform those apps into microservices.To see first-hand how vFunction helps remote application modernization teams maximize their effectiveness, request a demo today.

In a report on managing technical debt, Google researchers make a startling admission:

“With a large and rapidly changing codebase, Google software engineers are constantly paying interest on various forms of technical debt.”

What’s true of Google is very likely true of your company as well, especially if you have legacy applications you still depend on for important business functions. If you do, you’re almost certainly carrying a load of technical debt that is hindering your ability to innovate as quickly and as nimbly as you need to in today’s fast-changing marketplace and technological environments.

Technical debt is an issue you cannot afford to ignore. As an article in CIO Magazine explains,

“CIOs say reducing technical debt needs increasing focus. It isn’t wasting money. It’s about replacing brittle, monolithic systems with more secure, fluid, customizable systems. CIOs stress there is ROI in less maintenance labor, fewer incursions, and easier change.”

But what, exactly, is technical debt, and why is managing it so vital for companies today?

Why Managing Technical Debt is Critical

What is technical debt? According to Ori Saporta: “Technical debt, in plain words, is an accumulation over time of lots of little compromises that hamper your coding efforts.”

In other words, technical debt is what happens when developers prioritize speed over quality. The problem is that, just as with financial debt, you must eventually pay off your technical debt, and until you do, you’ll pay interest on the principal.

• The “interest” on technical debt consists of the ongoing charges you incur in trying to keep flawed, inflexible, and outmoded applications running as the technological context for which they were designed recedes further and further into the past. Software developers spend, on average, about a third of their workweek addressing technical debt. Plus, there’s also the opportunity cost of time that’s not being spent to develop the innovations that can help propel a company ahead in its marketplace.
• The “principle” on technical debt is what it costs to clean up (or replace) the original messy code and bring the application into the modern world. Companies typically incur $361,000 of technical debt for every 100,000 lines of code.

Managing your technical debt is critical because the price you’ll pay for not doing so, in terms of time, money, focus, and lost market opportunities, will grow at an ever-accelerating pace until you do.

Managing Technical Debt: Getting Started

A report from McKinsey highlights how a company can begin dealing with its technical debt:

“[A] degree of tech debt is an unavoidable cost of doing business, and it needs to be managed appropriately to ensure an organization’s long-term viability. That could include ‘paying down’ debt through carefully targeted, high-impact interventions, such as modernizing systems to align with target architecture.”

The place to start in managing technical debt is with modernizing legacy applications to align with a target architecture, which today is usually the cloud. Legacy applications weren’t designed to work in the cloud context, and it’s very difficult to upgrade them to do so. That’s because such apps often have a monolithic system architecture.

Monolithic code is organized as a single unit with various functionalities and dependencies interwoven throughout the code. The coding shortcuts, ad hoc patches, and documentation inadequacies that are typical sources of technical debt in legacy applications are embedded in the code in ways that are extremely difficult for humans to unravel. Worse, because of hidden dependencies in the code, any changes aimed at upgrading functions or adding features may ripple throughout the codebase in unexpected ways, potentially causing the entire application to fail.

From Monoliths to Microservices

Because a monolithic architecture makes upgrading an application for new features or for integration into the cloud ecosystem so difficult, the first step of legacy app modernization is usually to restructure the code from a monolith to a cloud-native, microservices architecture.

Microservices are small chunks of code that perform a single task. Each can be deployed and updated independently of any others. This allows developers to change a specific function in an application by updating the associated microservice without the risk of unintentionally impacting the codebase as a whole.

The process of restructuring a codebase from a monolith to microservices will expose the hidden dependencies and coding shortcuts that are the source of technical debt.

Related: Migrating Monolithic Applications to Microservices Architecture

Options for Modernizing Legacy Apps

Gartner lists seven options for modernizing legacy applications:

1. Encapsulate: Connect the app to cloud resources by providing API access to its existing data and functions, but without changing its internal structure and operations.
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 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: Throw out the original application, and replace it with a new one.

The first three options, encapsulation, rehosting, and replatforming, simply migrate an app to the cloud with minimal changes. They offer some improvements in terms of operating costs, performance, and integration with the cloud. However, they do little to reduce technical debt because there’s no restructuring of the legacy application’s codebase—if it was monolithic before being migrated to the cloud, it remains monolithic once there.

The last option, replacing the original application, can certainly impact technical debt, but because it’s the most extreme in terms of time, cost, and risk, it’s usually considered only as a last resort.

The most viable options, then, for removing technical debt are refactoring, rearchitecting, or rewriting the code.

Assessing Your Monolithic Application Landscape

The ideal solution for managing technical debt would be to immediately identify and convert a subset of your legacy applications to microservices. But because any restructuring project involves significant costs in terms of money, time, and risk, trying to modernize every app in your portfolio is not a practical strategy for most companies.

That’s why your first step on the road to effectively managing technical debt should be surveying your portfolio of monolithic legacy applications to assess each in terms of its complexity, degree of technical debt, and the level of risk associated with upgrading it. With that information in hand, you can then prioritize each app based on the degree to which its value to the business justifies the amount of effort required to modernize it.

• For apps with high levels of technical debt and great value to the business, consider full modernization through refactoring, rearchitecting, or rewriting.
• Apps with lower levels of technical debt (meaning that they function acceptably as they are) or that have a lesser business value should be considered for simple migration through encapsulation, rehosting, or replatforming.

Refactoring is Key

Refactoring is fundamental to managing technical debt for at least two reasons:

1. It exposes the elements of technical debt, such as hidden dependencies and undocumented functionalities, that are inherent in an app’s original monolithic code. These must be well understood before any rearchitecting or rewriting efforts can be safely initiated.
2. By converting an app to a cloud-native microservices architecture, refactoring positions it for full integration into the cloud ecosystem, making further upgrades and functional extensions relatively easy.

That’s why refactoring is normally the first stage in modernizing a monolithic legacy app. Then, if new capabilities or performance improvements are required that the original code structure does not support, rearchitecting may be in order. Or, if the development team wishes to avoid the complexities of rearchitecting existing code, they may opt to rewrite the application instead.

In any case, refactoring will normally be the initial step because it produces a codebase that developers can easily understand and work with.

Implement “Continuous Modernization”

Technical debt is unavoidable. As the pace of technological change continues to accelerate, even your most recently written or upgraded apps will slide relentlessly over time toward increased technical debt. That means you should plan to deal with your technical debt on a continuous basis–known as continuous modernization. As John Kodumal, CTO and cofounder of LaunchDarkly has said,

“Technical debt is inevitable in software development, but you can combat it by being proactive… This is much healthier than stopping other work and trying to dig out from a mountain of debt.”

You need to constantly monitor and clean up your technical debt as you go, rather than waiting until some application or system reaches a crisis point that requires an immediate all-out effort at modernization. In fact, continuous modernization leads to technical debt removal and should be a fundamental element of your CI/CD pipeline.

Related: Preventing Monoliths: Why Cloud Modernization is a Continuum

vFunction Can Help You Manage Your Technical Debt

As we’ve seen, the first step toward effectively managing your technical debt is to assess your suite of legacy apps to understand just how large the problem is. That has historically been a very complex and time-consuming task when pursued manually. But now the AI-driven vFunction platform can substantially simplify and speed up the process.

The vFunction Architectural Observability Platform will automatically evaluate your applications and generate qualitative measures of code complexity and risk due to interdependencies. It produces a number that represents the amount of technical debt associated with each app, providing you with just the information you need to prioritize your modernization efforts.

And once you’ve determined your modernization priorities, the vFunction Code Copy automates the process of actually transforming complex monolithic applications into microservices, which can result in immense savings of time and money. If you’d like a first-hand view of how vFunction can help your company effectively manage its technical debt, schedule a demo today.

The Microsoft Azure Cloud is a popular destination for companies seeking to modernize their legacy applications. Azure provides a variety of fully managed services that make application modernization much easier by shifting much of the infrastructure management workload from developers to the platform itself.

These services include Infrastructure as a Service (IaaS) offerings that allow legacy apps to be directly migrated to the cloud without making major changes to the code. This approach allows developers to take advantage of cloud characteristics, such as increased scalability, performance, stability, and security, without making major investments of time and money.

Azure also offers a suite of fully managed Platform as a Service (PaaS) tools that help developers restructure legacy apps for easy integration into the cloud ecosystem.

To take full advantage of the Azure platform, companies should be aware of the modernization services it provides, and closely examine them to determine how they can best be used. But to put those services into proper perspective, let’s first establish what application modernization is all about.

The Need for Application Modernization

Many companies still use applications developed years or decades ago for some of their most business-critical processing. Often, such applications were built at a time when software development standards were far less sophisticated than they are today, and when apps were not expected to interact with other software. As a result, many legacy apps are limited in two crucial areas:

• Their architecture is monolithic, meaning that the codebase is essentially a single unit with function implementations and dependencies interwoven throughout. Upgrading such applications is extremely difficult because a single change to any function or feature might ripple through the code in unexpected ways, possibly causing the entire app to fail.
• Legacy apps are usually self-contained, with little ability to interact with other applications. In today’s open-source, cloud-centered environment, an inability to tap into the functionalities provided by other cloud resources can be a crippling disadvantage.

Legacy application modernization aims at overcoming these deficiencies by converting an app’s codebase from a monolith to microservices.

The Importance of Microservices

For true modernization to occur, a monolithic legacy app codebase must be restructured into a cloud-native, microservices architecture.

Microservices are small chunks of code that operate autonomously and perform a single task. Because they can be deployed and updated independently of one another, microservices allow individual functions to be easily upgraded to meet new requirements without impacting other portions of the application. When a legacy app is restructured into microservices, upgrading it becomes far easier.

Because microservices communicate using APIs based on published, standardized interface definitions, legacy apps that have been converted to microservices can easily be integrated into the cloud ecosystem and tap into the multitude of open-source services it offers.

Related: Migrating Monolithic Applications to Microservices Architecture

App Modernization Strategies

Most companies involved in legacy application modernization make use of three major approaches:

1. Migrate (Rehost, Replatform)

Because it’s usually not possible to fully modernize all of their legacy apps in one fell swoop, companies often rehost or replatform many of those apps to the cloud with minimal changes. This is the easiest means of reaping some of the benefits of the cloud environment, such as improvements in performance and scalability, without making wholesale alterations to the code.

The problem is that although such “lift and shift” efforts tap into some cloud capabilities, the app itself remains essentially unchanged—if it was monolithic in the data center, it’s monolithic in the cloud, with all the disadvantages of that architecture.

2. Replace

Companies typically replace only a small percentage of their legacy apps. It’s usually done when the complexities of upgrading the original code to meet new requirements are too great, and it seems simpler to start from scratch. But because this option is the most extreme in terms of time, cost, and risk, it’s normally chosen only as a last resort.

3. Modernize (Refactor, Rearchitect, or Rewrite)

Forward-looking companies recognize that their most business-critical legacy apps should not simply be migrated to the cloud, but should be fully modernized by restructuring them as cloud-native microservices. This is normally done using one of the following approaches:

• Refactoring: Restructure the app’s code to microservices without changing its external behavior. Refactoring allows legacy apps to fit comfortably into a cloud-first environment.
• Rearchitecting: Create a new application architecture that enables improved performance, greater scaling, and enhanced capabilities.
• Rewriting: Rewrite the application from scratch, retaining its original scope and specifications.

Refactoring is normally the starting point because it transforms monolithic code into a form that’s simpler, cleaner, and easier for developers to understand. That makes it much easier to update refactored apps with new features and integrate them into the cloud ecosystem. Even if a legacy app must ultimately be rearchitected or rewritten to obtain the needed functionality or performance, the first step is usually to refactor it so that developers can more easily work with it.

Related: The CIO Guide to Modernizing Monolithic Applications

Azure App Modernization Offerings

Now that we understand what legacy app modernization is all about, let’s look at the tools Azure offers to facilitate that process.

Azure App Service (AAS)

Azure App Service enables migration of apps directly to the cloud. As a PaaS platform, Azure App Service takes over management of all infrastructure functions, such as the operating system and runtime or middleware components, relieving users of such concerns. AAS provides a set of tools that allow applications written in the most popular programming languages, including .NET, Java, Ruby, Node.js, PHP, and Python, to be adapted into an essentially Azure-native form.

Azure Spring Cloud

Azure Spring Cloud, now renamed to Azure Spring Apps, is a fully managed PaaS offering that facilitates seamless integration of Spring apps with Azure. It is especially important in restructuring monolithic legacy apps as microservices. As the digital publication AiThority notes:

“Spring is the most powerful and widely used Java framework for building custom Cloud-based microservices for web and app… [Azure Spring Cloud] enables any coder to run complex Spring apps at scale, completely removing the pain and risk of managing Spring architecture in virtualized setup.”

Azure Kubernetes Service (AKS)

According to Microsoft, cloud-native apps “are often composed of distributed microservices hosted in containers.” The most widely used container orchestration platform is Kubernetes. However, Kubernetes deployment and management can be quite complex. Azure Kubernetes Service relieves developers of much of the operational workload and is, Microsoft says, the quickest way to develop and deploy cloud-native apps.

Azure Container Apps (ACA)

Azure Container Apps is a fully managed serverless container service that enables users to build, deploy, and run microservices and containerized apps at scale in a serverless environment. ACA automatically manages infrastructure and complex container orchestrations. ACA applications, as well as individual microservices, can dynamically scale up or down, in or out, to meet changing requirements.

Azure SQL Database / Azure Cosmos DB

Azure SQL Database is Azure’s native SQL database, while Azure Cosmos DB is a serverless NoSQL database. Both are fully managed PaaS services that handle all infrastructure-related issues, such as updates, patches, backups, and monitoring.

• Azure SQL Database is essentially a DBaaS (database as a service) offering. It uses the same underlying DB engine as SQL Server, allowing easy migration from an on-premises SQL Server database to Azure.
• Azure Cosmos DB provides API access to NoSQL databases such as MongoDB and Apache Cassandra while offering single-digit millisecond performance, instant and automatic scalability, and an SLA-backed 99.999% availability guarantee.

Azure Database Migration Service

Azure Database Migration Service is a fully managed service that enables seamless migration of data from relational database sources to Azure. Supported databases include SQL Server, MySQL, PostgreSQL, and MongoDB.

Azure API Management (APIM)

Azure API Management is a multi-cloud API management platform. C# Corner describes it this way:

“API Management (APIM) is a way to create consistent and modern API gateways for existing back-end services. API Management helps organizations publish APIs to external, partner, and internal developers to unlock the potential of their data and services”

With APIM, your previously isolated legacy apps can be fully integrated into the cloud ecosystem.

Azure DevOps

Azure DevOps is a SaaS (Software as a Service) offering that provides services and tools to support DevOps teams in building cloud-native applications. Microsoft describes it this way:

“Azure DevOps supports a collaborative culture and set of processes that bring together developers, project managers, and contributors to develop software.”

Azure Application Gateway

Azure Application Gateway is a PaaS load balancer that maximizes throughput by automatically distributing web traffic among multiple virtual servers.

Azure Key Vault

Azure Key Vault allows centralized, secure storage of information (such as passwords, API keys, cryptographic keys, and security certificates) for which access must be controlled. Key Vault eliminates the need to include security information (such as key strings) as part of an application’s code.

How vFunction Accelerates Azure App Modernization

Ideally, a company would want to modernize all of its important legacy apps. But because traditional refactoring is so time, labor, and risk intensive, developers often settle for migrating many critical apps to the cloud basically as-is. By doing so they forego most of the benefits of the cloud ecosystem.

Now, however, vFunction has changed that equation. Its AI-driven modernization platform substantially automates the process, significantly increasing speed, lowering risk, and allowing a greater proportion of a company’s legacy app portfolio to be refactored into microservices.

In early 2022, Microsoft explicitly recognized the value vFunction brings to the Azure app modernization table. According to a recent devops.com article:

“Microsoft has teamed up with vFunction to make it easier to convert monolithic Java applications into a set of microservices that can be deployed on the Microsoft Azure cloud… the goal is to eliminate the heavy lifting currently required to shift Java applications into the cloud.”If you’d like to experience first-hand how the Azure/vFunction partnership can help modernize your company’s legacy applications, please schedule a demo today.

This webinar from ADTMag with guest speakers Moti Rafalin, CEO of vFunction, and KellyAnn Fitzpatrick, Senior Analyst at RedMonk, reveals some critical insights with supporting survey data that can help CIOs and architects better understand, plan, prioritize, and succeed with application modernization projects.   

Insight #1 – Application Modernization Must Be A Dynamic, Not Static, Imperative

Kelly’s first insight emphasized that modernizing applications is not a “one-and-done” project. It’s an ever-moving target–if you modernized a 15-year-old application in 2018, then you can expect to need further modernization initiatives to catch up to the expectations, technologies, and platforms of 2022 and beyond. 

The term “Continuous Modernization” is key here–the ability to maintain fast innovation and development cycles, rapidly detect and eliminate technical debt, and avoid poor architectural decisions and coding patterns–refers to a highly valuable set of capabilities that elite software organizations have internalized.

Insight #2 – In the Cloud ≠ Cloud Native

Kelly then dug deeper why it’s not enough to simply have workloads running in the cloud. Migrating existing applications to the cloud, often seen as “lift and shift”, is a short-term tactical action that doesn’t solve the major challenges of development velocity, technical debt accumulation, and speed of innovation. Migrating to the cloud solves certain problems, like hosting, baked-in security, and cost controls, but also introduces other problems if the application is still a monolith now running in the cloud.

The adoption of containers, managed services, serverless workloads, and new paradigms of building, integrating, and deploying applications mean something more substantial is needed: actual modernization (refactoring, rewriting, rearchitecting) of logical domains, business logic, APIs and more is where strategic value can be achieved.

Insight #3 – Microservices Have Trade-offs That Are Worth It

Next up, Kelly focused on why modernizing a monolith into a microservices architecture isn’t easy–it requires a major mental shift in how development, testing, and deployment is done. The benefits of microservices have been discussed ad nauseum for many years now–like increased velocity, better flexibility, and faster development and deployment.  

However, these benefits come with a new set of challenges that IT organizations didn’t have to worry about as much before: overall application complexity, API management, event-driven communication and distributed data management are just some of these examples. Despite these trade-offs, elite technology organizations have made it a priority to succeed with a microservices architecture (when it makes sense).

Insight #4 – Technology Is Great, But Have You Tried Talented People?

If the decision to modernize didn’t directly impact the development team around it, things might be simpler, Kelly shared. However, we cannot ignore the human aspect–in fact, 97% of survey respondents expressed that organizational pushback against modernizing is to be expected. Whether it’s the cost, risk, fear of change, or fear of failure, it’s often difficult to get full team support to begin a large-scale modernization project.  

How does the monolithic structure of your business applications and organization influence the hiring and onboarding of new employees? Are they excited to spend their first 6 months on the job trying to understand a 15-year-old monolith with 10 million lines of code? More importantly, what does this mean for retaining valuable staff in the days of the Great Resignation?  

Insight #5 – Java (and .NET) Are Still Vital

Finally, Kelly reminded us all that Java is still vital and evolving, adapting to modern cloud architectures in new and innovative ways. Newer programming languages like Scala, Kotlin, and Go may be viewed as popular  for greenfield projects and indeed have been used at some of the world’s most well-known companies–Twitter, Airbnb, Google, and many others have embraced alternative languages to deal with specific challenges.

Yet, as Redmonk’s Programming Language research continues to show, the newer investments and advancements in Java combined with the fact that the majority of monolithic enterprise systems were written in languages like Java (plus .NET and C# ), make Java very relevant for everyone today. These are vital programming languages to many leaders in the finance, healthcare, automotive, and manufacturing industries. When you’re a financial services provider processing $1 billion of transactions every day, you do not have to simply turn everything off and adopt a new set of technologies. This is where application modernization and the strategic, long-term impact of refactoring and re-architecting pay off.

Next Steps

To learn more, we invite you to learn from the 2022 research report Why App Modernization Projects Fail, and check out vFunction Architectural Observability Platform, a purpose-built tool to analyze, calculate, and identify technical debt in order to prioritize your efforts and make a business case for modernization.