A new, agile approach to simplify migration of highly coupled systems
In many companies' system landscapes there lurk various legacy systems that should ideally be immediately replaced. However, migrating away from these systems often proves to be extremely difficult. In particular, the dependencies on other systems are a huge problem in such migrations. We have been confronted with such challenges for our customers. Our approach that has shown itself to be very successful is Agile Migration.
Application Migrations in complex System Landscapes
Even if reengineering is our preferred method in most cases, there are cases where other approaches make sense. For instance, if there is a standard product that completely covers all requirements, or if there is another application in the system stack that fulfils the same tasks and is to be adapted to replace an old application. For such projects the question is often how to carry out the actual migration from the old to the new application. In very simple cases, it is possible to switch from the old to the new application and everything works. But this is the exception rather than the rule. Generally, an application communicates with many other applications. And because a system landscape grows over time, there are often several other applications that need to be replaced. If the new application has to include support for the old applications, the result can be high costs. The investment is also short term, as the interfaces to old applications are no longer needed as soon as they too are replaced. The only common case where old and new applications use the same interface is the migration to a newer version of standard software. Usually it makes little sense to keep old interfaces for new software, as it is desirable to use new technologies or architectures that have established themselves in the meantime. Business requirements can also play a role: new products to support or additional data required. As a result, the new and the old application are simply not compatible. Migration of old applications one after the other is very complex and usually not sensible.
The figure above shows the differences. Here, the same systems are migrated in two ways. In the lower part, the Big Bang Migration, only one step is necessary, but this step is costly and high risk. In the upper part, the Agile Migration, many small steps are executed. In this way, one system can be migrated at a time with little risk, while reacting flexibly to the changed requirements and problems. At the end of the migration the result is the same in both cases: the new system landscape without traces of the old applications.
An approach with problems: Big Bang Migration
A Big Bang Migration is another option. The individual replacement projects are co-ordinated so that all applications are migrated at once. There is no need to consider old interfaces, so all new applications can assume that they only need to support the new interfaces. This is the principal reason why this approach is so often used. However, the approach has many disadvantages. Firstly, the co-ordination requires much work. The individual migration projects are mostly developed by different teams. Because all migrations have to occur at the same time, the teams' progress has to be synchronized. If one project is delayed, the other teams have to wait for their migration. If serious problems occur with one of the new applications, there is no choice but to switch completely back to the old applications and, after fixing the problem, try the migration again. Such migrations are therefore very costly, risky and difficult to execute. As a consquence, such migrations are oftern delayed or even abandoned, as there is no one willing to take the risk.
The alternative: Agile Migration
Our approach, which we have termed Agile Migration, addresses these problems, Instead of a large migration for all applications, we migrated each application individually. To avoid problems with the old interfaces, we relocate this into their own component: the adapter. The advantage is that the new applications remain free of the burden of legacy interfaces. From the developers' point of view, there is only the other new applications. The adapter therefore avoids all the problems of the Big Bang Migration: because it serves as a mediator between new and old applications, it can prevent delays and rollbacks. Each application migration can now be planned and executed separately from the others: the projects are decoupled. After all components have been successfully migrated, the adapted can be switched off, and all legacy systems are removed without trace from the system landscape. This is the great advantage of the decision to move old interfaces into a new component: otherwise, the legacy interfaces remain in the new application and have to be removed at great cost and effort. Before a migration, it is therefore important to consider which approach to take, and to choose the most useful approach for the situation.
The following table compares Agile Migration and Big Bang Migration:
Big Bang Migration
Single complex migration
Delays are a high risk for project as a whole
Errors during the migration make a rollback of all involved applications necessary
The project as a whole has to be carefully co-ordinated and controlled
Agile Migration
Several small, simple migrations
Delays affect only a single part of the project
Rollbacks of single applications are possible
The project parts are largely independent of each other
Agile Migration is in most cases a beneficial alternative to Big Bang Migration, which we and our customers have had very good experiences with.
Any Questions Left?
How can we help? Just contact info(at)tngtech.com, or use one of the other contact options. We are happy to support you!