Supra Migration

MigrationWare has a great deal of experience helping clients migrate from legacy database platforms to modern RDBMS platforms.

Overview

Having completed so many different rehosting projects has demonstrated to us that there are really only three general approaches to accomplish migrations of this nature: Total Reengineering / "Transparency Layer" / Call-for-Call Replacement.

MigrationWare have used each of these approaches in the past and are very familiar with the positive and negative aspects associated with each of them. When deciding which approach to take there several factors to be considered:

Complexity is an important consideration as it affects numerous other aspects of the project. The more complex the approach the greater the associated risks. Complex approaches generally require a large team of very senior technicians increasing the associated costs. Finally, complex approaches tend to require complex maintenance support following deployment.

Risk is an important element in any decision-making process. When you attempt to move a suite of application software designed to work with one database platform to another, particularly one so different, the associated risks can quickly overwhelm any benefit that might be derived. The MigrationWare team view risk reduction and mitigation as a major evaluation factor.

Schedule is a factor which weight varies depending on the schedule requirements as defined by the client. Obviously, not all the potential approaches require the same level of effort. Therefore, the schedule associated with each approach will be different—in some cases, radically so.

Cost is always a factor in any decision. If the costs associated with completing a project are more than the associated real or perceived value, the project is generally not funded. The costs associated with the different approaches evaluated were very different.

Clients generally undertake a migration of this nature to enhance the Future Viability of the associated application software portfolio. The selected approach should totally free the migrated applications from limitations associated with the legacy database environment. It should also provide a solid foundation on which to make future enhancements as the modernization efforts continue.

Performance of the source environment is generally very important. The selected approach must ensure that performance of the system (batch and on-line) is not negatively affected by the migration project.

MigrationWare’s work with past clients tells us that no single one of the typical approaches is the “best” approach. Instead, MigrationWare has developed a hybrid designed to leverage the positive aspects of each of the three approaches described above.

The source DBMS we are currently able to migrate are Supra RDM, Supra PDM, Total, Adabas, Datacom.

The target databases we support are DB2 and Oracle but migration to any SQL compliant database is possible.

Key facts

Minimize the impact to the application programs
Maximize the performance of the RDBMS platform
Do not encumber the database design with limitations associated with the legacy DBMS platform
Provide a database environment that will be a solid foundation for future enhancements

Reengineering

MigrationWare’s approach allows the rehosted database design to be reengineered to take full advantage of the powerful facilities provided by the RDBMS platform. Limitations associated with the legacy environment are not carried forward.
Transparency Layer

Like the Transparency Layer, MigrationWare’s hybrid approach has minimal impact on the application programs. The existing database calls are redirected to MigrationWare’s infrastructure layers. Results of the call are returned to the application program as if the legacy database was still the DBMS.
Call-For-Call Substitution

Like the Call-for-Call Substitution, the MigrationWare approach replaces the original database calls with functionally equivalent SQL statements. It also includes program logic to translate/transform data and status codes back to the values expected by the application program. In most migration scenarios the major difference is that, instead of embedding this code into the application programs, this code is implemented as reusable components that are managed by the infrastructure and shared across all applications. This eliminates the redundancy issues associated with typical Call-for-Call Substitution schemes.