How do we handle the data migration resulting out of the combined consequences of :
1. DDS to DDL conversion of database (any easier way than writing conversion programs based on old and new field layouts)
2. Normalising the DB to 3NF with building up of data dictionary.
If current development, customisation and package are handled through a change management system like Turnover how can a product like AO be best integrated with them.
The IMPORT of a schema into AO will also build a data dictionary which will then need to be rationalized as part of the initial process of modernization and normalization.
The conversion of DDS to DDL should be handled in a phased approach. The initial conversion should not change the structure of the record (level id.) in any way, requiring no changes or re-compilations of programs.
Normalization of the database itself will always require changes to the files and programs. This should be done in a staged manner taking only single files or small groups of files at once and preferably including these changes in enhancements or updates to the systems required by business.
There are many techniques which can be employed to minimize the impact of normalization on existing systems. These include, but are not limited to, various DDS and DDL join constructs, temporary surrogation of files, SQL based Input/Output Servers, Trigger synchronization of new files, etc.
AO as a product provides the source code for each change promotion which can then be monitored by a CMS product. There are some products that can do this and therefore no further integration is required.
As far as Turnover is concerned this may also be possible but if not then TEMBO is on record as saying that a suitable integration will be created. I worked with Turnover for many years and I do not see any difficulty in creating the required integration.
A resource that explains our recommended process can be accessed at https://www.adsero-optima.com/assets/AO_Normalizing_legacy_P F's_non-disruptively_1.zip
