18 Sep Leaving a legacy: CIO advice on when and how to abandon old apps
Milwaukee, Wis. – The firms that aggressively have been replacing legacy systems over the past 10 years probably are in the minority, but walking that narrow path has its advantages.
Usually, these are organizations with the foresight to know exactly how non-replacement will affect their business in the coming years, especially the actual cost of maintaining their legacy systems.
For others, the process can be a mad scramble.
Most businesses continue to plod forward, with replacement of legacy systems as a mere back-burner issue. Such organizations know they’ll have to face the legacy music at some point, but they need a push and often the push comes in the form of departure (usually retirement) of key legacy system custodians.
At that point, the organization suddenly finds out nobody really knows the old system as well as the recently departed. If they retired, they often are hired back as consultants while the firm rushes to develop a plan for replacing the legacy. However, these former employees don’t want to work indefinitely, so the firm is under pressure to replace the system.
It’s not an optimal situation in which to replace a system that may have been in place for three decades, with tons of functionality, interfaces, patches, bridges, translators, and other “work-arounds” built in over time.
As we see from chief technologists who have “been there,” there is quite a contrast in value from a proactive and orderly approach and the chaos created by reacting.
Shut-down process
While some organizations opt instead to gradually modernize an application, perhaps adding a new front end while leaving the same back end in place, other businesses proceed full steam ahead.
Once an organization determines that an individual application must be replaced, whether it is done through building or buying or a combination of both, a big part of the task is about helping the end-user make the transition. Employees can become quite attached to the systems (including those old green screens) they have been using for years, and change is very frightening to some.
Mike Jackson, vice president of global business services and CIO of Rockwell Automation, is replacing 400 legacy systems with SAP. Jackson, who comes from the “replace them proactively” school, described a multiple-step, change-management process.
First, he makes sure the application is “officially” on a list of applications that must be closed down, and this list is approved by all senior leaders who must reinforce – frequently – why it’s important to “close things down.”
Second, Rockwell tries to redirect the attention of the change-makers in the business to the new application. Sometimes, the company formally assigns them to the new application project.
“This slows down the drive to keep enhancing the old app and gets them committed to the new app,” Jackson explained. “The change-makers may not be the major users, but they tend to be the most knowledgeable, credible leaders in that function or business unit. People listen to them.”
Third, the corporation stages events to introduce the users to the new application, and has experts answer questions. For some of the major changes, Rockwell may sponsor a “benchmarking trip” to another company that uses the application and give its employees a chance to question their peers at the other company.
In addition, Rockwell formalizes the shut-down process with a dedicated team and a documented process – mostly focused on capturing the key historical data. It then tries to keep it easy for the user by guiding them through the process without burdening them too much with creating the process.
Products with life cycles
Brian Hurdis, president of Metavante Image Solutions and the former CIO for Metavante Corp., said Metavante has not experienced a major overhaul of legacy systems in recent years. It has, however, decommissioned older versions of Internet banking products.
In many companies, the Y2K consolidation accomplished some legacy consolidation in 1998 and 1999, but for those who still have to make this call, he said the key is viewing the decision in the context of products like computers.
“We look at them as products with life cycles,” Hurdis said.
Metavante has a formal process, which was put in place five years ago, that dictates 18 months’ lead time from the time the decision is made to “sunset” a product to the time it’s decommissioned and the company migrates to a newer application. The key in acquiring a new system is evaluating whether it’s truly is an upgrade in terms of functionality and cost of operation. The applicable questions are: How does the organization manage the rollover of technology? And how much will it cost to manage the product throughout its lifecycle?
The availability of people in IT to build and support those legacy systems is another consideration. However, the main trigger appears to be the cost to maintain legacy applications, including costs associated with adding new functionality (which increases the complexity of the system) and the time it takes to make those changes.
“We look at product profit and loss,” Hurdis said. “These are standard business techniques we use to evaluate where we go with products.”
Rumor control
Whether or not the change management issue is overblown, it’s not something a CIO can ignore. It’s important to state the business reasons to IT employees and end-users. The typical IT fear is that the new application will cause company to eliminate the jobs of those who support the legacy system, while end-users are more concerned about learning the new systems than about losing their jobs.
It’s important to communicate early on so that rumors don’t start, and then communicate continually to allow users to build excitement about the technology’s new capabilities. This gives those who need more hand-holding some added training so they understand the advanced features of the system, and it reassures them about the company’s commitment to training before and after implementation.
The organization, in turn, should understand that there may be a dip in productivity while the new application is introduced, which can be mitigated by providing strong post-implementation support to end-users.
In terms of change management, Hurdis advises employee users not to assign their value to the company based on the applications or systems they use, but on the skills and experience they bring to the job.
Related articles
• Patrick Gray: Five steps to buying the right package software
• CIO Leadership Series: Mike Jackson, Rockwell Automation
• CIO Leadership Series: Brian Hurdis, Metavante