In the end, it doesn’t matter whether technical, commercial or professional reasons make it impossible to continue operating a software solution in a way that makes sense. The important thing is that if you want to replace software, a successor is usually needed. But how should you shape the transition? Does the transition have to be carried out without interruption, or at least for a limited period of time?
The first impulse is often to carry out a “soft migration”. A new solution is built while the old solution continues to operate. Data and business processes are migrated without disruption of operations, risks are kept as low as possible or eliminated altogether, and “suddenly everything is done and no one has noticed”.
Another way to go about it is the “Big Bang” approach. When the old software will be replaced and the users will switch to the new system is determined down to the second(and also postponed sometimes). This point in time tends to be very stressful, as it is not easy to judge whether everything will work, or at least everything that is essential to operations.
In the following, we want to clarify the conditions under which a smooth migration succeeds and what there is to take into consideration with the Big Bang approach.
When can a soft migration be carried out?
The question of how a soft migration can be carried out cannot be answered in general terms. A virtually unlimited number of options arise from circumstances such as the existence (or nonexistence) of suitable other systems, the specific migration task, various ways of breaking the overall task into subtasks, and the retaining or merging of technical processes.
However, what can be answered in a general way is the question of the necessary preconditions for successful migration. So let’s ask ourselves the following questions:
Does the old solution have the necessary modular structure that corresponds to the independent technical processes and subprocesses and data management?
Is it possible at all for the old solution to be changed so that it can support soft migration?
Are sufficient personnel capacities available or can they be built up to maintain parallel operation over a reasonable period of time? Is there sufficient know-how in terms of the business processes and technology?
Does the greater level of security justify the additional costs for multi-stage software updates for the old and new solution, along with higher personnel costs?
Can the primary external interfaces be addressed simultaneously by the old and new system? Can realistic interface emulators be provided at a minimum?
Were you able to answer (nearly) all questions in the affirmative? Then smooth migration should succeed. If not, then the Big Bang must be systematically prepared. It’s not uncommon for organisations to continue to pursue a soft migration for far too long, which ultimately means that an ill-prepared Big Bang migration ultimately has to be carried out.
Big Bang migration – if you’re gonna do it, do it right!
A Big Bang migration, that is, replacing the existing software in one fell swoop, isn’t that bad of an idea – but certain aspects must be given priority when you are in the preparation stage:
The hours surrounding the go-live must be meticulously planned and provided with “decision gates” for management. This also includes staff planning that ensures that all relevant persons are available.
A test plan with optimally automated tests allows the new solution to be quickly tested immediately after go-live.
To roll back the migration in an emergency, the emergency procedures of the old system pertaining to system failure must be up to date, and the staff must be well acquainted with them.
Advance training on the new solution must enable the staff to carry out regular operation and deal with the exceptional situation of the moment of go-live.
Procedures for importing configuration adjustments and software patches must be worked out with the supplier.
Capacity for timely (further) development of the system must be made available.
What can we learn from this?
It’s not easy to make a decision about the appropriate method for migration. However, in order to actually have the option of making a decision, the necessary preconditions must have been put in place in advance.
A soft migration may take more time and involve major work on the old solution together with the internal and external experts on that system. This is also one reason why migrations are easier when the old and new systems have the same manufacturer.
In any case, careful use of the method and a good understanding of the goals behind it, as well as involvement of all people concerned, are crucial for achieving overall success. Then it will be possible to ensure the success of the transition to the new solution!