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 NameProject #:

Data Conversion Strategy

Prepared by: Author's NamePrepared for: [Company Name]Date Submitted: [Date]

Project Sponsor: Project Sponsor's NameClient Acceptor: [if different than Sponsor]Project Manager: [Project Manager’s Name]

Document Number: 6450-20/Project Number /CVSSecurity Classification: LowVersion: 0.1

Last Updated: [Date]Creation Date: [Date]

Data Conversion Strategy Project Name

Table of Contents

Table of Contents...............................................................................................................21. Introduction................................................................................................................. 32. Background................................................................................................................. 4

2.1. Purpose..........................................................................................................................42.2. Scope and Application....................................................................................................4

3. Conversion Requirements.........................................................................................54. Constraints and Assumptions...................................................................................65. Conversion Approach.................................................................................................76. Implementation Approach..........................................................................................9

6.1. Planning Approach.........................................................................................................96.2. Deliverables....................................................................................................................9

7. Conversion Team Organization...............................................................................107.1. Conversion Team.........................................................................................................107.2. Roles and Responsibilities............................................................................................10

8. Conversion Resource Requirements......................................................................118.1. Software........................................................................................................................118.2. Hardware Environment.................................................................................................118.3. Network / File Transport...............................................................................................118.4. Staffing..........................................................................................................................118.5. Other.............................................................................................................................12

9. Project Standards.....................................................................................................139.1. Tool Standards.............................................................................................................139.2. Deliverable Naming Standards.....................................................................................13

10. Data Clean-up Process.............................................................................................1410.1. Data Clean-up...............................................................................................................1410.2. Key Data Translations..................................................................................................14

11. Testing Strategy........................................................................................................1512. Business System Processing..................................................................................16

12.1. Delivery.........................................................................................................................1612.2. Data Acceptance..........................................................................................................16

13. Issue Tracking Process............................................................................................1713.1. Issue Management Procedure......................................................................................1713.2. Issue Resolution...........................................................................................................17

14. Version Control Procedures....................................................................................1815. Project Metrics..........................................................................................................1916. Project Milestones....................................................................................................2017. Conversion Risks......................................................................................................21Revision Log.....................................................................................................................22Appendices.......................................................................................................................23Approval............................................................................................................................. 24

Last revised: 2019-10-02 Page 2 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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?

Last revised: 2019-10-02 Page 3 of 24

Security Classification: Low

Data Conversion Strategy Project Name

2. Background

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.

Last revised: 2019-10-02 Page 4 of 24

Security Classification: Low

Data Conversion Strategy Project Name

3. Conversion Requirements

Insert text here.

Last revised: 2019-10-02 Page 5 of 24

Security Classification: Low

Data Conversion Strategy Project Name

4. Constraints and Assumptions

The following constraints and assumptions apply:

conversion project start date: target production date:

Last revised: 2019-10-02 Page 6 of 24

Security Classification: Low

Data Conversion Strategy Project Name

5. Conversion Approach

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.

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.

Last revised: 2019-10-02 Page 7 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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:

Last revised: 2019-10-02 Page 8 of 24

Security Classification: Low

Data Conversion Strategy Project Name

6. Implementation Approach

6.1. Planning 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 DeliverableDocument Data Conversion Requirements Data Conversion StrategyDefine Data Conversion Strategy Data Conversion StrategyDefine Data Conversion Workplan Data Conversion WorkplanDesign Data Conversion Modules Data Conversion Module DesignCode Conversion Modules Conversion ModulesPerform Conversion Module Test Conversion Module Test ResultsConvert and Verify Data Converted and Verified Data

Last revised: 2019-10-02 Page 9 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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 RoleConversion Project ManagerAnalyst Module DesignerProgrammerTesterTechnical Expert

Last revised: 2019-10-02 Page 10 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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:

Last revised: 2019-10-02 Page 11 of 24

Security Classification: Low

Data Conversion Strategy Project Name

8.5. Other

Last revised: 2019-10-02 Page 12 of 24

Security Classification: Low

Data Conversion Strategy Project Name

9. Project Standards

9.1. Tool Standards

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 ExampleUpload ModuleDownload ModuleInterface Table Creation ModuleTranslation ModuleInterface/ Conversion ModuleWord DocumentsOther Project Deliverables

Last revised: 2019-10-02 Page 13 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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:

Last revised: 2019-10-02 Page 14 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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)

Last revised: 2019-10-02 Page 15 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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

Last revised: 2019-10-02 Page 16 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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.

Last revised: 2019-10-02 Page 17 of 24

Security Classification: Low

Data Conversion Strategy Project Name

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.

Last revised: 2019-10-02 Page 18 of 24

Security Classification: Low

Data Conversion Strategy Project Name

15. Project Metrics

The following metrics are considered in determining the complexity factors in the CDM estimating model:

existing record volumes by entity: volumes of data to be converted by entity: throughput of the conversion interfaces: number of users: number of concurrent users:

Last revised: 2019-10-02 Page 19 of 24

Security Classification: Low

Data Conversion Strategy Project Name

16. Project Milestones

The Development Team and <Company Long Name> will review and approve each project milestone by using the standard acceptance criteria for each task deliverable produced.

In addition to the previously defined conversion project deliverables, the following additional project milestone, which are subject to client acceptance have also been identified:

Phase Current Conversion Milestone Date

Actual Conversion Milestone Date

Last revised: 2019-10-02 Page 20 of 24

Security Classification: Low

Data Conversion Strategy Project Name

17. Conversion Risks

The following risks have been identified as having an impact on the overall success of the conversion project:

Last revised: 2019-10-02 Page 21 of 24

Security Classification: Low

Data Conversion Strategy Project Name

Revision Log

Date Version Change Reference Author Reviewed by[yyyy-mm-dd] 0.1

Last revised: 2019-10-02 Page 22 of 24

Security Classification: Low

Data Conversion Strategy Project Name

Appendices

Enter content here.

Last revised: 2019-10-02 Page 23 of 24

Security Classification: Low

Data Conversion Strategy Project Name

Approval

This document has been approved as the official Data Conversion Strategy for the Project Name project.

Following approval of this document, changes will be governed by the project’s change management process, including impact analysis, appropriate reviews and approvals, under the general control of the Master Project Plan and according to Project Support Office policy.

Prepared by Signature Date

Author's Name[Title][Organization]

Accepted by Signature Date

[Client Acceptor’s Name][Title][Organization]

Approved by Signature Date

[Client Approver’s Name][Title][Organization]

[Client Approver’s Name][Title][Organization]

[Project Manager’s Name][Title][Organization]

[IMG Approver’s Name][Title][Organization]

Last revised: 2019-10-02 Page 24 of 24

Security Classification: Low