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.
2. 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.
3. MIGRATION OF FILES/FILE SYSTEMS
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:
4. MIGRATION OF DATABASE ACCESSES
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
, which automatically performs these adaptations.
5. TEST OF MIGRATED DATA
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
pro et con Innovative Informatikanwendungen GmbH. All rights reserved.