Professional Documents
Culture Documents
Version 1.0
Data Migration
Version 1.0
Purpose
The purpose of this document is to lay out the structure for data migration for an application
reengineering project
Intended Audience
This document is primarily for the use of consultants associated with Data Migration projects
Glossary
TCS Tata Consultancy Services
Contents
1 INTRODUCTION.........................................................................................................4
1.1 Background................................................................................................................................ 4
1.2 Scope......................................................................................................................................... 4
1.3 Assumptions............................................................................................................................... 5
1.4 Open Items................................................................................................................................. 6
1.5 System Description..................................................................................................................... 6
1.5.1 Source System Description.................................................................................................... 6
1.5.2 Target System Description..................................................................................................... 6
2 Migration Approach...................................................................................................7
2.1 Introduction................................................................................................................................. 7
2.2 Planning..................................................................................................................................... 8
2.3 Analysis.................................................................................................................................... 10
2.3.1 Analysis of Source Inventory................................................................................................ 10
2.3.2 Source Data Analysis........................................................................................................... 11
2.3.3 Data Cleansing..................................................................................................................... 12
2.3.4 Extraction programs............................................................................................................. 12
2.3.5 Analysis of Target Database................................................................................................ 12
2.4 Strategy definition..................................................................................................................... 14
2.4.1 Proof of concept................................................................................................................... 14
2.5 Design...................................................................................................................................... 15
2.5.1 Mapping rules....................................................................................................................... 16
2.5.2 Data Format – Source to Text File.......................................................................................16
2.5.3 Non-key source fields becoming key fields in target.............................................................17
2.5.4 Date and time stamp / load date fields and user id..............................................................17
2.6 Construction............................................................................................................................. 17
2.6.1 Data migration approach...................................................................................................... 18
2.6.2 Source System (VSAM / DB2) to Staging database (Oracle)...............................................18
2.6.3 Staging database (Oracle) to Target database (Oracle).......................................................20
2.6.4 Cleansing............................................................................................................................. 21
2.6.5 Audit trail data, summary data.............................................................................................. 22
2.6.6 Reports................................................................................................................................. 22
2.6.7 Special Requirements.......................................................................................................... 22
2.7 Testing...................................................................................................................................... 23
2.7.1 Validation............................................................................................................................. 25
2.7.2 Audit..................................................................................................................................... 26
2.7.3 Testing Lifecycle.................................................................................................................. 26
2.8 Pre-Implementation(Dry Runs)................................................................................................. 27
2.9 Implementation......................................................................................................................... 27
2.9.1 Cutover Considerations........................................................................................................ 30
2.9.2 Change Control.................................................................................................................... 30
Scope of Change Control....................................................................................................................... 30
2.9.3 Traceability........................................................................................................................... 31
2.9.4 Backup and Recovery.......................................................................................................... 33
3 Risks.........................................................................................................................33
4 Guidelines................................................................................................................34
5 Recommendation.....................................................................................................35
1 INTRODUCTION
Background
ING has initiated a program to replace the existing Pension Fund Management applications running in
Mainframe systems with the J2EE application. This project will replace these legacy systems with more
flexible systems with up-to-date technological platforms and functionality.
As part of the replacement, the data from the existing mainframe applications should be moved to the
target Oracle database. ING has invited Tata Consultancy Services (TCS) Limited to prepare the data
migration strategy document. This document details the various steps necessary for the life cycle of the
data migration project that will feed the legacy data to state of the art “Oracle database”.
Scope
The scope of this document is to define the strategy for the various phases of data migration. The phases
in this data migration project are as follows.
Preparation Stage
o Planning
o Analysis
o Design
o Construction
o Testing
Implementation Stage
o Pre-Implementation/Dry Runs
Tools
Cutover Considerations
Proof of Concepts
Guidelines
Special Requirements
Roadmap
Assumptions
Target data model will be developed iteration wise and so may undergo several changes. So source
data analysis has to be done based on evolving target data model. Once the target data model is
baselined unmapped fields in source will be further analyzed to confirm whether it can be actually
ignored.
ING will define the strategy, analysis, design and construct scripts for Data Cleansing. TCS will
support and complement this.
The production cut-over window for implementation is expected to be 48 hours over a weekend. This
could change based on the volume of the record, relationship between tables which defines the order
of migration
The source inventory and corresponding data are based on the assumption that the go-live date will
be on a weekend that doesn’t fall on a month-end.
The current strategy is to extract the data from mainframe source using Informatica power exchange
and use Informatica powercenter to transform and load Oracle target database
There will not be any explicit lock on the data to be migrated by any of the application accessing the
data during the outage window
The current existing model is base lined and assumed to be 100% complete.
The scope of data migration project is to migrate only the data that will be accessed by the target
application system
ING will provide the list of concurrent activities during the outage window. The impact of it will be
studied and the outage window size will be decided
Open Items
Need for migrating the historic and back up data in tapes which are not going to be accessed by
the target application, target table and the strategy for the same will be analyzed by ING and
discussed and finalized. Both ING and TCS will discuss and resolve on the extra effort involved
and the impact on the plan.
The possible solution could be one time migration either through regular interface or using
scripts and then incremental migration using regular interface.
The scope of migrating the data present in tapes which are rarely used by the application needs
to be finalized. The feasibility of the target application system accessing the same tapes needs
to be studied
Risk analysis, Implementation details, Roll back strategy, handling of exceptions are yet to be
finalized.
The migration strategy of back up data when the layout is different is yet to be finalized.
System Description
The scope of the data migration project is to migrate the data from the existing mainframe system to
ORACLE Database. The System architecture related to these systems is:
2 Migration Approach
Introduction
Data migration is process by which data is moved from source databases to target databases. Currently
source data is in VSAM and flat files and DB2 tables in Mainframe. This data needs to be moved to target
databases in Oracle. The various phases involved in this endeavor are as described below.
Preparation Stage
o Planning
o Analysis
o Strategy Definition
o Design
o Construction
o Testing
Implementation Stage
o Pre-Implementation/Dry Runs
The preparation stage will be used to develop data migration strategy and the data migration programs.
This will be tested in non-production environment. All the factors that influence Implementation stage like
business requirements, data volumes and infrastructure constraints should be taken into account in the
preparation stage. This stage is very vital in the success of any data migration program. This stage will be
done in seven iterations and will be synchronized with the iterations in ING Core AFP Project.
The actual execution of the data migration programs on the production data will be done in
implementation stage. Implementation is planned in two phases. Preceding each implementation will be a
Pre-Implementation or dry run to test the data migration scripts with production data in simulated test
environment.
Planning
All planning activities required for data migration will be done in this phase. Other activities that will be
taken up in this phase will be the finalization of source inventory, creation of standards, strategy for data
analysis, cleansing, implementation and selection of tools.
Assumptions
Project Plan is available
Activities
Deliverables
Updated Project Plan
Source Inventory list
Inventory List for POC
Tools
The tool required for various phases of data migration has been identified during POC and the list is given
below.
Analysis
Detailed analysis of source and target databases will be carried out in this phase. Data analysis will be
carried out to understand the contents of source data and documented. Data cleansing requirements are
documented and criteria for extraction audit and validation of source data are agreed upon.
The VSAM files, DB2 tables and flat files (structures, data and copybook layouts) are assumed to be base
lined for inventory purposes. As Archive data migration will take place if archives are in current source
format, their inventory needs to be documented.
When data is migrated from VSAM and DB2 to Oracle, the data that needs to be migrated and the data
that is left in source because of duplications etc. need to be identified as part of scope analysis.
3 No of VSAM files to
be migrated
4 No of DB2 tables to
be migrated
5 No of VSAM backups
6 No of DB2 backups
7 Volume of data
10 No of DB2 Tables
with Reference Data
11 No of VSAM files with
Reference Data
12 No of DB2 tables with
transaction data
13 No of VSAM files with
transaction data
14 No of DB2 tables with
Master data
15 No of VSAM files with
Master Data
16 No of Databases in
the system
Data analysis for all the source entities needs to be documented. This will be done iteration wise
based on the evolving target data model. ING will provide the field description, ranges, and
domain values for all the fields. This will help us in deciding whether an unmapped source field
can be ignored or not. The following excel format is agreed upon and ING and TCS will jointly
complete for all the VSAM files and DB2 table attributes and their descriptions.
Field Analysis
Template.xls
As part of Standardization measure, the domain values of the source database may have to be
standardized for target (based on international standards, ING specifics or new application
design). Such domain values should be agreed upon and signed off well in advance, as part of
analysis phase.
The analysis should also cover the following aspects of source and target data model,
- Database specific constraints that may have potential impact on the data conversion (for
example the impact of migration of COMP-3, OCCURS, REDFINES, etc. from a mainframe
environment to Unix/Oracle)
Based on the data analysis, the fields that need to cleansed should be identified. Data cleansing
is required to ensure that only accurate, consistent and complete data is loaded into target
database. Data cleansing will be required for
- Junk Characters/Characters not supported by Oracle like nulls
- Referential integrity (eg, affiliate RUT in any transaction table should also be present in
affiliate master)
The cleansing requirements should be documented clearly, stating the present conditions and the
proposed corrective action. The field analysis template itself can be used for documenting
cleansing requirements. Data cleansing requirements and routines will be provided by ING. We
also need to identify at what stage the cleansing rules can be applied (extraction , transformation
or load)
Total
Assumptions
Updated Project Plan is available
Finalized Source inventory list for current iteration is available
Target data model for current iteration is available
Activities
Deliverables
Data analysis findings
Updated Inventory list
Challenges
It is essential to baseline both source and target data models to reduce rework. However it is not
practical when analysis is done in iterations. It is vital that any changes to the source and target
baseline should be informed to the data migration team immediately. The changes should be
immediately analysed and data analysis document updated.
All environment specific constructs should be identified. It should be verified whether the
informatica tool will handle it. If the tool does not handle it suitable solutions should be identified
for migrating them to target. During POC we have identified the following list
o Character set in mainframe and Unix are different. Mainframe uses EBCDIC while Unix
uses ASCII. Informatica power center is able to handle this conversion.
o Occurs , and Redefines can be handled by Informatica power center.
o For Occurs depending we have to manually alter the data to make it the maximum
number before loading in informatica power center. Usage of Power Exchange will be
able to address this problem.
o Loading of DB2 null data into Oracle was found to be a problem. An extra field was
manually added before every column that may contain null. This is to hold the null
indicator. Usage of Power Exchange will be able to address this problem
o In Oracle Date is defined as YYYY-MM-DD-Time but in Vsam files it can be of any
combination. A transformation rule was written in power center to transform source date
to target format
o We could not find any Julian dates in POC. So a strategy for transforming it is not
identified. Further analysis to be done to check if ING core AFP system uses Julian date
or not.
Strategy definition
The various strategies related to data migration are defined in this phase. The data migration strategy
document is prepared in this phase. A proof of concept has been done to validate the migration strategy
for extraction, transformation and load. This document will be updated with best practices and lessons
learnt after each iteration.
2.1.6 Proof of concept
The migration of following VSAM files and DB2 tables will be the scope for the Proof of concepts. The
extraction, transformation and load will be done for these sample data in the development environment.
VSAM
1. CUENTAS.PROD.PMC321D1
2. CUENTAS.PROD.PMC321D2
3. CUENTAS.PROD.COT905D1
4. BENEFIC.PROD.PCB150D1
5. BENEFIC.PROD.PCT200D1
6. BENEFIC.PROD.PPR100D1
7. INCORPOR.DESA.EAE02M
8. INCORPOR.PROD.EAE03M
DB2
1. PER_INC_REC
2. RECLAMO
3. EMPLEADO
4. DIRECCION_POSTAL
5. DIRECCION_PERSONA
Assumptions
Project Plan is available
Activities
Deliverables
Data Migration Strategy Document
Design
The objective of this phase is to define a set of rules to transform data from source to target. The mapping
rules are based on source and target data structure and domain information provided by ING. The
mapping repository is created to maintain list of mapping rules.
The following template is used for mapping repository
"Mapping repository
template.xls"
computation clearly.
All the following conversions will be done by Informatica Power center itself based on the standards
VSAM DATA TYPE Flat File REMARKS
Numeric Numeric
2.1.10 Date and time stamp / load date fields and user id
Date will be ORACLE format of mm/dd/ccyy with default value set by the business. Time stamp
will also be default ORACLE timestamp. For load dates field and update user id field the date
when the loading/migration is done and a default User Id will be assigned.
Assumptions
Baselined source and data model for the current iteration is available
Data analysis findings is available
Activities
Deliverables
Mapping repository
Construction
The objective of this phase is development of data migration suite. This phase consists of creation of
extraction , transformation and load scripts for data migration.
JCL Text
VSA M COB OL File
Transfo
Loading Target
rmat ion
Conversion Database
(AS IS) Loading
FTP DB
DB2 Te xt
DB2 Unload File
2.1.12.1 Extract
The strategy of extraction given here is without Informatica Power Exchange. The impact of
having Informatica Power Exchange on extraction process will be analyzed and the same
will be updated in this document after iteration 1.
The data from VSAM file and DB2 table is extracted by the following steps
1. The COBOL format programs with copybook names with “.CBL” extension will be
written
2. The copybooks in the same folder with ".CPY” extension will be copied
3. The source descriptions will be defined in Informatica Source Analyzer
4. Using the source descriptions the target table descriptions (Staging Oracle db)
will be defined in Informatica Warehouse designer
5. The staging target tables are created in the database
Note: Any compatibility issues between Mainframe data and loading data into Infomatica Power
center will be analyzed and the extraction process may have an impact. The document will be
updated accordingly.
2.1.12.2 Transform
The following are the steps that needs to be followed in informatica power center
1. The mapping rules are defined and linked between the source and target in the
mapping designer
2. The transformations rules are designed and scripted in Transformation developer
3. Some degree of data cleansing activity will be performed as a part of the
extraction process.
2.1.12.3 Load
The following are steps involved in loading the data from VSAM and DB2 to staging oracle
database.
1. The reusable sessions are created which will define the mapping
2. The workflow is created in the Workflow Manager which will define which session
needs to be executed and sequence and time of execution
3. The workflow is executed to load the data from the source to the staging
database. The number of workflows will be decided based on the sequence of
the migration
4. The referential integrity will not be maintained in this database.
5. Indexes will be created based on the performance requirements
2.1.13.1 Extract
The data from staging database is not extracted but it is physically represented as mapping
and transformation and the Informatica Power center picks it up from staging database to
the target database.
2.1.13.2 Transform
The following are the steps that needs to be followed in informatica power center
1. The mapping rules are defined and linked between the source and target in the
mapping designer
2. The transformations rules are designed and scripted in Transformation developer
3. Cleansing activities will also be done here.
4. The data will be ported to Informatica server through UNIX box.
2.1.13.3 Load
The following are steps involved in loading the data from staging oracle database to target
oracle database.
1. The reusable sessions are created which will define the mapping
2. The workflow is created in the Workflow Manager which will define which session
needs to be executed and sequence and time of execution
3. The workflow is executed to load the data from the staging database to target
database.
4. The referential integrity will be maintained in this database and hence the data
loading will have to be performed based on the defined loading sequence.
5. Indexes will be created based on the Target database schema requirements.
6. Additional indexes may also be necessary to improve the performance
requirements
Note: For the input source data that does not require cleansing in staging will be migrated directly to the
target. The analysis of cleansing for the files plays a major role in deciding this strategy. This approach
will save a lot of time during the implementation
2.1.14 Cleansing
X%
Cleansing
Transformation
VSAM
VSAM files
files
Y%
W % Ta
Ta
Cleansing
Cleansing by Dat
Dat
COBOL/JCL
DB2
DB2 Tables
Tables Transformation
Staging
Staging Z%
Database
Database Cleansing by
JAVA /SQL
Mainframe Oracle Or
Source Staging Ta
This process will cleanse all the non voluminous and business non-critical data. The main
purpose of cleaning the data directly in production is to avoid any cleaning activities of the similar
data in the subsequent migration. Therefore the data, which is cleaned, will remain clean
throughout the different phases of migration. The types of data that will be cleaned are:
Name: These are entity properties data like, Customer name, Customer address, Dealer
name, Bank name DSSO Name.
Comment: These are entity attributes data, like, description, Comments, Attention fields and
any other fields that are not participants in business validation.
Appropriation: These are any standardization data like, customer name standardization,
address standardization.
This level cleansing process is to clean voluminous business non-critical data. This also includes
the data that are routine and static clean. The data that are cleaned in this process are:
The major part of the data cleansing rules is applied in this stage. Cleansing at transformation
include while transforming data from source to staging and also while transforming staging to
target. These include:
Inconsistency in Business
Domain value (ZIP code, RUT)
Unmapped data
2.1.14.4 In staging
Some level of cleansing will be done on the data present in the staging table. Either Java
programs or SQL will be written to clean the data present in staging.
Note: If cleansing will be done during transformation and staging, then ING and TCS has to
analyze the impact on the effort involved and the changes to the plan.
Summary data will contain all type of key information for migration of a particular entity. For
example for Affiliate Master, RUT, Name of the affiliate and any other information that are critical
to the entity will be considered.
2.1.16 Reports
Exceptions reports will be analyzed, gap will be studied and new/changed data cleansing definition will
be incorporated. Both the rule definition and programs will be configured. Use of any reporting tool will
be analyzed and finalized
Any special requirements that arise as part of Data Analysis will be documented and updated frequently
Assumptions
Baselined source and target data model for the current iteration is available
Mapping repository available
Data cleansing requirements available
Activities
Deliverables
Extraction routines
Source and target definitions
Mapping and transformation rules
Load routines (Sessions and workflows)
Audit and validation routines
Testing
This phase comprises of testing the data migration suite for each iteration. Testing will check all the
transformations / mappings / workflows / cleansing / audit and validations. Individual test cases need to
be prepared for testing out various functionalities. The following matrix illustrates the broad areas that the
test cases will pertain to –
2.1.18 Validation
The following are the validations that will be performed to ensure the correctness of the data migrated.
2.1.19 Audit
Audit rules are expected to be defined by the ING Core AFP Data Migration team in the following format.
The auditing should be done based on the reliable reports from business. Business reports will be
provided by ING to be used for auditing
The construction and unit testing will be done by TCS onsite/offshore team after the finalization of
design document. This will be going forward basis.
The Migration components will be delivered by TCS upon completion of construction/unit testing.
After this primary validation a bigger Revolution Unit Testing will be performed by ING data
Migration team after ING Core AFP application is delivered. TCS will support the testing.
After the completion of this phase Performance Testing and Revolution Unit Testing will be
performed in parallel. TCS will support these two types of testing.
Assumptions
Data migration suite available (Extraction, transformation and load routines)
Audit and validation routines available
Source Data for migration is available
Activities
Deliverables
Tested data migration suite
Pre-Implementation(Dry Runs)
Pre-Implementation or Dry run is the simulation of production implementation in test environment.
The objective is to understand the complexities during implementation, in terms of the window for
data migration, infrastructure requirements and to fine tune the programs and implementation
procedures if required. Data migration implementation is planned in two phases. So Pre-
implementation run will also be done for each of these phases. This will be done by ING Data
Migration team and the Business Capability Team. TCS will support this testing.
The strategy describes the go-no-go checkpoints after different stages and a Root cause Analysis
(RCA) will be done for each checkpoints. Based on the RCA the Data Mapping, Data Model,
Design, Migration Design, Migration component codes will be revisited and necessary actions will
be taken.
Assumptions
Tested Data migration suite available for the current implementation phase
Test environment that is simulated based on production is available
Source Data for pre-implementation dry run is available
Activities
Deliverables
Full volume Tested data migration suite
Implementation
Implementation phase comprises of activities for implementing the actual production data
migration.
The implementation of data migration depends mainly on the implementation window, volume of
data to be migrated and the type of data. On further analysis on data and discussions the
implementation strategy will be finalized.
As of now the implementation of phase 1 roll out alone is considered. Based on further analysis the
document will be updated for the implementation of phase 2 roll out
All the back up data will be migrated two weeks ahead and the reference data will be migrated one
week ahead and the transaction and master data will be done in one weekend before live. The
same is depicted in the figure below
Time Line
17 th Sep-
17th Sep- 28
28th
th 29
29th
thOct
Oct 4 th 5
4th th Nov
5th Nov Go-live/Mon
Go-live/Mon
30 th Oct
30th Oct Mon
Mon –
–3 rd Nov
3rd Nov Fri
Fri Sat
22 nd Oct
22nd Oct Sat
Sat -- Sun
Sun Sat -- Sun
Sun 6 th Nov
6th Nov
Catch
Catch up
up
for
for
Testing
Testing changed
changed Apply
Apply
Back Reference
Reference post
Back upup Reference
Reference
post
files Data
Data dated
dated
files Data
Data
Migration
Migration Transac
Transac
Transaction
Transaction -tions
-tions
Data
Data
Data
Data Unlikely
Unlikely 2 nd Nov
2nd Nov Thu
Thu –
–3 rd Nov
3rd Nov Fri
Fri
Testing To
To Change
Change
Testing Apply
Apply
and
and Hold
Hold
Pre
Pre Data
Data
Master
Master
processing
processing View
View only
only Data
Data
Data Migrate
Migrate Frozen
Frozen
Data
Account
Account Files
Files
One off Migration One off Migration and Catch up One off Migration Corrections
Note: Data cleansing implementation is not considered. The cleansing implementation will have impact on
the strategy defined here and this document will be updated based on the cleansing implementation
Following source files of ING Core AFP System split according to the modules and the best strategy and
time for migrating these data will be tabularized in the following format once the approach is finalized.
# The following no of records and database sizes are based on the available information in production.
Sl System Data # Volu Vertical Horizont Special Link for the Proposed date of
me Split al Split Treatment list of Migration
( (GB) (By Tables/Files
M Design)
)
1 Contracts Transa
ction
2 Contracts Master
3 Contracts Refere
Sl System Data # Volu Vertical Horizont Special Link for the Proposed date of
me Split al Split Treatment list of Migration
( (GB) (By Tables/Files
M Design)
)
nce
4 Accounts Transa
-1 ction
5 Accounts Master
-1
6 Accounts Refere
-1 nce
7 Claims -1 Transa
ction
8 Claims -1 Master
9 Claims -1 Refere
nce
10 Accounts Transa
-2 ction
11 Accounts Master
-2
12 Accounts Refere
-2 nce
13 Claims -2 Transa
ction
14 Claims -2 Master
15 Claims -2 Refere
nce
16 Pensions Transa
ction
17 Pensions Master
18 Pensions Refere
nce
19 Bonds Transa
ction
20 Bonds Master
21 Bonds Refere
nce
Assumptions
Full volume Tested Data migration suite available for the current implementation phase
Activities
Deliverables
Data migrated to target table as per data migration requirements.
2.1.21 Cutover Considerations
Sl Candidate Issue
1 Master Files Weekend cutover will not have any issue. Go-live on weekday will require the
files to be kept on hold.
2 Quarterly Back up These type of files which are not going to be modified can be migrated two
files weeks ahead
3 Contracts All the contracts related files should go live in the month end only
4 Deceased Data Data related to deceased can be migrated well in ahead as they are not going
to be modified
5 Closed Claims All data pertaining to closed claims can be migrated well in ahead
6 Inactive affiliate The data related to inactive affiliate can be migrated well in ahead as they are
not going to be modified
6 DB2 tables Weekend cutover will not have any issue. Go-live on weekday will require the
record locked
7 Maintenance Stop online users to do any maintenance transaction in the last 3-4 days
before implementation. This will make the database more static.
Changes
8 Regulatory Stop applying regulatory changes in the last 1 month before implementation
Changes
9 Final Backups prior After the completion of the batch cycle final backups need to be taken.
to migration
2.1.23 Traceability
The traceability of the data migration artifacts (documents and programs) are to be traced from target
fields to the audit and validation routines in the ING Core AFP system. The following diagram depicts the
traceability requirements in different stages.
Table Table Rules Rules Spec Rules Rules Spec Rules Cases Rules/Spec
Sched Schedules
Schedules Schedules Reports
ules
Sl Trace Tracing to
Filed Number <Table Number>-<Field Number>
1 Target Field
2 Target Table
3 Source Field
4 Source Table / File
5 Clean Rule
6 Clean Program
7 Clean Report
8 Extract Rule
9 Extract Program
10 Extract Job
11 Extract Schedule
12 Transfer Spec
13 Transfer Program
14 Transfer Jobs
15 Transfer Schedule
16 Transform Spec
17 Transform Program
18 Transfer Job
19 Transfer Schedule
20 Clean Rule
21 Clean Program
22 Clean Report
23 Load Spec
24 Load Program
25 Load Job
26 Load Schedule
27 Clean Rule
28 Clean Program
29 Clean Report
Sl Trace Tracing to
30 Test Case (Unit/Integration)
31 Test Script (Unit/Integration)
32 Test Result (Unit/Integration)
33 Test Report (Unit/Integration)
34 Validation Rule
35 Validation Script
36 Validation Report
37 Audit Rule
38 Audit Script
39 Audit Report
The strategy developed for the data migration has been modularized to enable restart of the process at
any stage of failure.
The exception handling during outage window will be decided based on the business criticality of the data
that is migrated.
1. Stop the migration. Delete everything and start from the first
2. Write the exception in separate file and continue with the migration without inserting
that record
3. Write the exception in separate file and continue with the migration by inserting the
record with pre defined values.
4. Stop the migration. Analyze the exception, solve it and restart the migration from the
last commit point
3 Risks
Target Database Design is not available on time. This may impact on defining mapping rules and
transformation rules and the whole migration process.
The production cut-over window for implementation is expected to be 48 hours over a weekend.
This window might get reduced.
Environment readiness
4 Guidelines
Pre extraction data cleansing is advisable for voluminous non-critical data
Vertical split of the source data is preferable only when design of the target data model demands
it. Vertical split to handle the voluminous data is not recommended.
The scripts written for extraction and all other activities needs to be written in standard formats
and back ups taken periodically.
Non Critical and back up data can be migrated two weeks before the system goes live.
5 Recommendation
1. Target data model for conversion database is yet to be firmed up. Once we have the firmed up
target model, the mapping can be started. However, the iterative development model of ING Core
AFP project definitely demands for an iterative construction and unit testing phase for the data
migration programs. .
2. The assumption of month-end-weekend implementation of the whole ING Core AFP Data
Migration may not hold good. The DM POC can be used as a contingency plan for the complete
implementation.
3. The fine line between the several interfaces and the cutoff scenario of data migration has to be
properly monitored. Several cutoff issues are related to the handling of the interfaces during the
cutover window. We recommend formal weekly interaction among the interface team, migration
team, business capability team and maintenance team.
4. The complete migration life cycle (extraction to loading on target data base) has been designed
with redundancy and modularity. This is to ensure that in every logical break point one can
commit or restart.
5. To minimize the risk, the implementation strategy assumed a one off data migration on the
weekend and incremental build for five days. This portion will include only the data that are
unlikely to change. The data related to active accounts will be migrated on the production cutover
weekend.
7. The data migration for the phase I and phase II will be assumed to be two separate
implementations.
8. Candidate field analysis for all the source data is recommended upfront to identify the potential
data-cleansing requirement.
6 Responsibility Matrix
"Responsibility
matrix.xls"