Database migration assessment is a process that measures database conversion complexity at a point in time.
Assessment dimensions are i.e:
• database's object cardinality.
• dependency from proprietary database features.
• overall number of in-database code.
• database size.
The outcome is a measurement of database complexity, expressed with two main indicators: the compatibility percentage and the estimated number of days to convert the database to the desired target.
In this phase , we assist the decision-making process evaluating the best database migration options.
We assume the source and target databases have an identical: schema, paradigm (e.g., relational or NoSQL), and we help enterprises to select the best option among the available ones.
The outcome is the selection of the target platform, a shared expectation in terms of timing and in terms of expected results.
In Waypoint Reply we focus on Heterogeneous database migrations, in the sense of migration between source and target databases of different database technologies.
This phase is the most complex, since it is about the conversion of basic objects inside the database (tables, indexes, constraints and so forth) and procedural ones (stored procedures, functions, packages).
It is also about data migration, and the most adequate data migration technique for the database in use.
Adaptation phase somehow overlaps with conversion one: we use the term «adaptation» to focus on peculiar database features that can’be be ported «as they are» into the target database.
These situations require some more focus: that's why we highlight this phase on our migration methodoogy.
Testing, in al his aspects: functional, parallel, performance, stress tests. Our methodology is test-centric.
Function test refers to the functional equivalence of the migrated functionality.
Parallel test is about running the application in parallel, comparing the results.
Performance and stess test refer to the general idea of performance measurement, on both a quiet system or a heavy loaded one.
Only after an accurate testing phase, the new database is declared as «ready to use», and it's possible to move to last migration phase: the go-live
The go-live phase is both a technical a issue (large volume of data to move, need of a CDC setup…) and a management issue (downtime, freeze, applications switch…)
The application is now switched to the new database!
