Eventually everyone must upgrade and migrate their data to a new platform because of drastic changes in technology over time. Data migration, in itself, is a arduous task that must be meticulously completed to insure the integrity of the data and the minimization of downtime for your end users. We take pride in our in migration teams’ ability to seamlessly integrate your existing data into your new systems.
One would think that any two systems that maintain the same sort of data must have been performing very similar tasks. Therefore, information from one system should map to the other with ease. This is hardly ever the reality of the situation. Legacy systems have historically proven to be far too lenient with respect to enforcing integrity at the atomic level of data. Fields that should be populated from a list of valid values, such as STATES, tend to require that a value be entered, but seldom validate the value entered by the user.
The most significant problem with data migration projects is that people really do not understand the complexity of data transformation until they have undergone a number of arduous migration projects. |
|
 Strategy
- The Strategy phase of data migration should be scheduled to occur concurrently with the Strategy phase of the core project. Unfortunately, in most cases, the same people are expected to perform both analyses. This can be done, but these people need a clearly defined set of tasks for which they are responsible.
Analysis
- The Analysis phase of data migration also happens in parallel with the Analysis phase of the core project. This is because each data element identified as a candidate for migration inevitably results in a change to the data model.
Design
- The Design phase is where the bulk of the actual mapping of legacy data elements to columns takes place. The physical data structures have been frozen, offering an ideal starting point for migration testing. Note that data migration is iterative – it does not happen in a single sitting.
Pre-Test/Implementation
- Since testing and implementation are practically inseparable, they are often combined into one phase. The Pre-Test phase deals with two core subject areas: logical errors and physical errors. Physical errors are typically syntactical in nature and can be easily identified and resolved. Physical errors have nothing to do with the quality of the mapping effort. Rather, this level of testing deals with semantics of the scripting language used in the transformation effort.
Revise
- The Revise phase is really a superset of the last four phases (Pre-Test, Test, Implement and Maintenance), which are iterative and do not take place independently. This is the point in the process where cleanup is managed. All of the data model modifications, transformation rule adjustments, and script modifications are essentially combined to form the Revise phase.
Maintenance
- The Maintenance phase is where all of the mappings are validated and successfully implemented in a series of scripts that have been thoroughly tested.
|
|
