The Modernization Problem, Part 1 

Download Article Article in Digital Form

Informally, a legacy system may be defined as technology or software application environments that may be replaced by newer or more modern technology, but because of prohibitive cost, lack of detailed knowledge and, in some instances, effectiveness within the current context, the system continues to function and provide services to the organization. The intellectual capital stored up in legacy systems often represents a significant organizational asset; therefore, the management of these long-term systems is critical to organizations as they are not easily replaced.

The concept of software evolution has been in existence for many years. For example, J.I. Schwartz said the following at the second North Atlantic Treaty Organization (NATO) Software Engineering Conference in 1969:

Managers must be willing to adapt as situations arise requiring changes in scope or technique. The basic system must, through such means as data description divorced from procedures, centralized data maintenance, and data-independent programming languages, be flexible enough to permit change and evolution without reprogramming. People must be flexible enough to tolerate rather drastic changes in direction.

Drivers of Change

Organizations have made significant capital investments in their underlying software systems, and the expectation is that they will see a return on these investments and, consequently, that software will be usable for a good number of years. The life span of software is variable, but there are numerous examples of large systems remaining in use for more than 10 years. In fact, many large software installations remain in use for more than 20 years (e.g., systems at insurance companies and banks).

The business drivers for legacy modernization are numerous and provide good incentive for organizations to embark on these projects.

Business drivers include:1

  • Increasingly higher costs associated with maintaining and upgrading these systems
  • The risk associated with running potentially unsupported software
  • Graying of the labor pool as experts on the legacy system age (e.g., shortage of Cobol programmers. Cobol is more than 50 years old, yet a large portion of legacy systems have been written in Cobol.)
  • Low levels of legacy systems integration capability and inflexibility with respect to responding to changing business demands

The reality is that although legacy systems possess numerous limitations, such as green-screen interfaces that lack the conveniences of modern applications (i.e., drop-down menus, instant help files, intuitive navigation), approximately 70 percent of today’s organizations’ core business systems are legacy applications that are still heavily relied on to provide mission-critical business functionality.2

Addressing the Problem—Rip and Replace

It is common knowledge that organizations regularly replace outdated equipment and machinery with newer and more modern systems. This is not generally the case with software systems and, in particular, legacy systems. These types of projects may lead to significant risk, including:

  • Incomplete legacy system specification
  • Business processes and legacy systems codependency
  • Undocumented and embedded business rules
  • New software development risk

Incomplete Legacy System Specification
In most instances the original documentation of the system has been lost or is not representative of the current version of the system. The implication of this lack of adequate documentation is manifested as:

  • Increased risk to the organization when implementing changes to the system in response to external or internal forces
  • Higher maintenance costs
  • Increased cycle times for introduction of new products and/or services that rely on underlying system changes

Business Processes and Legacy Systems Codependency
In most instances, the organizations’ business processes have evolved around the underlying legacy system implementation and would have been designed to work around or avoid any software weaknesses. The importance of the relationship between the business process and the system often becomes clear when projects are undertaken in an attempt to change a process without touching the supporting legacy system module. In these circumstances, the codependency condition has the potential for disruptions in production operations.

Undocumented and Embedded Business Rules
Important business rules may be embedded or hard-coded into the software and may not be documented elsewhere. A business rule is a constraint that applies to some business function; the implementation of new systems that break these constraints can result in unpredictable consequences for the business. Programmers come and go and business rules that have been codified over the years by multiple programmers are difficult to understand by an individual or group new to the system. In these circumstances even routine programming changes may expose organizations to unintended consequences that may give rise to financial impacts (third-party claims), reputational damage and even regulatory breaches.

New Software Development Risk
Software development is an activity that has a significant amount of uncertainty that is usually manifested as possible risk materialization.3 The well-known Chaos Report by the Standish Group in 1994 indicated that 16 percent of software projects were successful; 53 percent were challenged as a result of cost overruns, budget overruns or content deficiencies; and 31 percent were cancelled. This risk is magnified for new software developments involving interaction with legacy systems. The absence of a fully documented environment, aging infrastructure and a lack of standards contribute to an increased possibility of project failure. While keeping such legacy systems in production avoids replacement risk, this has to be balanced against the rising costs of maintaining the aging system.

Adopting Modernization as a Strategy

While recognizing the value of existing systems and the risk involved in their replacement, organizations are realizing the value of adopting a modernization strategy as opposed to replacement. A 2010 survey conducted by NASCIO identified legacy modernization as one of the top 10 activities that organizations were planning to carry out in 2011.4

Modernization involves more extensive system changes than regular maintenance and results in the preservation of significant portions of the legacy investment while at the same time executing activities such as:

  • System restructuring
  • Enhancing core system functionality
  • Modifying software attributes

Organizations recognize that a modernization of programs represents a viable approach to upgrading legacy environments when risky and pervasive changes are needed to address changing business requirements.5

Modernization is the preferred approach to system evolution when the legacy system provides significant business benefit, but the growing complexities associated with system maintenance results in overall increased risk for the organization. In the main, there are two broad approaches to legacy system modernization:

  1. White-box modernization—This approach is largely predicated on an understanding of the existing system, facilitated through the use of existing documentation or, in most instances, the execution of a reverse-engineering process. This is often a labor-intensive exercise, and vendors are continuously coming out with new tools to facilitate automated system information discovery.
  2. Black-box modernization—In contrast, black-box modernization is not concerned with the inner workings of the system to be modernized. The main focus of this approach lies in understanding the interfacing elements of the operations of the system. The fundamental idea is to wrap a layer of code around the legacy system to hide the complexity and expose a modern interface for interaction with other systems.

The decision to replace a system as opposed to ongoing maintenance or modernization is usually predicated on the inability to justify the cost of maintenance or modernization efforts against the cost of acquiring a new system. The decision to utilize replacement as the route to system evolution must be evaluated against the inherent implementation risk associated with new system developments, since the system being introduced typically is not as stable as the old system. Additionally, consideration must be given to risk associated with the implementation of a new technology unfamiliar to supporting personnel. Therefore, when deciding upon a plan of action, organizations must gain an appreciation of the potential risk and develop mitigating plans through the application of an appropriate risk framework (e.g., COBIT 5 or Risk IT) to feed into the final decision.

Next Steps

The question facing organizations that have decided to embark on a modernization program is how to achieve the necessary agility while maintaining operating effectiveness, especially in those circumstances where the legacy system resides on either a mainframe, AS/400/IBM i, OpenVMS/Unix or Windows client server-type platform.

Part two of this article, to be published in volume 2, 2013, will examine some of the techniques available to organizations as they embark on modernization projects and will discuss the questions surrounding:

  1. Writing a new application from the beginning
  2. Application migration and the use of service-oriented architecture (SOA)
  3. Application reengineering, through the execution of functional transformations to generate either a more modern representation on the existing platform or multiple instantiations on multiple platforms
  4. Application revamping, via updating the presentation layer of the legacy system without touching the underlying application code


1 Hyland Software, “The Trouble with Legacy Systems,”
2 Loma, Paehr Roger; “Legacy Modernization: Creating an Agile Enterprise,” November 2007
3 Boban, M. Pozgaj; H. Sertic; Strategies for Successful Software Development Risk Management, vol. 8, 2003, p. 77-91
4 NASCIO, “State CIO Priorities for 2011,” 2010,
5 Microsoft, “The Business Value of Legacy Transformation,” July 2007

Kirk Henry is head of the information and communications technology (ICT) department at the Trinidad & Tobago Unit Trust Corporation, the largest mutual fund provider in the Caribbean region. Henry has extensive experience in ICT governance, strategic planning and application systems development. He is currently spearheading a legacy modernization program that is based on his postgraduate work at the University of the West Indies, St. Augustine campus. Henry can be reached at

Enjoying this article? To read the most current ISACA Journal articles, become a member or subscribe to the Journal.

The ISACA Journal is published by ISACA. Membership in the association, a voluntary organization serving IT governance professionals, entitles one to receive an annual subscription to the ISACA Journal.

Opinions expressed in the ISACA Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors’ employers, or the editors of this Journal. ISACA Journal does not attest to the originality of authors’ content.

© 2013 ISACA. All rights reserved.

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, MA 01970, to photocopy articles owned by ISACA, for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.