Big Bang: simple, but only at first glance
A Big Bang replacement looks easiest at the rough planning stage and can usually be implemented in the shortest time frame. Progress in specification, development and testing can always be measured at the final state and no intermediate solutions are built, only to be used for a transitional period and then discarded in the final state. However, this apparent advantage is often more than offset by the high risks involved. These include extremely complex implementation processes with many dependencies, and elaborate fallback scenarios to ensure that, even in the event of problems during the "bang", it is possible to switch back without affecting the operational business. To these we have to add extremely high expectations, and a success that will only become visible to the outside world at a very late stage. Minimising these risks demands very detailed planning of the launch and a high number of dry runs.
The critical phase is limited to a very short period of time, and all preparations can be optimised for this one date.
Incremental replacement with parallel operation
In the project being reviewed, an incremental replacement was chosen instead, which mitigated the risks:
On the one hand, partial functionalities were gradually released in the new system and deactivated in the old system. On the other hand, the stations were converted one after the other to the new system, so that at any one station, either the old or the new system was in operation.
The fact that the introduction processes were carried out step by step meant that the complexity and the impact on the application landscape was reduced in each individual step and fallback scenarios could be better planned. It was also possible to gain experience with the new system in operation without having all of the company's critical processes already running on the new system. In this way, real key production figures and runtime effects could be determined at an early stage without affecting the entire operational business. Users were better supported and user problems identified and solved before the next station was switched over.
However, the incremental replacement also made it necessary for the old and new systems to be run in parallel for the transition period, and data synchronicity and data integrity had to be guaranteed. For this purpose, it was necessary to create interfaces and matching mechanisms that were only needed for the duration of parallel operation and were subsequently discarded.
The early go-live production switchover led to management accepting the new system earlier than anticipated due to the early successes that could be demonstrated. This reduced the likelihood that the project would be completely stopped by management during its lifetime, as this would result in the dismantling of the new system.
The entire parallel-operation phase in this project lasted two years and was ultimately successful. At the end of the project, the old system could be shut down without hesitation, because the entire operational business was already running on the new system at that time