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.
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.
The project was co-financed by the European Union from the European Regional Development Fund. The content of the site is the sole responsibility of Serengeti ltd.
Get a Quote
To get an accurate quote, please provide as many details as possible. One of our key account managers will contact you back with a custom quote for your project.
Manage Cookie Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.