Database migration
The challenges of databases migration
- How to decrease migration risks, budget, and deadline?
- How to migrate "rapidly" a legacy database into a relational environment?
- How to guarantee that my application will evolve easily after migration?
- Is it necessary to wait for the complete migration termination before starting new developments?
- Is it possible to migrate my data and programs batch per batch?
- Is it possible to first migrate the data base and later on the programs?
- How to control that the migrated data kept their coherence?
- How to make sure that the data to be migrated are of adequate quality?
- Is it possible to set up a replication system allowing parallelism between source and target database?
- Which are the data to be migrated to feed in an ERP or CRM system?
How will the REVER migration techniques lower your costs, risks and delivery time?
- By an in-depth and comprehensive analysis of all technical elements ( DDL, BD, JCL, programs)
- By a "phasing" of the migration process without freezing the applications
- By allowing the application programs to remain some time on the source computer even if the database is already migrated into the target one.
- By allowing a detailed re-documentation of existing applications and a complete data rules recovery
- By allowing compliancy between the semantic concepts used in the source and target databases
- By providing post migration data coherence thanks to a data "down load - reload" process according to a business logic
- By allowing a data quality control before migration into target database
- By generating a native target base (without technical columns simulating the source database functionalities
