Deutsch Privacy Imprint > Software Migration > FiRe > Migration Phases
FiRe Migration Aspects Migration Phases Download


The starting point of each migration is the analysis of the filesystems and/or data base systems in the basic system. Over time, databases have the tendency to lose the schemas clearly implemented when they were created. Ad hoc solutions created under time pressure are often the causes of such faults. These inconsistencies are discovered during our analysis, and solutions for their removal are developed. File contents are also subject to erosion over time. Originally redundancy-free data records are duplicated by individual errors, whereby common minimal differences regarding the spelling of single terms are created. We also find duplicated data records where the records are not stored identically. Based on several algorithms of similarity analysis, we define paths and methods for harmonising this data.
All documents are in German.
[PDF] FiRe datasheet
[PDF] Success story Amadeus Germany


[Schema migration]
Example of schema migration
A schema migration is often connected with a change in the database paradigm. Legacy systems are often based on network or hierarchical database models, or they store information in sequential or index-sequential files. A relational redesign of the schema is thus not required.

But even a schema migration between two relational-based databases is not just a simple copying process. Differences in data types and their value ranges generally exist, even if common SQL standards are supported.

We accompany the creative schema migration process with tools that offer a high degree of automation.


Based on a successful schema migration and the knowledge gained during the analysis, we migrate the files/file systems automatically. In this step, adaptations to the new schema are made with the help of migration tools. Our experiences from several projects have shown that only a fully automated process can meet the needs of larger migration projects. The export of data from the legacy system, the transformation of data and the import of data into the target system often follow the "big bang scenario" to avoid a standstill of the corresponding applications. But this process also requires a technically mature rollback concept that can transfer data back to the legacy system in a worst-case scenario. We also provide fully automated solutions for this step. The following graphic example shows the sequence described herein:
[Data migration]


[Cache systems] For us, the process is not finished after the migration of the schema and the files/file systems. Our view of database migration also includes the migration of the applications that work with this data. Programs are normally modified anyway. Reasons for this migration step include, for example, differences in transaction controls and syntactical differences in SQL interfaces. However, elementary questions of application performance are also fundamentally important. Against this background, decisions must be made about whether SQL embedded in static or dynamic format can be used or if additional cache systems are required. Independent from the concrete answers to these questions, massive adjustments to the application code are required. For this, we have powerful tools like CoJaC, which automatically performs these adaptations.


[Test] We are pursuing a fully automated test management. A so-called reverse migration is carried out. Thereby the data of the target system are automatically migrated in data of the basic system in the reverse direction. These recovery data are then checked for the semantic identity with the original data pool. The persistence API is tested separately (unit tests). For this purpose, the migrated data and special test data are used, with which as many test cases as possible can be covered.