Process module: Enhancement and Migration of Legacy Systems
Activity: Developing Migration Concept
Participating: System Integrator
The »Migration Concept is basis and procedural manual for migrating system divisions from a legacy system to a new system. It describes tasks, responsibilities and procedures for transferring relevant system divisions of the legacy system to the new target environment.
The migration concept describes in detail which divisions of the legacy system are concerned, which changes shall be executed for the migration and where the migrated system divisions are to be integrated into the new system. Depending on safety and security aspects of the legacy system, a migration and a »Rollback Strategy will be selected for business processes, and a detailed migration plan will be specified.
The »System Architect, as person in charge for the design of the new system, is also responsible for the migration concept. This ensures that the system divisions to be migrated are considered properly in the architectural design. The System Architect will be supported by the »System Integrator, who is responsible for the new system to be developed
Data on the legacy system, which are relevant for the new system, will be derived from the »Legacy System Analysis. Information on the new system will be derived from the Overall System Specification, the system architecture and the »Database Design.
Is generated by
The »Migration Overview supports the »System Architect during migration planning and preparation. It describes which systems are included in the migration, which targets are intended to be achieved by the migration and which framework conditions must be observed.
A typical framework condition for a migration is the temporal restriction to a specified period. Frequently, applications to be migrated are subject to high availability requirements, which must be fulfilled.
The »Migration Strategy specifies the strategy for executing the migration. Basically, there are two strategies for replacining a legacy system: the step-by-step introduction of a new system or the big-bang strategy, i.e., the introduction in one step. It must be examined and determined in detail which strategy is suitable for the individual case.
If the big-bang strategy is applied, the legacy system will be switched off, the new system will be installed, and system divisions and data will be migrated during a specified period - frequently during one weekend.
In case of a step-by-step migration, the legacy system will be migrated in several steps. Generally, this step-by-step migration is less critical than the big-bang strategy. The users can familiarize themselves more slowly with the new functionalities. If the new system is not yet stable, it is possible to take recourse to the legacy system in case of emergency. The step-by-step migration may be subdivided in two types:
- The new system provides the complete functionality, but is only available to a limited user group. New and legacy systems run in parallel. With each step, the user circle will be extended. However, the parallel use of legacy and new system, and thus particularly the maintenance of data consistency, pose a problem.
- In another type of step-by-step introduction, a partial functionality will be provided for all users. The users work in parallel on new and legacy systems. With each step, the functionality of the new system will be extended until the legacy system is replaced completely.
A »Rollback Strategy shall be determined for every level specified in the migration planning. This strategy describes all activities to be executed in order to reset modifications in time if the migration fails. For each migration level, it will be specified individually
- according to which criteria the decision for a reset of the modifications, and thus for an abort of the migration, will be made,
- which tasks must be executed in order to prepare the abort,
- which activities must be executed to conduct the abort, particularly how the original data stock can be reconstructed and
- which activities are necessary after the execution of the abort. Particularly an evaluation strategy ensuring that the legacy system will again be available with its complete functionality shall be developed.
Data are the central element of the migration. Perhaps, data from the legacy system must be transformed into a new format and loaded into the database(s) of the new system. The »Data Migration shall be planned in detail. The data flow from the source databases to the target databases will be specified. In addition all necessary data transformations will be defined.
The degree of detailing goes down to the fields in a database table. The planning of the data migration is based on the »Data Model of the »Legacy System Analysis as source of the data flow and on the »Database Design of the new system as target.
Depending on the selected »Migration Strategy, the schedule for the execution of the migration will be planned. Within the defined migration levels, additional levels - each provided with a »Rollback Strategy - will be specified. The activities to be executed will be planned and the responsibilities assigned. For each level and for the entire migration planning, the point of no return, i.e., the point when an abort or rollback is impossible, will be specified.