Data Conversion Strategy Project Name
Ministry/Agency Name
Complete file/properties to populate fields on this page and in the document headers. To see instructions select Tools/Options Print tab, and make sure that “Hidden Text” is checked. Delete red instructions when filling in the template or select Tools/Options Print tab, and make sure that “Hidden Text” is not checked.
Project Name
Project #:
Data Conversion Strategy
Prepared by: Author's Name
Prepared for: [Company Name]
Date Submitted: [Date]
Project Sponsor: Project Sponsor's Name
Client Acceptor: [if different than Sponsor]
Project Manager: [Project Manager’s Name]
Document Number: 6450-20/Project Number /CVS
Security Classification: Low
Version: 0.1
Last Updated: January 23, 2012
Creation Date: [Date]
About this template: This template uses built in styles to assist the author in preparing the layout of the document. For assistance with styles, please contact the Project Support Office.
Table of Contents
Table of Contents 2
1. Introduction 3
2. Background 4
2.1. Purpose 4
2.2. Scope and Application 4
3. Conversion Requirements 5
4. Constraints and Assumptions 6
5. Conversion Approach 7
6. Implementation Approach 9
6.1. Planning Approach 9
6.2. Deliverables 9
7. Conversion Team Organization 10
7.1. Conversion Team 10
7.2. Roles and Responsibilities 10
8. Conversion Resource Requirements 11
8.1. Software 11
8.2. Hardware Environment 11
8.3. Network / File Transport 11
8.4. Staffing 11
8.5. Other 12
9. Project Standards 13
9.1. Tool Standards 13
9.2. Deliverable Naming Standards 13
10. Data Clean-up Process 14
10.1. Data Clean-up 14
10.2. Key Data Translations 14
11. Testing Strategy 15
12. Business System Processing 16
12.1. Delivery 16
12.2. Data Acceptance 16
13. Issue Tracking Process 17
13.1. Issue Management Procedure 17
13.2. Issue Resolution 17
14. Version Control Procedures 18
15. Project Metrics 19
16. Project Milestones 20
17. Conversion Risks 21
Revision Log 22
Appendices 23
Approval 24
1. Introduction
This document is used to determine the strategy for meeting the defined conversion requirements. The Data Conversion Strategy is intended to provide a roadmap for performing the conversion of data from the legacy system to the new Oracle system. The tasks and resources needed to fulfill this strategy are also discussed in this deliverable. The strategy in the deliverable template is based upon the proven conversion methods practiced by the Oracle Advanced Conversion Technologies (ACT) Group.
The Data Conversion Strategy is used as follows:
· The conversion team uses this document to communicate to the client the strategy for successfully converting their legacy data to the new Oracle system(s).
· The conversion team uses this document as a roadmap for performing the conversion. All members of the team, both consultants and client team members, should understand and follow the same strategy.
· The project manager uses this document to understand how the conversion team plans to perform the conversion, and how the conversion effort may impact the overall project.
Therefore, the readers of the Data Conversion Strategy include the following:
· the client project leader who should sign-off the conversion requirements and strategy
· each member of the conversion team
· the project leader who needs to review and determine what other groups should be given the document
Use the following criteria to review this deliverable:
· Is the strategy understood by those on the distribution list for this deliverable?
· Are all assumptions, constraints, and risks which could impact the conversion process stated and understood?
2. Background
Describe how the system to be converted is used by your client management.
2.1. Purpose
The purpose of this document is to provide Ministry/Agency Name with a strategy for planning the conversion project to ensure the highest quality conversion. This deliverable document summarizes the key areas to focus on in organizing, planning, and executing the conversion project tasks and deliverables.
2.2. Scope and Application
The application of this Data Conversion Strategy provides direction for all phases in conjunction with the Oracle Custom Development Method.
3. Conversion Requirements
Detailed conversion requirements are documented here. Identify the legacy system entities that are being converted to the new applications.
Insert text here.
4. Constraints and Assumptions
List all assumptions on which the tasks, resources, and conversion execution strategies are based.
The following constraints and assumptions apply:
· conversion project start date:
· target production date:
5. Conversion Approach
This section describes a proven conversion method which has been developed and successfully implemented. An explanation of the method is given and is intended to give the client and the conversion team an understanding of how the conversion will be performed.
This section provides a graphical description of the conversion approach which will be used to convert the <System to be Converted> to the new application. An explanation of this strategy follows.
Insert diagram here.
Insert diagram caption here.
Review the description below. More detail can be added to make this description of the conversion method specific to the company’s requirements. There are many different options for building the conversion scripts including several automated conversion tools.
1. Data Mapping
The data mapping process provides detailed lists of the <System to be Converted> data sets and data elements that will need to be moved into the Oracle tables during the data conversion. During this process, some decisions will need to be made with regard to obtaining required information needed by the target application which may not be present in the old system. Default settings, user input, and new data entries are many issues that must be addressed during this phase.
The output of this section is data mapping spreadsheets that show what is needed for the Oracle target application processing to meet business operational requirements and where these data elements will come from.
2. Download Programs
These programs are used to extract the identified conversion data elements from the current existing <System to be Converted>. What tool is used to accomplish this task is usually dependent on the abilities of the current system to develop an ASCII flat file. It is important to remember how the flat file will be structured (the order of the records as they are pulled) , type of delineation used, number of records, etc. This must match how the interim tables are set up. The output from this is the ASCII flat files identified in the next section.
3. ASCII Flat File
Most database or file systems output data in text form. A comma or space delimited, variable or fixed format data file from the existing system should be generated. If you cannot find a way to produce clean text data, try generating a report to disk, using a text editor to format your data.
4. Upload Program
Once data has been put into an ASCII flat file and physically moved onto the same computer that has the Oracle RDBMS, the next step is to load the data into a relational database environment.
Programs must be written and run to move data, validate data, and perhaps insert standard values into default fields. Usually a single loader program is written for each data table being loaded.
5a. Description of Interface Table
The detailed technical description of any interface table that the data is placed into from the ASCII flat file is described. A temporary table which mimics the production table that the data will eventually be loaded into should be built. This allows you to manipulate the data as needed before loading the legacy data into the production tables.
5b. Creation of Interface Table
Before loading the Oracle application production tables, the legacy data should first be loaded into temporary or interface tables. The interface tables provide a location for you to manipulate and translate the data as needed before validating the data and loading the application production tables. These temporary interface tables need to be built before you run the loader script to populate these tables.
6. Translation Programs
These scripts are developed to translate data from the existing system format into useful data for the Oracle target application. An example of this might be taking the date format that exists in the legacy system and converting it into an Oracle format. There may be several or no translation programs, depending on both the type of data coming across and the format of that data.
7. Interface Programs
The interface program scripts are used to populate the production database. The purpose of the interface programs is not only to move the data to the target tables but also to validate the data which would be validated by the form in the target module if the data was converted manually.
8. Application Production Table
This is the final production data table where the converted data resides. These tables are identified early on when doing the initial data mapping. These tables drive some of the translation programs that must ultimately ensure that 100% of the required information that the target applications require is present in the final data structures.
9. Testing
This test plan has been integrated into the entire conversion process so that, even during the pre-conversion steps, some type of validation reports are generated from the,<System to be Converted> systems, to be compared later with the converted data.
The approach to data validation
10. Write and Perform Conversion Execution Plan
The conversion execution plan is the execution document meant to be followed when performing the actual conversion. This document is specifically tailored for the <Company Short Name> conversion.
The following steps within the approach described above will be managed using the automated conversion tool described below:
6. Implementation Approach
6.1. Planning Approach
Briefly identify the development method and/or lifecycle being used on the project and identify the major lifecycle phases. Alter the statements below to suit the project’s actual approach.
A waterfall development method is being used on this project. The method covers the following phases of the project life cycle:
· Definition
· Analysis
· Design
· Build
· Transition
· Production
6.2. Deliverables
This section lists the tasks and deliverables which will be produced during this conversion project:
Task / Deliverable /Document Data Conversion Requirements / Data Conversion Strategy
Define Data Conversion Strategy / Data Conversion Strategy
Define Data Conversion Workplan / Data Conversion Workplan
Design Data Conversion Modules / Data Conversion Module Design
Code Conversion Modules / Conversion Modules
Perform Conversion Module Test / Conversion Module Test Results
Convert and Verify Data / Converted and Verified Data
7. Conversion Team Organization
7.1. Conversion Team
The organization structure for this conversion project is as follows:
·
·
7.2. Roles and Responsibilities
The conversion project roles will be staffed by the indicated person:
Oracle Team Member / Client Team Member / Role /Conversion Project Manager
Analyst
Module Designer
Programmer
Tester
Technical Expert
8. Conversion Resource Requirements
The following software and hardware requirements are considered a part of this conversion effort:
8.1. Software
The application software considered as part of this project includes:
Legacy Environment (Source):
·
·
·
Oracle Environment (Target):
·
·
8.2. Hardware Environment
The hardware and operating software to be used includes:
Legacy Environment:
·
·
·
Oracle Environment:
·
·
·
8.3. Network / File Transport
8.4. Staffing
The staff involved with this project must have the background , experience, and training in the following areas:
·
·
·
Below is a list skills which the current conversion project team does not fulfill:
·
·
8.5. Other
9. Project Standards
9.1. Tool Standards
If the standards are the same as the overall project standards then refer the reader to the appropriate deliverable.
A list of tool standards specific to the conversion project follows:
Application Tools:
·
Conversion Tools:
·
Source Control:
·
Version Control:
·
System Management Tools:
·
9.2. Deliverable Naming Standards
The following table provides instructions on how to name files, programs, and other project deliverables.
Program Type / Format / Extension / Example /Upload Module
Download Module
Interface Table Creation Module
Translation Module
Interface/ Conversion Module
Word Documents
Other Project Deliverables
10. Data Clean-up Process
10.1. Data Clean-up
Specific areas (entities) which are candidates for data clean-up include the following:
·
·
10.2. Key Data Translations
Strategic data which requires translation includes the following entities:
·
·
·
11. Testing Strategy
The agreed upon conversion project deliverables should be signed-off by those client representatives who are responsible for the success of the conversion project. In addition three levels of conversion testing have been identified and described in the Data Conversion Module Design deliverable document. The following criteria should be considered while performing data integrity and conversion integration testing:
· record counts
· hash totals
· balances
· journal debits and credits (balanced transactions)
12. Business System Processing
12.1. Delivery
All conversions will be deemed to be delivered following successful business system testing. Conversion data acceptance criteria should include the following:
· transactability
· ability to reconcile financial information
· definition and acceptance of account level variances
12.2. Data Acceptance
Describe the client’s data acceptance criteria.
13. Issue Tracking Process
13.1. Issue Management Procedure
All conversion issues will be tracked and managed as part of the overall project level implementation process.
13.2. Issue Resolution
All conversion issues will be resolved using the overall project issue resolution process.
14. Version Control Procedures
All versions of instance information and conversion modules will be managed under version/source control. The version source control strategy being used by the overall project will be followed.