Legacy applications are one of the most difficult issues to face within IT. A rip-and-replace approach is expensive and thus difficult to justify; plus, it tends to interrupt operations. Meanwhile, the aging software lingers in accounting's ledgers, overstays its welcome in sales and causes poor network performance throughout the organization.
And it gets worse. An old mapping application in a transportation department, for instance, is a disaster waiting to happen. As the months and years go by, the application grows more outdated and the problem becomes harder to address.
In the examples below -- each featuring a slightly different legacy application problem -- the key to finding a solution involved business analysis. IT staffers helped figure out how the legacy app was being used, in what ways employees depended on it and how the company would be affected by a disruption in service if the software were to fail. Such failures, of course, typically lead to a loss of productivity that continues during the time needed to install new software and train employees to use it.
"A core element in all these cases is that the existing portfolio [of IT applications] ought to be continuously managed for its balance of delivered value to cost and risk," says Jim Duggan, a Gartner analyst who studies enterprise IT applications.
Of course, how these companies balanced the value of software against its cost and the risk of failure, and the factors that pushed them to finally make an upgrade, varied depending on the specific business need and the exact nature of the legacy app problem.
Hudson's Bay Company and Lord & Taylor
Problem: A merger renders existing ERP systems obsolete.
Solution: Wholesale ERP replacement to meet the needs of all divisions.
Hudson's Bay Company, established in 1670, is one of the oldest retail chains in Canada. The company also owns other popular chains, including Home Outfitters and Zellers. In 2008, Hudson's Bay was purchased by NRDC Equity Partners, which owns Lord & Taylor, an upscale department-store chain.
Together, the two companies employ about 75,000 people and generate more than $8 billion in sales, so the merger presented some challenges. One was the fact that Hudson's Bay and Lord & Taylor were both happy with their respective ERP systems, which came from different vendors, but neither system could handle the needs of both organizations. (The previous systems, which Hudson's Bay declined to name, ran on IBM mainframes.)
One of the main purposes for which Hudson's Bay uses ERP is to manage deliveries to its stores. "When we order merchandise from a vendor, sometimes it comes in from Europe and we know about how many we need by store, but it might be months before it is delivered to our company," says Dan Smith, CIO of Hudson's Bay. The resulting delay, he adds, "may change how much you need for one store versus another." Store employees often have to wait until the merchandise arrives, open the containers and then route them to other stores as needed, he explains.
Hudson's Bay decided it needed to replace its older systems with one overarching ERP system for all stores. Executives knew they wanted to move away from their mainframe systems and instead use newer blade servers; the mainframes had many problems, including the headache of finding Cobol programmers to maintain the old ERP software. The company upgraded to supply-chain management software from Manhattan Associates partly to gain the ability to determine exactly what was being delivered to stores and when it was arriving.
Some of the benefits that the upgrade yielded included process improvements, labor savings (which Smith chose not to detail) and the ability to consider future acquisitions that could be easily transitioned onto the existing supply-chain software.
Of course, Smith says, the overall project presented challenges, too, including the need to integrate the systems for the combined companies and the need to train staffers on the new process.
Julie Lockner, a data management analyst at Enterprise Strategy Group (ESG), says all mergers are complex, but they're especially complicated for retailers that will need to address compliance issues and figure out how old data sets will be maintained after moving to one companywide system.
If data is going to be merged into a single application, she says, companies should "[have] a plan for data retention and legacy application retirement at the outset" in order to minimize the chances that any application will become "a source of pain years later."
For his part, Gartner's Duggan says Hudson's Bay faced a very complex series of problems: legacy apps that mostly worked but didn't meet the needs of the newly merged company; a large-scale implementation across multiple locations; and the political concerns that typically arise when different corporate cultures come together. The main issue, he says, is that complexity leads to high costs, and IT has to make business continuity a priority.
"A major factor in mergers and acquisitions will be the attitude toward business process standardization," says Duggan. "Political concerns often result in multiple processes where only one should exist. IT can federate some processes when that is needed, but using IT to mask an inability to enforce consistency can result in costly, unreliable operations."
Problem: Infrastructure makes adding new CRM features difficult.
Solution: An infrastructure extension for now, but the ultimate goal is to move to the cloud.
Jim Finwick knew the writing was on the wall. As the CIO of Compassion International, a Colorado Springs-based Christian organization that helps children in developing countries, Finwick noticed that an existing home-built customer relationship management system called Compass was showing its age. Built on Sybase PowerBuilder, the CRM system wasn't scalable, didn't have an open API and had no way of collecting detailed information about sponsors.
"We had all of these connections that were wired together, and not in a standard way, that created this level of fragility. We knew we needed more flexibility and stability," says Finwick.
His fears were realized in November 2010, when the Compass CRM system froze completely, leading to a half-day of downtime and the loss of about $500,000 in donations. Because Compassion works with 10 regional centers and 25 offices throughout the world that help arrange donations, it needed to minimize the number of software patches and connections its system required. The organization decided to move to a cloud-based IT infrastructure, built partly on the Microsoft .Net framework and partly on Neudesic Neuron, an enterprise bus server that connects diverse systems.
One of the organization's goals is to create a one-to-one relationship between sponsor and child. It has to be able to reassure contributors that children aren't being sponsored by multiple people. That means coordinating data about a child who lives in one country with data about a sponsor who lives in a different country. Ideally, a U.K.-based sponsor, for instance, will be able to get information quickly about a child who needs help, even if that child lives on another continent. That level of integration would not have been possible with the stand-alone CRM system, but it's possible in the cloud.
So far, Compassion has upgraded the Compass database to run on a hosted platform using several technologies, including Neudesic. And Bleum Inc., an IT outsourcing company based in Shanghai, added Web services to the Compass CRM system to help the group get by in the short term. But further out, Compassion plans to upgrade to a full cloud-based ERP system. Finwick would not say when that will happen.
ESG's Lockner says Compassion is on the right path, but she advises the charity to continue to bring users -- employees and churches and other approved groups using the system -- into the loop as it investigates cloud-based ERP systems. With a cloud architecture, the organization may need to train users on what to do when the Internet is down or provide a way to make data available offline. She says it is important to make sure users have the same level of functionality in the cloud as they do when the data is local.
Problem: Messaging platform is several versions old.
Solution: A series of in-place upgrades to the latest version.
At Flexcon, a Spencer, Mass.-based maker of pressure-coated films and adhesives for labels, a Lotus Notes messaging platform was becoming seriously outdated.
For Jeremiah Benjamin, the company's collaboration and tech support leader, the problem turned into a weekly support headache. For example, the system could not correctly render rich emails -- those that use complex graphics. The company also could not accommodate some add-ons for specific handheld devices because of the extra costs involved. Moreover, it took several days just to book a meeting room and match the room's size with the number of participants, says Benjamin.
"We had not done any upgrades in quite a while, and we patched [only] to fix specific problems. There were a lot of upgrades we had not done," Benjamin explains. "We needed to get things up to date."
Benjamin first started noticing problems a few years ago, when the company's version of IBM Lotus Notes failed to recognize some modern smartphones, including Android devices and Apple's http://www.computerworld.com/s/topic/75/Smartphones. He also had trouble integrating new versions of applications, such as those in http://www.computerworld.com/s/topic/75/Smartphones Office, with Notes.
Because it had missed several upgrades, Flexcon undertook the fixes in steps, first going from Notes 4.6 to Notes 6.5. Then, in 2009, the company upgraded Notes and its Domino server from Version 6.5 to Version 7. The goal was to finish the upgrade before vendor support for the 6.5 release ended in 2010. Finally, in early 2010, Flexcon upgraded its Domino 7 server environment to Notes 8.5. Notes client upgrades were completed last year, and the company is now up to date on all of its Notes releases.
Benjamin says he used a variety of tactics to make the upgrade process a smooth one. He tested extensively and used Twitter to get advice from experts. He had paid for IBM support but rarely used it with the older version; however, he made frequent support calls during the upgrades from Notes 6.5 and 7 to Notes 8.
The main benefit now is that Flexcon's IT team is prepared for the introduction of new consumer gadgets into the enterprise: When an executive brings in an iPad or a smartphone, Benjamin knows Flexcon has the server and client versions needed to support the latest models.
"After this, I made the decision to always upgrade the servers within weeks of any release so as to always be current," says Benjamin. "The main benefits are supporting the latest devices, providing strong security, consistent user experiences and continual increases in performance."
Gartner's Duggan says that skipping upgrades tends to lead to an increase in security risks and a reduction in the software's value. Flexcon was wise to address the legacy situation before the problems became harder to fix and the upgrades grew even more difficult to deploy.
And here's another problem that Flexcon encountered as a result of skipping upgrades: "They no longer had timely support for new technologies but still paid for them in the yearly maintenance fee," says Duggan.
Duggan advises IT shops to always stay within two releases of the latest version. He describes a strategy known as N+1. In that approach, most users would be on the last major upgrade (N) of the software -- not the most current release, but the one before that. Meanwhile, advanced users would be testing the most current release (N+1) and casual users would be two releases behind them (N-1), gradually catching up to the main group of users.
In the end, every aging application presents complex IT challenges -- analyzing the business process, figuring out the cost of the upgrade, dealing with the vagaries of training and retooling. As Duggan says, once any application hits production, it is instantly labeled "legacy" -- and in many ways, that means IT should start planning how the application will be upgraded, replaced or outsourced before it is even fully deployed.
John Brandon is a former IT manager at a Fortune 100 company who now writes about technology. He's written more than 2,500 articles in the past 10 years. You can follow him on Twitter (@jmbrandonbb).
This story, "Legacy application fixer-uppers" was originally published by Computerworld.