15.4 Data Migration Plan

A data migration plan for incremental development and deployment needs to account for the mapping of legacy database elements to modern database elements, the number and type of data adapters (see Section 13.2), synchronization procedures, if necessary, and the procedures and scripts for migrating data from the legacy system to the modern system.

The RSS architectural transformation strategy requires that code be migrated first, followed by the data. Performing the data migration after the code migration eliminates the need for data replication and synchronization between a legacy database and a modern database, reduces the complexity of the incremental development, and allows for optimization and refinement of the modern database schema based on lessons learned from each increment.

During system preparation, data is ported from DMS to Oracle. The schema in the Oracle OLTP database is an interim relational schema that is modified from the DMS network schema only to accommodate the differences between the database types. Data- related calls inside the legacy code are mapped to a data-access layer for interaction with the Oracle OLTP database instead of the DMS database. Figure 15-12 shows the system before code migration. ^[2]

^[2] Client application, communication, and transaction-management details are omitted.

Figure 15-12. System before code migration

Functionality inside business objects is implemented by session beans that communicate with entity beans to access and update data. In this case, the entity beans also serve as a data persistence layer. During code migration, the entity beans need to map to the interim database schema. Figure 15-13 shows the system during code migration.

Figure 15-13. System during code migration

The COBOL program elements and logic adapters are no longer needed once the code migration is finished, as shown in Figure 15-14. Data can now be migrated from the interim database schema to the final database schema. Because the data is already in Oracle, this is a straightforward task that can be easily accomplished using scripts, provided that the mapping is clearly understood . The interim entity beans are replaced with entity beans that map to the final database schema. The advantage of using entity beans as a data persistence layer is that the session beans that contain the business logic need not be changed to switch schemas, as long as the interfaces remain constant. Figure 15-15 shows the final system after data migration. The tasks of creating the new database schema, developing the final entity beans, and the data migration itself need to be accounted for in the cost estimate for the overall modernization strategy.

Figure 15-14. System after code migration

Figure 15-15. System after data migration