Especially in information technology, development is progressing at rapid speed. What was state of the art yesterday, can be outdated already today. Even though release cycles of big software vendors have become longer, migration projects arise from changes in strategy, manufacturer consolidations or corporate acquisition. Protection of privacy, data consistency and especially the legal provisions (retention periods, audit security and traceability) are only some of the aspects to be considered. A division into different phases is more than reasonable.
Migration analysis and conception
The essential aspects in this feasibility analysis are the assessment of the requirements and the development of a migration concept. This captures the essential points, such as the tasking, the time requirement, the timing and specific sequence of actions. Furthermore, the assessment of the migration risk is off fundamental importance (latest milestone for a possible restore, point of no return).
During this phase the technical and business-related requirements are collected, an analysis of the existing (legacy) environment is done on test data or test media and the volume of migration data is determined. This information ultimately flows into the migration concept, which determines the downtime of the systems and the resource demand (personnel and possibly hardware). Additionally test cases are defined for a comparison of results ('before and after' principle).
In this stage, the initial implementation of the migration is done according to the timetable and the mutually defined migration steps and paths. Depending on the resource demand for the temporarily needed hardware and the data volume, a more or less complete test run of the individual migration steps and the functional acceptance test is done. The planned timing is verified again and can eventually be adjusted realistically.
This is the appropriate time to start administration and user training for the new system.
Execution of the actual migration
The actual data migration is executed strictly according to the migration concept and schedule. Unexpected events or results immediately lead to migration stop and mandatory reevaluation of the migration plan and risks. Depending on the scope of the migration and the data volumen, weekends, holidays and bridging days are ideal for the actual migration.
Verification of migrated data / information
This involves the comparison of application databases (e.g. SAP R/3 TOA-Tables) against the migration database, a validation of query results for the defined test cases and expected results. An amount comparison (e.g. document count per archive volume) and a hash value calculation for the migrated data attest the integrity of the migration.
Conclusion of migration
The conclusion of the migration includes additional actions after the succesful data migration, inter alia, the acceptance of the migrated environment and approval of the erase procedure for the legacy data. We support our customers with DMS- and archive migrations from / to given manufacturers, migration of OpenText PDMS projects to OpenText TCP projects, import of BPM process information into OpenText BPM Server or OpenText TCP and database consolidations.