Why Use the Planning Module

Establishing a Scope

The Planning module provides support for a data migration project at the beginning and end of the process, firstly by enabling the documentation of the scope of the data to be migrated and secondly the definition of the testing that should be carried out to support the sign off of the completed migration. 

As with any other project definitively defining the scope of the data to be migrated is key to a successful migration project.  If you are confused about the objective of the migration you cannot possibly measure whether it is complete or successful. 

Defining the specific Scope 

The definition of scope in the Planning Module is three dimensional, 

• it must identify what data objects are to be migrated
• which attributes of those objects are required
• ... and what is time frame for history of those objects 

Normally of these "what objects" and "what history" are defined first, the detail of the attributes will follow as the mapping work is carried out. 

It is better to start with a high level definition that is related to the functional areas of the target system than a list of data objects, this can also be more easily related to by the business and will support the testing plans. 

Using Templates

To define the scope in the hopp software you first define a template at the Portal level that can be applied to any Project. This should cover all the areas of the Target System that could be included in an implementation of that system. 

The Template can form the basis of many migration projects and so is particularly useful to organisations that repeatedly migrate to the same or similar target systems. 

The Template should be defined to be independent of the detail of a Target system or any particular version of a Target system so that it does not need to be reworked if a small change is included in a new release of the target software.  It can always be extended in a specific project if there are areas that are encountered in one situation that are not common in most. 

Introducing Dimentions

The Dimensions can be used to further categorise the types of project that may be carried out by the customer, group projects by geography, industry, or other differentiator. 

The scope of the migration is a three dimensional puzzle: 

• Which data areas should be migrated 
• What level of history is required for each of these areas 
• What are the data objects for each of the areas 

The first two should be settled at the start of the project, and form part of the objectives of the project.  They are required to enable the Project team to plan the required activities, timelines, resources, etc. that will be needed to achieve a successful migration.  They will also be used to define the success criteria for the project, and potentially used as a measure for the completeness of the project at intermediate stages. 

Based on the success criteria for the project it must be established what constitutes a successful migration, i.e. for each Object what level of defects can be accommodated without preventing the new system supporting the business adequately.  This can also be stated as what level of defect can be successfully corrected post go-live in the new system. 

The definition of a successful migration must be quantifiable, i.e. it must be possible to count the number of data objects that fail to migrate and the number of errors that have been found (not necessarily the same figure).  These metrics are also necessary to measure progress during the data migration project. 

The detail of the data objects and their attributes will take time during the development phase of the data migration project to finalise. 

Testing using the Planning Module

Once the data has begun to be processed the testing of the migration can begin.  This may be separate from the main system testing or rolled up into it.  Certainly UAT should be carried out using migrated data and so should form part of the final sign off of the implementation. 

Testing will be complemented by reconciliation.  The first is to prove that the data has been migrated correctly, i.e. the data populated in the new system accurately reflects that held in the old.  The second is to prove that all the data from the old system has been migrated to the new without any omissions or additions. 

The Planning module is designed to be populated at the beginning of the project once the Scope has been agreed and then used at the end to record the results of the testing that has been included in the plan.