After having analyzed the options and ensured business strategy alignment, you have decided to replace your current system. The next step is to select an approach for moving forward. Your options are either to build a new system and to replace the old one at once or to take a phased approach and gradually introduce the new system in stages.
You must find a migration strategy that supports your business needs and that is aligned with them.
What kind of system replacement strategy is the best?
Does a one-time replacement make sense?
What about an incremental replacement?
If you have a big enterprise software solution that is the backbone of your most vital business processes, you cannot just simply install the new software, no matter how simple it is. Before production, you need to be sure that the new solution is working properly and that users are trained to use the new system.
In the non-incremental approach, you would turn off your old system and turn on a new one, and thus implement all the changes at once (also known as a “Big Bang”). This approach consequently supports scalability and centralization.
Well, it’s obvious that just turning the system off at some point is faster, as it does not require heavily detailed planning of phases and milestones. But this approach includes high risks because the whole system goes live at once. Although it allows for a faster transition, it is financially riskier and demands more resources, so you should also count on a temporary lack of productivity in your company in this scenario.
An alternative to a non-incremental replacement is a phased implementation that rolls out new software gradually, introducing the new system piece by piece. This kind of implementation has several smaller go-live dates for each phase of the project, giving your users more time to adjust to the changes. This style of migration also allows users to migrate in stages.
Besides, as a dominant approach to software development, the Agile approach supports phased delivery because of, among other things, a faster realization of ROI and continuous feedback.
It must be said that there is a third option, which is basically running both systems in parallel at the same time. While this method gives your users the opportunity to learn the new software while still having access to the old system and reduces the risks of wrongly implemented functionalities, this option is usually connected with significantly higher costs.
Incremental replacement is conducted by gradually reengineering the old system’s components one by one, and by doing so, carefully building coexistence among new and old components. The most important thing here is the unique architecture which includes both old and reengineered components. In this scenario, the vital thing is to ensure that the old components are here only temporarily. In this way, the system can be used as usual while its components are being gradually replaced.
To be precise, you would have a kind of interface package that intercepts the requests and then activates the corresponding component. These components could be old, restored, or reengineered, and so, the old system is incrementally replaced with a new one as the reengineering process continues. (Iterative Reengineering of Legacy Systems; A. Bianchi, D. Caivano)
Some of the benefits of incremental replacement are:
On the other hand, you should also expect some risks when it comes incremental replacement, such as:
What could you do to minimize these risks?
In any replacement project, no matter if incremental or not, the biggest risk is an internal cultural attachment to old systems and how they functioned.
Finally, it can be said that the Big Bang vs. incremental change is a constant debate among IT and business managers.
Big Bang supporters usually say that there is no other way to introduce a major change to an organization but with a coordinated switch. When facing a fundamental change in an IT environment, the incremental way is hard to implement.
On the other hand, the Big Bang approach with large-scale change is too risky. By dividing a project into many separate, easily manageable phases, the management can see way before the end of the replacement whether things are moving forward in the right direction.
Although both approaches have their time and place, when faced with replacements that are expected to take more than a year or require a change in processes within several organization units, the first choice to consider should be to implement it incrementally. Feel free to reach us if you need some help with this.