A CIO's guide to legacy system modernization

A structured approach to legacy system modernization

Taking a structured approach to legacy system modernization means asking two key questions, then taking the right approach based on the answers to those questions. It also means making legacy system modernization an ongoing process, rather than a one-and-done project.

The hardest part for many CIOs is forcing themselves and their teams to methodically address questions they're sure they already know the answers to. But it's worth the effort: Many times, the answers will enable technology professionals to completely sidestep labor-intensive efforts.

1. What is your organization's definition of legacy?

Your answer to this question will determine which systems to focus your efforts on and which to leave alone for now.

According to Mobindustry, a software company based in Ukraine, "A legacy system is any system that hampers further development, doesn't allow for the easy integration of new features and slows down a business's day-to-day operations. In short, a legacy system is hard to maintain, support and extend."

The key point here is that legacy doesn't mean old. Applications that were completed last week may fall into this category if the developers didn't follow up-to-date architectural principles, either through ignorance or hurry. Hurried application development is a frequent source of technical debt.

Therefore, step one is to sort all systems modernization into three categories: legacy, intermediate and modern.

Legacy systems are those that require modernization, regardless of age; modern systems are those that do not. Intermediate systems and applications allow for modernization but may not be top priority.

A CIO will often resist this critical first step on the grounds that business stakeholders have reached the boiling point when it comes to tolerance of a particular application and are demanding that it be modernized immediately. The thinking usually goes, "We already know which systems need to be modernized, we don't need to waste time classifying them."

It's tempting to think that way, but it shouldn't be the case. Even if the legacy system modernization team only has the bandwidth to work on a single application, it's important to know which other systems are on the list so that best practices are applied to all.

In other words, don't treat legacy system modernization as a single ad hoc project for a critical app. View it as an ongoing process following a consistent methodology, applied to the applications most in need of modernizing.

Every system should carry a classification from the moment it goes into production. Revisit your system classification at least once a year, as systems that were previously classified as intermediate or modern will inexorably slip into legacy as technology and development practices advance.

2. What's the best approach for legacy system modernization?

By now, it should be evident that this question is about the best approach for a given application, since the point of a structured methodology is to apply the optimal approach on a system-by-system basis.

To answer this question, we need to review the core approaches to legacy system modernization.

Gartner refers to the five R's: rehost, refactor, rearchitect, rebuild, replace. That's one way to look at things, but it's both specific -- rearchitecting and rebuilding tend to overlap -- and rather broad in scope for the specific purposes of legacy system modernization.

A better way to think about legacy system modernization specifically is to think in terms of these five approaches: encapsulate, replatform, refactor, redesign, rethink.

Encapsulating a system -- via APIs -- essentially limits access to the system to match the information and workflow of modern systems that interface to it. You might, for instance, integrate the system into a common UX platform via an API so its information is displayed in a format that's easily consumed by users to deliver optimal UX.

The value of encapsulation is that it addresses the short-term pain of poor UX and makes a legacy system appear to operate like a modern one. The downside is that it doesn't address the fundamental problem with a legacy system: maintenance overhead. An encapsulated legacy system is still a legacy system; it will continue to consume just as much labor and costs once encapsulated as it did before. Since many studies suggest that CIOs spend up to 80% of their budgets supporting and maintaining legacy systems, this isn't a trivial consideration.

Replatforming is what it sounds like: moving the system -- and, likely, all its data and storage resources -- to another platform. Typically, this is either a colocation facility or IaaS. Replatforming is an attractive option when it comes to addressing short-term goals, such as shutting down an on-premises data center or avoiding an expensive WAN upgrade to enable remote users to access the system.

However, replatforming is very much an interim step. Moving a problem to IaaS or a colocation facility may address short-term concerns, but the costs of maintaining cloud services can add up, and paying cloud costs for legacy apps is merely another form of technical debt.

Refactoring, as defined by Agile Alliance, consists of "improving the internal structure of an existing program's source code while preserving its external behavior." Specifically, this includes improving objective attributes of code -- length, duplication, coupling, cohesion and cyclomatic complexity -- that correlate with ease of maintenance, enhancing code understanding and increasing the use of reusable design elements and code modules. Agile Alliance goes on to point out that refactoring does not mean rewriting code, fixing bugs or improving observable aspects of software such as its interface.

One way to understand refactoring is to think of it as code optimization. That is, the developer doesn't change the functionality or basic coding algorithms, but rather reviews code to ensure that it's optimally understandable and instantiates good agile development hygiene. You could also envision refactoring as removing technical debt from code -- i.e., replacing all the coding shortcuts and suboptimal implementation with cleaner, optimized design.

Refactoring is a good way to reduce the support costs of a system, and many organizations deploy it as a healthy part of their cloud migration strategies. The dilemma with refactoring, from the perspective of legacy system modernization, is it doesn't address the challenge of systems that rely on outmoded and outdated architectures.

Redesign encompasses both rearchitecting and rebuilding, including rewriting code. Essentially, it is architecture and design modernization. This is the option that most enterprise technologists immediately gravitate toward when considering legacy system modernization because it's the most intuitive: delivering the same business functionality but using modern coding techniques and architectures.

Redesign is certainly a viable approach, and it goes the farthest toward providing a seamless soup-to-nuts cleanup. Both UX and support costs should improve as the result of a system redesign. But, there's one more level that CIOs shouldn't rule out.

Rethinking is an underutilized approach that refers to rethinking the entire business process that a system is designed to deliver on. Most enterprise technologists take business requirements as set in stone, but they aren't. Sometimes the business requirement itself is what's obsolete.

A simple example: During the COVID-19 pandemic, many companies struggled with how to enable signature-based workflow for various documents with employees working from home and unable -- for compliance or security reasons -- to print out documents.

The real fix wasn't to modernize the applications but rather to rethink the requirement for signature-based workflow in the first place. With effective authentication, checking a box can be as ironclad as leaving a signature.

Many business requirements are obsolete or reflect the limitations of technology at the time. For example, most CRM systems predate LinkedIn and weren't designed with the ability to maintain contact with individuals across job changes.

Oftentimes, the best approach to legacy system modernization is to rethink the business process the system is serving. Frequently, you'll find the process itself is obsolete.

The answer to the question "Which approach is best?" depends on a range of factors, including cost, timing (i.e., how quickly does the modernization need to happen), the number and type of other legacy systems that need modernizing, the company's cloud strategy and the company's overall business strategy.

The important thing is to consider all legacy systems against all possible modernization alternatives, then select the approach that makes the most sense for each system. A key factor to consider is the degree to which rethinking is part of the overall modernization strategy; sometimes, rethinking can eliminate entire categories of systems.

Finally, develop a roadmap for modernizing all systems -- not just those that are currently classified as legacy. The roadmap should include a regular review of all systems to determine when they slip into the legacy category.