Information system conversion has been with us since users of punched-card tabulating systems first moved to vacuum-tube computers. However, it has generally been seen as an afterthought: once the “interesting” development stages of analysis, design and so on are done, it will just happen. This article attempts to view the process holistically, from both the technical and human viewpoints, reflecting the fact that information systems have both technical and human components. It shows how ignoring one side or the other can lead to problems, which can be avoided if all aspects are considered together. It proposes a systematic approach to considering these issues and points out benefits to both researchers and practitioners from using it.
TopIntroduction
Conversion from one information system (IS) to another is common in all organizations, regardless of type, size or location. On the information technology (IT) side, conversion can involve hardware, operating system (OS), database management system (DBMS) and the database it supports, and/or application portfolio. On the human side, procedures must be changed and people must be, if not changed, at least moved (in the sense of change theory (e.g., Schein 1990), not geographically) and retrained.
Effective management of conversion is vital to the long-term success of any IS. Choosing a conversion strategy from one information technology environment to a new one is not easy. A conversion effort may affect any of the four IT components to varying degrees, as well as the human and procedural components of the IS as a whole.
The existing literature focuses on either the technical or human side of conversion, the latter often under the broader label “implementation.” This leads to a narrow view of the issues, treating IT and the human components of an IS in isolation from each other, and can lead to local optimization at the expense of global optimization.
The aim of this article is to provide an overall framework of information system conversion, including all aspects of the information system. It also updates the literature to provide a 2008 view of conversion, both to provide guidance to professionals faced with a new conversion situation and to serve as a basis for future research in this area.
A Note on Terminology
Some writers use conversion to refer only to the technological (IT) aspects, calling either the human side or the entire process “implementation.” Here “conversion” will refer to the entire process. We will use more specific terminology (such as “IT conversion”) for its subsets when necessary to avoid confusion.
System Components And Conversion Framework
An information system consists of five components: hardware, software, data, procedures and people (originally Kroenke 1981; more accessibly today in, e.g., Kroenke 2009). Figure 1, adapted from that source, shows the relationships.
Figure 1. Five components of an information system
All five IT components must be considered in any conversion. Conversion of any element may impact elements to either side. For example, database conversion will affect usage procedures (to its right); a new application may require hardware changes (to its left).
TopIt Conversion Methods
The literature, including standard textbooks such as (Baltzan & Phillips 2008) and (Stair & Reynolds 2008), generally recognizes four conversion methods:
- •
Direct cutover1: an entire organization stops using the old system at one time and begins using the new one immediately thereafter. (This may be after a natural activity break such as overnight.) The organization ends one day using the old system, begins the next day with the new. This is the riskiest method: Lee (2004) discusses how the Nevada Department of Motor Vehicles gave itself problems by using it. Other methods reduce this risk.
- •
Pilot conversion: Part of an organization uses the new system while the rest of it continues to use the old. This localizes problems to the pilot group so support resources can focus on it. However, there can be interface issues where organizational units share data.
- •
Phased (modular) conversion: Part of the new system is introduced while the rest of the old one remains in use. This localizes problems to the new module so support resources can focus on it. However, there can be interface issues where modules share data.
- •
Parallel conversion: The new system is introduced while the old one is still in use. Both systems process all activity and the results are compared. Once there is confidence that the new one operates properly, the old one is shut down. Because parallel conversion isn’t as useful today as some people believe (and many authors suggest), it is discussed separately below.