Migration strategies (information technology)

Migration strategies are used in information technology to migrate systems in order to replace systems.

Migration requirements

To be successful, a migration must meet at least the following requirements:

Guarantee uninterrupted, safe, reliable operation: A company cannot cope with failures of central systems such as company information systems for a long time, even the shortest failures lead to (financial) losses.
Carry out as many changes as appears necessary to cover current and future requirements: this means that the new system does not have to be adapted shortly after the migration is complete, and that another migration may be pending.
Make as few changes as possible in order to reduce the scope and risk of migration: the more complex a migration is, the higher the risk of errors, and the complexity of a migration increases with the number of changes made.
Change old code as little as possible in order to minimize risks: as long as the code works and no new functionality is required, it should be adopted as it is, or only minimal changes made, as changes inevitably lead to errors in the implementation pull yourself. However, this principle is usually not applied because the whole system is developed from scratch without adopting any code.
Change old code to the point that it supports the migration: if changes to the code make the migration easier with a reasonable amount of effort, this should be done.
Include the greatest possible flexibility in order to facilitate future changes: for example, by encapsulating the functions and providing an API (Application Programming Interface), future developments and adjustments can be made easier.
Minimize possible negative effects of the changes: with all changes to the system, it should be checked whether these changes are still compatible with the system, in order to prevent undesirable developments at an early stage.
Maximize the benefits of modern technologies and methods: on the one hand, this makes future adjustments easier and, on the other hand, system values that determine the decision to migrate, for example performance, data throughput, can be positively influenced.

"Chicken Little" strategy

This migration strategy consists of eleven “small steps” that are carried out incrementally, which makes the migration manageable, as the actual migration is split up into smaller parts (principle “ Divide & Conquer ”). "Chicken Little" still means a completely new development of the system.

Analysis of the legacy system: For a successful migration, it is essential to first understand how the legacy system works. Hopefully existing documentation will help, otherwise reverse engineering .
Dismantling the old system: The old system must be changed to the extent that there are defined interfaces between the individual modules and the database backends.
Developing the interfaces of the target system.
Developing the target applications: Weighing up whether the functionality of the application of the old system should be recreated or that of the old application should only come as close as possible.
Development of the database backend: Here the results of the previous steps are taken into account; we recommend developing with a relational database based on SQL .
Installation of the target environment: setting up a test environment and testing this environment.
Development and installation of gateways : The gateways are responsible for extracting the data from the old system and transferring it to the target system.
Migration of the database of the old system: Installation of the new database system, then migration of the data between the old and target system.
Migration of old applications: Gradually replacement of the individual modules of the old applications and their integration into the overall system.
Migration of the user interface
Switching from the old system to the target system: activate the new system and switch off the old system

Database First

First, the database system is migrated to a modern system before applications and user interfaces are migrated. So-called forward gateways are used to access the components of the old system on the new database system. After complete migration of the applications and interfaces, the forward gateway can be deactivated.

The decisive advantage of this method is that at the end of the migration the developed application and the database will definitely match, since the application development does not start until the migration of the database has been completed. This means that the new database can already be used for tests of the application still to be developed. Another advantage is that the changeover to the new database enables immediate improvements in reporting through the use of the latest programming languages. The individual applications can also be migrated one after the other without affecting the functionality of the system.

The main disadvantage of this approach is that it can only be used on systems that have a defined interface to the databases, i.e. a strict separation of application and databases. In addition, the database structure must be developed before starting the migration. The forward gateway to be developed can also be so complicated that it is sometimes not possible to create one at all.

Database load

This approach is the opposite of Database First and can also only be applied to systems with a defined data backend interface.

Gradually, the applications of the old system are migrated, for the simultaneous access of components of the old and new system to the data stock, all components of the new system have to handle access via reverse gateways. The last step in this migration method is to migrate the database system to the new platform.

Composite Database Approach

With this approach, the new application system is developed and implemented step by step while the old system is still in operation. Both systems thus form a network that remains in place until the migration is complete. The basis for this network is a co-ordinator layer in which gateways to the individual databases of the old and new systems are created. The individual relations can be migrated using mapping tables. It can be used with legacy systems that can be fully dismantled, semi-dismantled and not dismantled.

"Cold Turkey" / "Big Bang"

"Cold Turkey", like "Chicken Little", is a completely new development of the old system with the help of modern development methods. The new system is developed and tested parallel to the old system. If the new system has passed all the necessary tests, the old system is deactivated in a final step, the “Big Bang”, and the new system takes over. However, this results in high risks for a functioning migration:

A complete new development takes time. Over time, however, that the development takes, changes are also made to the legacy system in order to meet the company's current needs. This creates a general problem, as these changes to the old system also have to be entered into parts of the new system that have already been completed. This is error-prone and costly.
Usually there is no documentation for the legacy systems except for the system itself, for example the source code . There is now the problem that the original developers of the system are usually no longer available, and the system and its functionality must therefore be understood using the source code. In addition, certain programming techniques, such as self-modifying code, cause migration problems.
There are often undocumented dependencies between the legacy system and other systems. These dependencies can range in the entire spectrum from non-critical dependencies to business-critical dependencies. In the development cycle of the legacy system, the number of dependencies continues to increase and the existence of these dependencies is often not even known due to the mostly missing documentation.
The sheer volume of data poses another problem for this approach. Even if the target system is fully available, in some cases it would take weeks to move the data from the legacy system to the new system. During this time, no changes to the data would be possible and the system would not be usable. This is hardly a viable option for any company. The data schema is also usually changed during a migration, which must also be taken into account during the data migration.
Managing such large projects is extremely difficult.
The points listed above mean that the plan for the development can hardly be adhered to, the completion of the system continues to be delayed.

butterfly

The butterfly migration approach is a strategy that, unlike “Chicken Little”, does not require the use of gateways. The method is based on an initial migration of the data backends: the legacy system remains operational, while the new system can be developed and tested in a test environment without influencing or even disrupting normal operation.

The basic assumption that is important for this migration technique is that it is all about data migration and that cooperation between the old and target systems is not necessary.

Butterfly migration

At the beginning of the migration process, in addition to the database of the old system, several temporary memories are set up and the database is provided with write protection. The accesses are redirected by the data access allocator: information that has not yet been accessed is fetched from the database, changes are initially written to the temporary memory TS ₁ . If changed information has to be called up, it is taken from TS ₁ .

Subsequently, the data of the old system can safely, without loss of data and loss of service quality of the system, using the so-called "Chrysalizer", a component that transfers the data from the data schema of the old system to the new data schema and stores it in the new data backend System. During this migration, as described above, all data changes are no longer stored in the legacy data backend, but in the temporary storage TS ₁ .

Once the migration of the old database has been completed, the information that has been saved in TS ₁ in the meantime must also be migrated. For this purpose, TS _{1 is} blocked for write access and the new storage TS _{2 is} opened. Changes to the database are no longer saved in TS ₁ , but in TS ₂ . Every time now a temporary storage TS _n migrated from "Chrysaliser", the memory TS is _{n + 1} locked for write access, the storage TS _{n + 2} opens the legacy system for write access, and the storage TS _{n + 1} to hand over the "Chrysaliser". If the contents of a temporary memory can be migrated faster than the new memory is created by the old system, i.e. if the legacy system does not have any write accesses during the migration of a temporary memory TS _n , the size of the temporary memory TS _{n + 2 is} reduced in the next step. Mathematically, the size of the memory has the limit value zero. ${\ displaystyle n \ rightarrow \ infty}$

During the entire migration, the system continues to work normally until the size of the last temporary memory falls below a certain threshold value, so that the time it takes to migrate this last memory is extremely short. Then, in the last step, the old system can be stopped, the last temporary memory can be transferred to the new system, and the new system can be put into operation, since consistency has now been achieved between the database of the old and new system.

The advantages of the butterfly process are obvious: On the one hand, the entire system is available at all times, except for the step of the final switchover to the new system, the duration of which can be further minimized by carefully selecting the threshold value. The migration can also be canceled at any time before the system is switched, since the migration can be reversed as long as all data has passed through the data access allocator. If the migration has to be aborted, the temp memories only have to be reintegrated into the data memory one after the other, starting with TS ₁ .

The disadvantage of this strategy is that, depending on the activity in the old system, an extremely large number of temporary memories may be necessary, none of which may be overwritten, for example in the round robin process , in order to allow the migration to be aborted. In extreme cases, it may be necessary to use a lot of hardware for storage backends during the migration. The development of the data access allocator poses another problem: in contrast to "Chicken Little", the development of gateways between the systems is saved, but the data access allocator is also a very complex component that can require a high development effort.

literature

Brodie, Stonebraker: Migrating Legacy Systems; Morgan Kaufmann Publishers Inc., 1995
Bisbal, et al .: A Survey of Research into Legacy System Migration
Harry M. Sneed et al .: Software migration in practice: transferring old software systems into a modern environment. dpunkt.verlag, Heidelberg 2010, ISBN 3898645649 .