Lift-and-Reshape strategy From Business case to successful replatforming
Outdated IT infrastructures often pose risks in terms of stability and security. The danger: a total failure. To prevent this, companies should regularly check, question and possibly replace their platforms.
If an application is to be lifted to another platform, there is a chance to break up deadlocked structures.
For modern, functional and secure IT solutions, entire infrastructures do not have to be created directly. A lot can already be achieved with existing tools and technologies. At the same time, the integration and use of individual additional services can have a great effect.
At a certain point, drastic changes are still necessary to achieve the desired effects – regardless of whether it is more performance, stability or security. With such comprehensive replatforming processes, developers should therefore pay attention to the following points:
Step-by-step implementation for better troubleshooting
A system landscape consists of various components: central back office components, such as ERP and PIM systems, the respective platform itself with all its components and additionally connected third-party systems.
If a replatforming process is pending, it is often driven from the business operations area. This is usually due to the desire to directly replace other systems or add new functions. So everything would be done at once.
However, especially in the case of complex changes, integration problems can arise. Too many “moving targets” increase the complexity of the project. This makes error analysis and the anticipation of integration problems even more difficult. Through a step-by-step implementation, developers can locate and fix any errors faster.
Setting realistic goals
Of course, perfect replatforming rarely reflects everyday business life. A careful, step-by-step approach costs more time and thus collides with ambitious go-to-market ideas. Nevertheless, it should be prioritized and systematic. For this purpose, critical problem points of the infrastructure must first be identified.
If it is no longer possible to update components to ensure smooth operation, or if it requires too much effort, or if the system is no longer responsible from a technological point of view, action must be taken. This is followed by an evaluation of the technical options in order to modernize and expand the existing infrastructure in a meaningful way. Here, in addition to the defined business requirements, attention should be paid to stable and safe operation.
At the same time, costs also play a role. Certain core components such as ERP systems are usually expensive and are based on license models with corresponding terms, which is why it is usually not worthwhile to have several of them in use at the same time to cover the same functional area.
Pay attention to simple implementation
Once the decision has been made regarding the components to be adapted, it is time for implementation. In the best case, it is an API integration. Here it must be ensured exclusively that the old component can be switched off and the new one can be switched on.
However, this case also applies only to applications that do not require a comprehensive data basis, otherwise the data migration must also be prepared in order to ensure data consistency and adapt data structures. As a possible fallback plan, parallel operation of the new and old components is often recommended here.
Creating fallback strategies
With regard to the deployment in the course of a replatforming, a careful approach is also recommended. In recent years – driven by best practices in Continuous Integration and continuous Deployment (CI/CD) – one approach to this is the “Blue/green deployment”.
On a scalable system, the new component is only rolled out for a small percentage of users. In this way, it can be checked for the occurrence of possible errors. If this is the case, go back to the old system. With a smooth process, the distribution is gradually expanded until the new component is fully rolled out.
However, this approach can only be used in certain scenarios, because it requires specific infrastructure capacities and applications that allow a corresponding procedure. Alternatively, the specialists can use rolling deployments or phased rollouts.
It is important that the load balancer used supports user persistence so that the dedicated user traffic is always communicated to the same container /server. Now there are scenarios in which parallel operation is not possible.
In order to implement the most frictionless replatforming possible, a classic “staging” is necessary. Attention should be paid to good test coverage with well-thought-out test scenarios and the highest possible test automation. The two most common approaches for testing here are “Test Driven Development” (TDD) and “Test After Development” (TAD).
Since replatforming is often accompanied by new features, tests must also be carried out at different levels, such as unit tests, integration tests or end-to-end tests. The success of all tools, including the automatic updating of components, is based on a solid test concept.
Change as an opportunity
When replatforming, it is important to question the status quo. This includes putting all existing processes and functions to the test. As risky as such IT projects can be, replatforming is first and foremost an immense opportunity to break up deadlocked structures and meet new requirements.
It is important to have a good prioritization and critical analysis in order to be able to assume technological responsibility. Here, developers are asked to show their employers possible solutions and to create IT structures that enable successful, safe and trouble-free work.
* Bernd Alter is Technical Director at Turbine Kreuzberg. For more than 15 years he has been working at the technology agency with the conception and technical management of software projects. His specialty is PHP, accompanied by infrastructure topics (Docker/Kubernetes and cloud) as well as the development of software and system architectures.
