<PROJECT NAME>

DATA CONVERSION PLAN

Version: <0.0>
Date:<XX/XX/XXXX>

Prepared by:

Project Manager
Approved by:

Project Sponsor
Approved by:

Agency CIO
Approved by:

Executive Sponsor
Table of Contents
1 INTRODUCTION 4
1.1 Purpose and Description 4
1.2 Data Conversion Objectives 4
1.3 Assumptions 4
1.4 Constraints 4
1.5 Risks 4
1.6 Unresolved Issues 4
2 DATA CONVERSION STRATEGY 4
2.1 Conversion Scope 4
2.2 Type of Conversion 5
2.2.1 Hardware Conversion Strategy 5
2.2.2 Software Conversion Strategy 5
2.3 Data Conversion Approach 5
2.3.1 Interfaces 5
2.4 Data Quality Assurance and Control 5
2.5 Data Validation and Verification 6
3 CONVERSION PLANNING 6
3.1 Pre-Conversion Tasks 7
3.2 Major Tasks and Procedures 7
3.2.1 Major Task Name 7
3.2.2 Procedures 7
3.2.3 Prerequisites 7
3.2.4 Backup Strategy 7
3.2.5 Fallback Process 7
4 SECURITY 8
4.1.1 System Security Features 8
4.1.2 Security During Conversion 8
5 ROLES AND RESPONSIBILITIES 8
5.1 Training of Conversion Staff 9
6 CONVERSION SCHEDULE 9
7 CONVERSION SUPPORT 9
7.1 Hardware 10
7.2 Software 10
7.3 Facilities 10
8 DATA CONVERSION PROCESS DIAGRAM 10
9 10
10 PROJECT REFERENCES 10
11 GLOSSARY 11

Revision History
Date Version Description Author

XX/XX/XXXX 0.0 Describe update(s). <First Name, Last Name>

Template Overview and Instructions:

The Conversion Plan describes the strategies involved in converting data from an existing
system to another hardware or software environment. It is appropriate to reexamine the original
system’s functional requirements for the condition of the system before conversion to determine
if the original requirements are still valid. An outline of what is needed in a Conversion Plan is
described below.>
Note: This template is for guidance only and may be revised to capture other areas of concern as it relates to
each projects specific data conversion.
1 INTRODUCTION

1.1 Purpose and Description

<This section describes the purpose and description of the Conversion Plan.

1.2 Data Conversion Objectives

<This section should describe the objectives of the Data Conversion and intended outcomes.>

1.3 Assumptions
<This section is for listing assumptions necessary for a successful conversion of data.>

1.4 Constraints
<This section is for listing constraints to identify areas of concern.>

1.5 Risks
<The following Table summarizes the risks identified to date that are specific to the data
conversion activities, and environment.>

# Risk Name Risk Trigger Potential Probability Risk

Description Point Outcome Strategy

1.6 Unresolved Issues

<Describe issues pending further analysis.>

2 DATA CONVERSION STRATEGY

This section provides the strategy for all aspects of the conversion effort, which are discussed in
the subsequent sections.

2.1 Conversion Scope

<This section provides the scope of the conversion, including a list of data types, and technical
components that will be affected/changed by the data conversion.

If the conversion process will be broken into discrete phases, this section should identify which
components will undergo conversion in each phase. Include hardware, software, and data as
appropriate. Charts, diagrams, and graphics should be listed in Section7: Data Conversion and
Process Diagrams.>

2.2 Type of Conversion

<This section describes the type of conversion effort. The software part of the conversion effort
usually falls into one of the following categories:

● Intra language conversion is a conversion between different versions of the same

computer language or different versions of a software system, such as a database management
system (DBMS), operating system, or local area network (LAN) management system.

● Inter language conversion is the conversion from one computer language to another or
from one software system to another.

● Same compiler conversions use the same language and compiler versions. Typically,
these conversions are performed to make programs conform to standards, improve program
performance, convert to a new system concept, etc. These conversions may require some
program redesign and generally require some reprogramming.

In addition to the three categories of conversions described above, other types of conversions
may be defined as necessary.>

2.2.1 Hardware Conversion Strategy

<This section describes the strategy to be used for the conversion of system hardware, if any.
Describe the new (target) hardware environment, if appropriate.>

2.2.2 Software Conversion Strategy

<This section describes the conversion strategy to be used for software>.

2.3 Data Conversion Approach

<This section describes the specific data preparation requirements and the data that must be
available for the system conversion. If data will be transported from the original system, provide
a detailed description of the data handling, conversion, and loading procedures. If these data
will be transported using machine-readable media, describe the characteristics of those media.>

2.3.1 Interfaces
<In the case of a hardware platform conversion - such as mainframe to client/server - the
interfaces to other systems may need reengineering. This section describes the affected
interfaces and the revisions required in each>.

2.4 Data Quality Assurance and Control

<This section describes the strategy to be used to ensure data quality before and after all data
conversions. This section also describes the approach to data scrubbing and quality
assessment of data before they are moved to the new or converted system. The strategy and
approach may be described in a formal transition plan or a document if more appropriate.>

2.5 Data Validation and Verification

<This section describes the data validation, data verification, and testing for the validity and
accuracy of the converted data elements. It is based on what is required and how well the
converted data complies with those requirements> Samples provided below.

No. Quality Assurance Area Description QA Verification

1 Required DM Data Formats Verify that the Columbia Ultimate Business Inspect the full cycle layout file,
Systems RPCS data conversion program run the ETL which loads the file,
placed the converted data elements in the analyze defects, and implement
full cycle layout which is a fixed length text any corrective actions.
file format (see Section Error! Reference
source not found.
2 Data Type Redefinitions Verify the data converted does not contain - Indexes will be created by the
alpha characters in numeric fields or DM FCL processing and are not
duplicate values in a unique index. being converted.
- The RPCS data conversion
program will convert dates,
times, phone numbers and
SSN/EIN to the DM format.

3 CONVERSION PLANNING
<This section describes planning for the conversion effort. If planning and related issues have
been addressed in other life-cycle documents, reference those documents in this section. The
following list provides some examples of conversion planning issues that could be addressed:

● Analysis of the workload projected for the target conversion environment to ensure that
the projected environment can adequately handle that workload and meet performance and
capacity requirements

● Projection of the growth rate of the data processing needs in the target environment to
ensure that the system can handle the projected near-term growth, and that it has the
expansion capacity for future needs

● Analysis to identify missing features in the new (target) hardware and software
environment that were supported in the original hardware and software and used in the original
system.

● Development of a strategy for recoding, reprogramming, or redesigning the components

of the system that used hardware and software features not supported in the new (target)
hardware and software environment but used in the original system.>

3.1 Pre-Conversion Tasks

<This section describes all tasks that are logically separate from the conversion effort itself but
that must be completed before the initiation, development, or completion of the conversion
effort. Examples of such pre-conversion tasks include:

● Finalize decisions regarding the type of conversion to be pursued.

● Install changes to the system hardware, such as a new computer or communications
hardware, if necessary.
● Implement changes to the computer operating system or operating system components,
such as the installation of a new LAN operating system or a new windowing system.
Acquire and install other software for the new environment, such a new DBMS or document
imaging system.>

3.2 Major Tasks and Procedures

<This section addresses the major tasks associated with the conversion and the procedures
associated with those tasks to include Prerequisites, Backup Strategy and Fallback Process.>

3.2.1 Major Task Name

<Provide a name for each major task. Provide a brief description of each major task required for
the conversion of the system, including the tasks required to perform the conversion,
preparation of data, and testing of the system. If some of these tasks are described in other life-
cycle documents, reference those documents in this section.>

3.2.2 Procedures
<This section should describe the procedural approach for each major task. Provide as much
detail as necessary to describe these procedures.>

3.2.3 Prerequisites
<This section should describe prerequisites for the conversion of the system. Describe what is
required for another task/activity to happen. Provide as much detail for each prerequisite.>
 3.2.4 Backup Strategy
<This section should describe the strategy for when a backup is done (daily, weekly, and
monthly) and on what servers or databases. What conditions would apply? Provide information
to describe when they are no longer needed.>

3.2.5 Fallback Process

<This section should describe the fallback plan and process in event the conversion of the
system is not successful. The fallback process should describe how the data conversion
environment needs to be set back to an earlier point in time, due to corrupt data, incomplete
conversion, or infrastructure failures.>

4 SECURITY
<If appropriate for the system to be implemented, provide an overview of the system security
features and the security during conversion.>

4.1.1 System Security Features

<The description of the system security features, if provided, should contain a brief overview
and discussion of the security features that will be associated with the system when it is
converted. Reference other life-cycle documents as appropriate. Describe the changes in the
security features or performance of the system that would result from the conversion.>

4.1.2 Security During Conversion

<This section addresses security issues specifically related to the conversion effort.>

5 ROLES AND RESPONSIBILITIES

<Provide project team Roles and Responsibilities and the Responsibility Assignment Matrix to
fully convert data as stated. Include all personnel for the staff required during the conversion
period. Samples are provided below>.

Role Name FTE Responsibility/ Skill Levels Estimated Estimated

Start Date End Date

Data Conversion Tom Jones 1.0 Provide review and oversight of the data conversion 12/1/15 6/30/17
Manager Deputy PM planning and activities. Leads the data conversion
related procurement for the project.
 Responsibility Assignment Matrix
Pro Dat Dat Dat DoIT Co Co De Proj Pr Dep Bu Da DoI
ject a a a or Pr ns ns vel ect oj uty si ta T
Pro Con Con Con DBM og ult ult op Tec ec Proj ne An Infr
gra ver ver ver Proc ra an an er hni t ect ss aly ast
m sio sio sio urem m t/ t/ cal Sp Spo An st ruc
Data Conversion Activities by Role Mgr n n n ent S S PM on nso aly tur
(Sample below) mi
. Proj Mgr Ana Offic ng M M so r st e
ect . lyst er Se E E r Le
Mgr rvi ad
. ce
s
Data Conversion Related Procurements
Mapping
Manual Entry
Developing Specifications for Conversion
Program
Test Conversion Program
Verify Data Converted
Iterative Balancing, Data Validation, and Data
Verification
Key’ R = Responsible = “the doer”. Those who do the work to achieve the task. There is at least one role with a
participation type of responsible, although others can be delegated to assist in the work required.
A = Accountable (also approver or final approving authority) = “the buck stops here”. The one ultimately answerable for the
correct and thorough completion of the deliverable or task, and the one who delegates the work to those responsible.
In other words, an accountable must sign off (approve) work that responsible provides. There must be only one
accountable specified for each task or deliverable.
C = Consulted (sometimes counsel) = “in the loop”. Those whose opinions are sought, typically subject matter experts;
and with whom there is two-way communication.
I = Informed = “kept in the picture”. Those who are kept up to date on progress, often only on completion of the task or
deliverable; and with whom there is just one-way communication.

5.1 Training of Conversion Staff

<This section addresses the training, if any, necessary to prepare the staff for converting the
system.

6 CONVERSION SCHEDULE
<This section provides a schedule of activities to be accomplished during the conversion. Pre-
conversion tasks and major tasks for all hardware, software, and data conversions described in
The Conversion Tasks section, should be described here, and should show the beginning and
end dates of each task.>
Task Task Description Begin End Date Key Person(s) Dependencies Miles
# Date Responsible tone
1 Write Data Conversion Plan 10/01/14 03/31/15 Technical PM and Configuration YES
Design Team signing off on
Architect configuration design
baseline.

7 CONVERSION SUPPORT
<This section describes the support necessary to implement the system. If there are additional
support requirements not covered by the categories shown here, add other subsections as
needed.>

7.1 Hardware
<This section lists support equipment, including all hardware to be used for the conversion.>

7.2 Software
<This section lists the software and databases required to support the conversion. It describes
all software tools used to support the conversion effort, including the following types of software
tools, if used:

● Automated conversion tools, such as software translation tools for translating among
different computer languages or translating within software families (such as, between release
versions of compilers and DBMSs)
● Automated data conversion tools for translating among data storage formats associated
with the different implementations (such as, different DBMSs or operating systems)
● Quality assurance and validation software for the data conversion that are automated
testing tools
● Computer-aided software engineering (CASE) tools for reverse engineering of the
existing application
● CASE tools for capturing system design information and presenting it graphically
● Documentation tools such as cross-reference lists and data attribute generators
● Commercial off-the-shelf software and software written specifically for the conversion
effort>

7.3 Facilities
<This section identifies the physical facilities and accommodations required during the
conversion period.>
8 DATA CONVERSION PROCESS DIAGRAM
<Provide diagrams for each process area of the Data Conversion>.

10 PROJECT REFERENCES
<This section provides a bibliography of key project references and deliverables that have been
produced before this point in the project development. These documents may have been
produced in a previous development life cycle that resulted in the initial version of the system
undergoing conversion or may have been produced in the current conversion effort as
appropriate>.

Document Name Description Location

11 GLOSSARY
<This section contains a glossary of all terms and abbreviations used in the plan. If it is several
pages in length, it may be placed in an appendix.>

Term Definition