The Incremental System Replacement: Why Is It Good for You?

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.

What are the differences between these approaches?

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.

Non-incremental replacement approach

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.

Incremental replacement

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.

What about other options?

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.

How is incremental replacement implemented?

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)

What are the benefits and risks of incremental replacement?

Some of the benefits of incremental replacement are:

• A generally lower risk with moving one piece at a time compared to transforming the entire system at once
• Lower business impact and lower cost of failure
• Quicker result delivery
• Componentized system at the end of the process
• The opportunity to select different technologies or a newer version for later components
• Less management bandwidth required since the work volume at a time is smaller than in the Big Bang replacement
• Easier budget approval compared to total transformation
• KPIs can be tracked and improved at more granular levels

On the other hand, you should also expect some risks when it comes incremental replacement, such as:

• Ending up with each application using a different tech stack due to the absence of monitoring
• Too many components and integrations in case the architecture is not properly planned and implemented
• Merging issues when not managed properly
• Scope definition when the end state is not defined in the beginning
• Versioning issues during concurrent development of two or more modules
• And finally, a set of components that do not function well together as a system

What could you do to minimize these risks?

• Be careful that all relevant management practice is followed
• Ensure that all new modules are consistent with predefined architecture and design
• Build reusable components for future use
• Try to have long-term key resources
• Watch that communication among different concurrent teams is smooth
• Ensure that non-functional requirements are captured and validated for all modules

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.