• Replacing a legacy system using a Big Bang approach is only simple on the surface: it carries a high risk.

• The risk can be minimised by using an incremental solution with parallel operation.

• An incremental solution achieves early demonstrable successes, but requires a complex synchronisation of the old and new systems.

System modernisation includes the replacement of large, historically expanded systems with a number of interfaces. This may be necessary for various reasons: the old systems can no longer be maintained, or new operating processes, organisational changes or contractual regulations necessitate a systems update.

The risk with a system replacement is considerable because it involves deep intervention in the business processes of a company and in the application landscape. The aim here is that the day-to-day business is, if possible, not disrupted, or only to a small extent.

In this blog entry I compare two approaches to system modernisation: the Big Bang replacement and the incremental replacement. Both possibilities are examined for their advantages and disadvantages, and the incremental replacement is explained with the help of an actual project.

At a large logistics provider, a central host system was completely replaced by a new system. The new system had approximately 50 interfaces to external systems and 150 stations that were used to process up to 10,000 orders per day. After selecting the new system, the question was how to manage the migration to the new system.
 

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.

Review

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
 

In the end, the decision for one alternative or the other depends on many factors: budget, time, risk, feasibility of parallel operation, contractual terms and political mood. In some cases, parallel operation is not possible because the systems do not provide appropriate interfaces or options for synchronisation. Then the only possibility is the Big Bang replacement, which has been used successfully for other large migrations.
Ideally, all these factors should be considered before a decision is made. This article demonstrates typical arguments for both sides and highlights a successful example of incremental replacement. However, the appropriate solution should always be selected on a case-by-case basis.