What Are Legacy Apps and What’s the Right Way to Modernize Legacy Apps?

What are legacy applications?

In the world of IT, you often hear about “legacy systems.” The term refers to systems that have remained in use at an organization for years, and thus, are no longer top-of-the-line or fresh.

A legacy system might be software or hardware; it might be a file format or programming language. Considering this, a “legacy application” is an application that is obsolete or growing obsolete. A legacy app can create problems over time if it’s buggy and difficult to update.

Sticking with legacy apps puts an organization at risk of catastrophe if the app should lose compatibility with modern operating systems—it can even result in security vulnerabilities.

In this blog post, you will learn the steps to modernize legacy applications and what this process of modernization involves.

Why are legacy systems and applications a concern?

Legacy systems include mission-critical, yet outdated, business processes and technologies. Mainframe software started being labeled as “legacy applications” when PCs began taking over the enterprise.

“Legacy applications are anything the new kids don’t want to play with,” says Gary Baney, chief development officer at IT service provider Advanced Server Management Group (ASMGi). “That’s the best technical definition because eventually, it defines sustainability, maintainability, and how much technical enthusiasm will be present in the application development process.”

Legacy systems are limited to their original purpose, and it’s not typically easy or cost-effective for them to integrate with more modern technology.

“There’s a symbiotic relationship between business and technology development,” says Baney. “The biggest downside of legacy applications is that the symbiotic relationship has disappeared.”

Why should you retire your legacy software?

“What language the code is written in or how old the software package is matters less than whether we can sustain it, support it, and maintain it,” says Peter Anderson, CTO at Computer Systems Center (CCSI). “What comes into play is manufacturer end-of-life and how much risk we are willing to take.”

Imagine running an 8-bit computer built in 1969 in the field today. Finding programmers is as difficult as finding technicians who can build the vacuum tubes needed to run the system. When it was built, a replacement board cost $400. Today it costs over $70,000.

“The people who are making technology decisions are not directly impacted by those decisions,” said Anderson. “They’re looking at things in terms of out-of-pocket cost rather than the total cost of ownership. Meanwhile, I’m thinking about how much it costs to build a vacuum tube and test everything. Maintaining the old system is probably more costly than buying a new system.”

Cost isn’t always a barrier

While the cost of maintaining an old system may indicate that a change is needed, it is also possible to spend more than necessary on a new solution.

One of Baney’s clients was prepared to spend $500,000 over 18 months to completely replace a 10-year-old enterprise resource management (ERP) system. By taking a more strategic approach to legacy modernization, the same functionality could be delivered at less than one-fifth of the cost and completed in less than one-third of the time.

“The client wanted to add eight new types of functionality. All we really needed to do was tie handheld devices into the existing ERP database,” Baney says.

By extending the capabilities of their legacy systems, the client’s modernization project included:

• upgrades to the database and production server
• the addition of faster storage to improve the old system’s processing capacity
• a new mobile front end

“They’re still running the legacy app and they got everything they needed for $85,000,” he says.

Who decides when to modernize?

Poor legacy application replacement decisions happen when technology decisions are not aligned with business requirements. What’s chosen and how it’s applied can mean the difference between leading or lagging behind competitors in any given industry.

As CTO of CSCI, Anderson is charged with making recommendations to the CFO and CEO. Before he does that, he holds regular meetings with the systems operations lead and the systems development lead. They collectively determine whether the hardware has become outdated and if the current base of developers is capable of accessing or modifying the code.

“If we get to the point where I can’t find hardware or we no longer have the development expertise, we get an uncomfortable feeling that we’re accepting more risk than we should,” said Anderson. “My CEO doesn’t like to accept risk at a time when economic factors are affecting small businesses.”

While highly sophisticated organizations are actively working to improve communication between business and IT professionals, challenges remain. A lot of technicians won’t give the business unit the time of day because they don’t think the business unit respects them enough. And there are business units that don’t respect technicians because they don’t think they listen enough. “If a corporate culture is going to thrive and remain perpetually competitive, there has to be a strong sense of partnership between the business unit and the technology group,” says ASMGi’s Baney.

Managing the legacy modernization process

Norm Ringgold, former Head of IT Operations and Infrastructure for Stanford Linear Accelerator Center (SLAC) manages legacy application transitions in a formalized IT Infrastructure Library (ITIL) Application Lifecycle (ALC) manner that is becoming more common in medium to large enterprises. The idea is that a governing body should make “informed” IT business decisions based upon the business value proposition.

It’s expensive to develop new business solutions. If an existing application continues to accommodate business requirements, and the complete platform, licensing, service, and support model presents a continued value proposition, then why change?

“I usually don’t suggest an application solution change unless a value-based business driver or a technology emergency warrants it,” says Ringgold. “In many cases, an application lifecycle is determined by some sort of significant event, such as a merger or acquisition.”

For example, when Oracle acquired Sun Microsystems and declared to kill the Sun Solaris platform, it created a technology emergency that required global application change. It also opened the door to third-party solution opportunities.

The US Postal Service, where Ringgold worked at the time, had 2,000 servers running Solaris applications. Although events like the Sun acquisition cannot be fully anticipated by customers, it is possible to manage that and other risks in a way that minimizes fallout.

Determining ROI

When a change is indicated — whether by circumstances or astronomic maintenance fees — Ringgold preliminarily investigates whether better ROI could be achieved another way.

If higher ROI seems likely, he presents a suggestion to a review board that includes:

• the cost of doing a more detailed investigation of current business processes
• how the application is performing at that particular point in time
• the options for replacement, including hardware, software, virtual machines, applications, end-user training, and usage costs

He may present a trio of solutions from several vendors upon which a business-based decision can be made. “The business has to have enough information to choose the platform, the application, the vendor solution, and total maintenance cost,” says Ringgold.

“There’s still a place for an SDLC but we’re talking about a more sophisticated way of dealing with it.” Today’s IT leaders’ application management strategy style includes an informed governance entity (with key business and technology representation) involved in every major decision technology decision made. “The partnership ensures the delivery of valuable solutions, as well as timely replacement of less valuable legacy solutions,” says Ringgold.

4 Steps to Modernize Legacy Applications

Legacy transitions often have several points of friction involving people and technology. While having a formal governance body is essential in large organizations, smaller organizations fear such a formality negatively affects their agility.

Smaller companies may push back on the idea of having a governance body. “I remind them that it’s not necessary to have 20 people on it when 3 will work,” says Ringgold.

Companies can die trying to manage application change. “The best way to prepare for it is to put in place a software development lifecycle, application lifecycle management, and a governance body that is capable of accommodating agile change, connected to business requirements.”

As for technology, Baney suggests a four-step approach to avoid oversights.

1. Make sure the documentation is complete

Issues arise when software and systems are not well documented, or the documentation has not been kept up to date. Ideally, the documentation should make it possible to ascertain the real state of the code base, the architecture, integration, and APIs.

2. Determine how stable the application is

Baney checks error logs to determine where defects are and the ripple effect those errors may be causing in the enterprise. It may be that service levels are deteriorating, and the root cause is a particular application.

3. Understand the integration points

This helps you determine which applications are monitoring and communicating with others, and what interfaces you would have to rebuild if something changes.

“You have to have a few meetings in which you say, ‘Look, you have to do a rewrite here, but we don’t want to create a ripple effect that affects you,’” says Baney. “You have to study interfaces and APIs intensely and understand them very well.”

4. Sit with the business unit with the goal of understanding the application’s workflow

It may be that the current workflow is the result of a manager’s personal preference or because it was specifically designed to improve business process efficiency. Walk them through the business workflow. Make sure you’re doing things the right way or see if there are opportunities for improvement.

“If there are opportunities for improvement, tie it to ROI,” says Baney. “If I can cut a claim agent’s claim processing time from 20 minutes to 11 minutes, I just impacted the customer experience. Efficiencies, customer satisfaction, and accuracy all feed into ROI.”

Change is inevitable

How a legacy modernization process is managed can mean the difference between staying competitive or falling behind the competition.

Regardless of an organization’s size, there should be a process for ascertaining what change needs to happen and when it needs to happen. Establish a group of decision-makers who have the dual goals of acting in the company’s best interest and minimizing risks.

While some changes can be anticipated — such as an operating system’s end-of-life date — others cannot. Savvy organizations make change management a priority so that planned and unplanned events can be managed in a way that minimizes unnecessary risks and costs.