Parallel adoption is a method for transferring between a previous (IT) system to a target (IT) system in an organization. In order to reduce risk, the old and new system run simultaneously for some period of time after which, if the criteria for the new system are met, the old system is disabled. The process requires careful planning and control and a significant investment in labor hours.
Overview This entry focuses on the generic process of parallel adoption. Real-world examples are used to provide a more meaningful interpretation of the process if necessary. Additionally, a process-data model is utilized to visualize the process, aiming to offer a comprehensive overview of all the steps involved in parallel adoption. However, the emphasis will be on the unique characteristics of parallel adoption. Some common characteristics, particularly those related to defining an implementation strategy, that apply to all four generic types of adoption are described in Adoption (software implementation).
Other kinds of adoption Besides parallel adoption, three other generic kinds of adoption can be identified. The choice for a specific adoption method depends on the organizational characteristics; more insight on this topic will be provided below. The three other adoption methods are: Big bang adoption/Plunge Adoption: A big-bang adoption entails transferring the entire organization from the old system to the new system in an instant changeover. This is the cheapest option but if the new System fails, the organization is in big trouble. It also opens risks for the system not to be accepted by its users. However, this may be the only approach to take when the two systems can not coexist or activating the new system is an emergency. Phased adoption (also known as gradual conversion): In phased adoption implementation, the organization is gradually transferring to a new system in different phases, per module or sub-system. Some systems are incapable of being introduced in pieces as it is too reliant on the whole system. Using phased adoption has fewer risks, but causes the most disruptions due to it taking the most time to transfer from the old system to the new. Pilot adoption: The pilot adoption method is used for large organizations that have multiple locations or largely independent departments. The new system is introduced in one of the locations or departments and extended to other locations or departments over time. (limited boundary if a new system is a failure) (Turban, 2002) In some cases, parallel conversion may not be a suitable strategy. For example, if the new system has significant schema changes that result in data elements not being populated correctly, it can lead to data inaccuracies or corruption. Additionally, if the system relies on commercial off-the-shelf (COTS) technology and the vendor's documentation specifies that multiple applications cannot share the same database, parallel conversion may not be feasible. For instance, products like Oracle's Siebel may have such restrictions. Similarly, other COTS products may have limitations when it comes to patches or major upgrades that require unique license keys, potentially causing issues with database changes and system functionality.
Place in implementation process There seem to be little conventions regarding the process of parallel adoption. Several sources (e.g.: Turban, 2002, Eason, 1988, Rooijmans, 2003, Brown, 1999), do not use a single process-description name. The term parallel adoption is denoted in these sources, although consistent per source as: parallel conversion, parallel running, shadow-running, parallel cutover and parallel implementation. This appears to be the case because a generic description of the process does not need a distinct classification. There are quite a few standard implementation methods, where different adoption techniques are described but often in a practical context; real-world case scenario or a more comprehensive set of implementation techniques like Regatta: adoption method, SIM and PRINCE2. In general, parallel adoption can best be seen as a systems engineering method of implementation of a new system.
In principle, the parallel adoption method is different from the decision to change a system in an organization and can be seen as one possible mean to achieve that goal. However, there are quite some factors that are being taken into account in determining the best implementation strategy. Moreover, a successful implementation can depend to a big extent on the adoption method. (Lee, 2004)
The process The parallel adoption process can not be represented without paying attention to the steps before the actual conversion, namely the construction of a conversion scenario and the identification and testing of all the requirements. Therefore the process is explained by going through all the identified processes in figure 1, while addressing the common activities that are necessary for any of the identified conversion strategies briefly.
Figure 1 gives an overview of the parallel adoption process. The left side depicts the flow of activities that contribute to the process. Activities that run simultaneously are preceded by a thick black line. When the parallel running of activities is over, the activities are joined again in a similar black line. When there is no arrow from an activity to another, this indicates that they are aggregates of a bigger activity above. The activities are divided in four main phases:
Define implementation strategy, that deals with the kind of implementation strategy should be executed. Pre-implementation, which has to do with constructing a planning of all aspects and requirements involved in the implementation. Prepare organization The organization should be prepared properly according to the previous phase. Conversion deals with the actual conversion process and closing the conversion process; proceeding with the new system.
The main phases are subdivided in other activities that will be described briefly in tables 1-1 to 1-4.
The right side of the model describes the data involved in the processes. Some of these concepts, depicted as a pair of overlapping open rectangles, can be subdivided in more than one concept. A pair of overlapping closed rectangles indicate a closed concept which means that it can be subdivided in more concepts, but it is not of further interest for the parallel adoption process. The diamond shapes figure indicates that the concept linked to it, serves as an aggregate concept and that this concepts consists of the other concepts. Finally the open arrow represents a super class-subclass relation. The concept linked with the arrow is the super class of the concepts that are linked to it. This syntax in figure 1 is according to Unified Modeling Language (UML) standards. The concepts in figure 1 are defined in table 2. More context for these sub activities in the process will be given underneath the tables.
table 1-1: Pre-implementationActivityDescriptionDefine implementation strategyThe implementation strategy is determined in this early stage. (Brown, Vessey, 1999)Create master implementation scriptThe first initial requirements analysis is made, consisting of the requirements below. (Venture, 2004)Construct Time planningA first time-planning of the implementation process is being constructed. (Rooijmans, 2003)Define Organizational requirementsThe organizational requirements are defined here (Rooijmans, 2003). Define IT requirementsIT requirements are determined (Rooijmans, 2003)
table 1-2: Prepare organizationActivityDescriptionInstall requirementsIn order to prepare the organization, the defined requirements are installed. The organization is being prepared and the IT installed on test-machines. (Rooijmans, 2003, Eason, 1988, Microsoft, 2004)Test requirementsThe requirements are tested to see if the organization is ready for the implementation (Rooijmans, 2003)Redefine master implementation scriptThe master implementation script is refined with the new information gathered in the process with the activities below. (Rooijmans, 2003)Define criteria indicatorsIn order to test the new system, criteria indicators are being created. (Rooijmans, 2003, Microsoft, 2004)Formulate workaround/rollback planAlso, a workaround plan with a rollback scenario is made. With these plans, the organization can respectively attempt to correct the mistakes that are made and fall back if the implementation in a certain stage of the process fails. (Microsoft, 2004, Rooijmans, 2003)Perform (segmental) Test conversionIn very complex organizations it can be beneficial to perform a test conversion, before going “live”. (Microsoft, 2004, Rooijmans, 2003)
table 1-3: ConversionActivityDescriptionMake catch upsThe conversion process is started, a number of activities run parallel. During this stage, catch ups are being made using the old system. The old system is leading, but the new one runs parallel. All changes in the system, have to be put in the new system. (Microsoft, 2004, Rooijmans, 2003)Control systemThe system is being controlled at all times by the control system. With the defined indicators and system run characteristics, errors and mistakes are tracked down. (Microsoft, 2004, Rooijmans, 2003)Run leading old systemThe old system is leading; processing the actual data. Run new systemThe new system is running parallel with the old system and is closely monitored. (Microsoft, 2004, Rooijmans, 2003)Translate catch ups in new systemIf the criteria are met, the catch ups are translated and transferred in the new system and the conversion process comes in its next stage. (Microsoft, 2004, Rooijmans, 2003)Execute workaround / rollback strategyIf the criteria are not met, the workaround strategy or rollback strategy is performed, depending on the nature of the errors. (Microsoft, 2004, Rooijmans, 2003)Make catch upsCatch ups are made for safety purposes, even when the new system is leading. (Microsoft, 2004, Rooijmans, 2003) Run old systemThe old system runs as a backup, for safety purposesRun leading new system(1)The new system is leading and in full operation. All the transactions and changes in the system are being handled here. (Microsoft, 2004, Rooijmans, 2003)
table 1-4: Closing parallel adoptionActivityDescriptionRun leading new system(2)All catch ups and controls are closed down. The new system is the only system in operation. (Microsoft, 2004, Rooijmans, 2003)Disable old systemThe old system is not necessary anymore and is disabled. (Microsoft, 2004, Rooijmans, 2003) The concepts from figure 1 are defined in table 2-1 below.