Data Conversion Plan Template
Data Conversion Plan Template
CONVERSION
PLAN
VERSION 1.0
DATA CONVERSION PLAN
Page 1
DATA CONVERSION PLAN
APPROVAL SIGNATURES
Example:
CONTRACTOR DATE
<<SIGNATURE>> <<DATE>>
Comments
Page 2 of 60
DATA CONVERSION PLAN
DOCUMENT HISTORY
DOCUMENT APPROVAL HISTORY
Prepared By
Reviewed By
Approved By <<Typically the Project Sponsor>>
Page 3 of 60
DATA CONVERSION PLAN
TABLE OF CONTENTS
1. INTRODUCTION........................................................................1
1.1. CONVERSION OVERVIEW....................................................................3
2. PROJECT DEFINITION................................................................7
2.1. PURPOSE OF DATA CONVERSION PLAN...............................................7
2.2. GOALS AND OBJECTIVES.....................................................................7
2.3. SCOPE OF DATA CONVERSION............................................................8
2.3.1............................................................................................ INCLUSIONS
9
2.3.2........................................................................................... EXCLUSIONS
9
2.4. CRITICAL SUCCESS FACTORS..............................................................9
2.5. CONVERSION ACCEPTANCE CRITERIA...............................................11
2.5.1..................................................DEFINE DATA ERROR SEVERITY LEVELS
12
2.5.2..............................................................DEFINE ACCEPTANCE CRITERIA
12
2.6. ASSUMPTIONS, CONSTRAINTS, AND RISKS.......................................13
2.6.1........................................................................................ ASSUMPTIONS
13
2.6.2......................................................................................... CONSTRAINTS
15
2.6.3...................................................................................................... RISKS
15
2.6.4...................................................................RISK MITIGATION STRATEGY
17
2.7. COMMUNICATION STRATEGY.............................................................18
3. CONVERSION REQUIREMENTS.................................................20
3.1. BUSINESS REQUIREMENTS AND EXPECTATIONS...............................20
3.2. TECHNOLOGY AND INFRASTRUCTURE CONSIDERATIONS.................22
3.3. DATA SECURITY AND PRIVACY REQUIREMENTS.................................24
3.4. CONVERSION DATA SOURCES...........................................................24
5. DATA CLEANSING...................................................................29
6. CONVERSION APPROACH........................................................32
6.1. METHODS OF CONVERSION..............................................................32
6.2. DATA MAPPING..................................................................................34
6.3. DATA EXTRACTION AND STAGING PROCESS.....................................36
Page 4 of 60
DATA CONVERSION PLAN
9. CONVERSION IMPLEMENTATION..............................................57
9.1. APPROACH TO IMPLEMENTATION......................................................57
9.2. CONVERSION CUTOVER PROCESS....................................................59
9.3. IMPLEMENTATION PLANNING & CONSIDERATIONS............................60
9.4. DATA CERTIFICATION.........................................................................62
Page 5 of 60
DATA CONVERSION PLAN
Page 6 of 60
DATA CONVERSION PLAN
1.INTRODUCTION
[This template is the result of experience and research of best practices
concerning data migration/conversion. It is intended to provide a high-level
overview for those individuals who are not familiar with data conversion and
to serve as a guide or reference for those who are familiar with data
conversion and/or who are in the process of developing a data conversion
plan for the project at hand. Throughout the document, the terms convert
and transform, as well as, migration and conversion are used
interchangeably.]
[Virtually everything in business today is an undifferentiated commodity,
except how a company manages its information. How you manage
information determines whether you win or lose." Bill Gates.
Data conversions are a leading cause of schedule and quality issues in
enterprise application implementations. Research from several sources,
including Gartner, confirms that over 80% of data conversion efforts either
fail outright or suffer significant cost overruns and delays. As a result, they
jeopardize any other IT projects that depend on them. Some of the key
challenges for data conversion are:
Lack of staff with data conversion expertise.
Lack of clearly established and realistic data conversion requirements,
key stakeholder expectations, and data conversion acceptance
criteria.
Lack of documented and/or refined business rules.
Lack of data governance.
Lack of relevant business subject matter expert involvement.
Target system data models that change during the conversion effort.
Converted data was either validated only at the end and/or tested only
with a subset of the data.
Data conversion planning and scoping were done without a clear
understanding of the data architecture and data quality of the legacy
systems from which data is to be migrated.]
As depicted in Figure 1-1, data conversion is the process whereby data from
its current sources (e.g., existing legacy systems, hardcopies, document
images, etc.) is extracted, transformed, and loaded to a new system. For
most state departments, data conversion is often part of a larger legacy
system modernization project; it involves multiple databases, file structures,
utilities, toolsets, different computer languages, and computer operating
systems. Because it is a complex and time consuming process, data
Page 1 of 60
DATA CONVERSION PLAN
Page 2 of 60
DATA CONVERSION PLAN
Page 3 of 60
DATA CONVERSION PLAN
Page 4 of 60
DATA CONVERSION PLAN
Page 5 of 60
DATA CONVERSION PLAN
Page 6 of 60
DATA CONVERSION PLAN
2.PROJECT DEFINITION
This section describes the purpose of the data conversion plan, goals and
objectives, scope of data conversion, critical success factors, acceptance
criteria, assumptions, constraints, and risks associated with the plan for
achieving the goals and objectives.
Page 7 of 60
DATA CONVERSION PLAN
[Without goals, and plans to reach them, you are like a ship that has set sail
with no destination.- Fitzhugh Dodson.
There must be specific goals and objectives that the project intends to
achieve through the implementation of this data conversion plan. Primarily,
the goals and objectives of this effort may be that:
All data needed to support the following core business processes in the
new target system must be converted and migrated from the identified
legacy systems to the target system completely and accurately, as
compared to the source, and in accordance with department and
regulatory policies on information controls and security. Furthermore,
converted data must be compatible with the target application. This
means there are no dropped or incomplete records, and converted
data must work well with the target application.
Data conversion process must be completed within the allotted
timeframe during the conversion cutover.
The quality of converted data must meet or exceed the established
conversion acceptance criteria.]
Page 8 of 60
DATA CONVERSION PLAN
Scope is a set of boundaries that defines the extent of the data conversion
effort. These boundaries determine what falls inside or outside the data
conversion effort. Activities that fall inside the boundaries are considered in
scope and are planned for in the schedule and budget. If an activity falls
outside the boundaries, it is considered out of scope and is not planned.
This can be done by defining what the project will deliver.
As a reminder, scope of data conversion should address all aspects that are
related to data conversion, not just the development of conversion programs
and processes alone. For example, data validation, data cleansing, and post-
conversion support should be considered. Therefore, it is imperative that the
scope of data conversion is clearly defined at the outset of data conversion
to prevent scope creep, which might reduce the projects chances of
success. Since many state department data conversion efforts are part of a
larger legacy system modernization project, the scope of data conversion
concentrates on migrating the data from multiple legacy source systems to a
single target system, and includes interfaces and reports.]
[Define the scope of the data conversion effort. The scope should
include all pertinent information to enable the data conversion team
to properly plan for the level of effort, the timeline, and the
resources needed to accomplish tasks as well as to help identify
dependencies and potential risks.]
2.3.1. INCLUSIONS
[If needed, this section can be used to specifically describe all the major
components that are included in the scope of the data conversion effort.]
Page 9 of 60
DATA CONVERSION PLAN
The following items are included in the scope of the data conversion effort:
in-scope items notes
2.3.2. EXCLUSIONS
[If needed, this section can be used to specifically describe all the major
components that are NOT included in the scope of the data conversion
effort.]
The following items are excluded from the scope of the data conversion
effort:
Out-of-scope items notes
Page 10 of 60
DATA CONVERSION PLAN
[Identify all relevant success factors that are pivotal to your data
conversion effort.]
The following success factors are considered pivotal to the success of the
data conversion effort.
1. <<Success factor 1>>
2. <<Success factor 2>>
3. <<Success factor 3..>>
2.5. CONVERSION ACCEPTANCE CRITERIA
This section defines the conditions that must be met in order for the
converted data to be considered ready for cutover.
[Begin with the end in mind. - Stephen R. Covey.
It is nearly impossible to have all records migrated from source to target
with no functional, reconciliation, or compatibility data errors by the time of
system cutover. Therefore, working with the key data stakeholders to
formally establish the data conversion acceptance criteria at the outset is
crucial to the success of data conversion. Prior to the final data conversion
execution, if the data errors found are within the tolerance boundaries of the
established acceptance criteria, key data stakeholders can make a decision
to cutover operations to the new system. However, if the data errors found
are beyond the tolerance boundaries, key data stakeholders can decide to
postpone the cutover, continue operations on the source system until the
data errors are addressed, or go forward with the cutover as scheduled and
address the data errors post conversion.
Therefore, the best place to begin the data conversion effort is with
acceptance criteria. Acceptance criteria are a list of conditions that must be
met in order for the converted data to be considered ready for cutover.
Page 11 of 60
DATA CONVERSION PLAN
Page 12 of 60
DATA CONVERSION PLAN
Severity Defect prevents <<business function>> from Incorrect application of rules to create
2 rendering critical business services accurately offset transactions resulting in an
to its employees and Business Partners.
inaccurate account balance.
An acceptable workaround was provided and
approved by the <<project leadership team>>. Workaround: users should use the
Detailed Account screen to manually enter
adjustment transactions.
Severity Defect does not prevent current services from Incorrect data types and data defects
being rendered accurately by <<Department>> to
3 pertaining to old data used for
its employees and Business Partners.
reporting/inquiry purposes only.
FIGURE 2-4: DEFINITION OF DATA ERROR SEVERITY LEVELS
ACCEPTANCE CRITERIA
Business function (ranked) Severity MAXIMUM TOLERANCE AS %
OF CONVERTED DATA VOLUME
1st Priority Business Function 1 0.0%
(Data Volume: ####) 2 0.3%
3 1.0%
Page 13 of 60
DATA CONVERSION PLAN
2.6.1. ASSUMPTIONS
[Consider the following assumptions as some of them may be relevant to
your current project:
All severity 1 and 2 data exceptions originating from source data will
be cleansed by the data cleanup team before the scheduled final data
conversion execution.
At the minimum, one key business subject matter expert per business
domain will be available within 24 hours of the request.
All environments (legacy, staging, and target) are fully documented
(conceptual/logical data models, physical data model, business rules,
and interfaces), available, and accessible by the data conversion team
as scheduled.
Only client records with active status as previously defined and
agreed upon will be migrated over to new application system.
Page 14 of 60
DATA CONVERSION PLAN
<<First Assumption>>
<<Second Assumption>>
2.6.2. CONSTRAINTS
Page 15 of 60
DATA CONVERSION PLAN
<<First Constraint>>
<<Second Constraint>>
2.6.3. RISKS
[Risk may be defined as the chance or probability of something that has the
potential to cause the data conversion effort to fail or fail to meet one or
more of its planned objectives such as scope, schedule, cost, or quality.
There are many risks inherently associated with moving data between
computer systems or storage formats, not to mention the types and number
of risks that may be involved in transforming and migrating huge volumes of
data with many years of history from multiple sources and platforms, and in
various storage formats, to a new computer system storage format.
Therefore, it is important that all relevant risks are identified at the outset so
that they can be qualitatively and quantitatively analyzed and mitigated.
The following are some of the risks that may be relevant to the current
project:
The data conversion plan may not be feasible to achieve the expected
goals and objectives because data conversion scoping was based
entirely on theory and previous experience.
Page 16 of 60
DATA CONVERSION PLAN
Data conversion effort may not be able to meet the planned schedule
because the quality of source data is unknown.
Legacy data architecture artifacts may be unavailable or incomplete.
The expense of overtime may be required to perform certain steps
during non-business hours to reduce impact on the current production
system.
The team may encounter incompatible software, hardware, and/or
processes due to: multiple operating systems or vendors, or format
incompatibilities (Database Management System (DBMS) to DBMS,
DBMS to Operating System, etc.)
Data conversion effort may not be able to achieve the expected goals
and objectives because the existing data conversion team does not
have the necessary level of skills and experience to effectively execute
the required tasks.
Integrity and quality of the converted data may be compromised due
to lack of data governance.
Data quality of the target system may not meet the departmental
standards due to lack of properly defined business rules.
Data quality of the target system may not meet the departmental
standards because independent data validation was not considered
part of the data conversion scope of work.
Source data may be inaccurately transformed and migrated due to
lack of involvement of key business subject matter experts.
Source data may be inaccurately mapped due to lack of or outdated
legacy system data dictionary.
Data quality of the target system may not meet the departmental
standards because only a subset of the converted data was tested.
Data conversion may not be ready for cutover as scheduled because
no data conversion dress rehearsal was planned and included as part
of the data conversion scope of work.
Converted data may not be compatible, useable, or processed by the
new application system because functional requirements and test were
not part of the data conversion scope of work.]
[Describe all relevant risks, their probability, and the level of
impact with respect to scope, strategies, and/or goals of the data
conversion effort, particularly any risks related to funding, staff
expertise and availability, schedule constraints, legacy environment
complexity, hardware and software (conversion tools) availability,
incompatibility between software and operating system, etc. The
following tables may be used for this purpose, if appropriate.]
Page 17 of 60
DATA CONVERSION PLAN
Marginal Negligible
Page 18 of 60
DATA CONVERSION PLAN
Address only severity 1 data quality issues before the final dress
rehearsal.
Analyze legacy data before finalizing the data conversion scope.
Establish a separate team to independently validate and ensure that
all data is migrated accurately and completely.
Ensure that the integrity of the converted data is maintained.
Ensure that a comprehensive set of business rules is gathered,
documented, and signed off by business domain SMEs. These must be
centrally located and shared among the data conversion team, data
clean-up team, and data validation team.
Ensure that acceptance criteria are clearly defined, measurable, and
signed off by key data stakeholders.
Ensure that data governance is established and dedicated to address
data issues related to the data conversion effort.
Prepare a detailed inventory of what data and systems architecture
exist, and identify any data issues relevant to the conversion during
the early phases of the project
Ensure all resource dependencies, such as access to and availability of
environments (legacy data, staging, and target system), tools,
software licenses, or personnel are thoroughly identified.
Identify and secure primary and secondary SMEs with knowledge of
and experience with the legacy data.
Schedule recurring risk identification and brainstorming sessions to
actively identify potential challenges and opportunities associated with
each data conversion deliverable and dependency during the planning
phase. This minimizes risks or challenges being introduced at later
phases and allows time to proactively address these challenges and
opportunities now.]
[Provide a mitigation strategy for each of the anticipated risks
identified. The following table may be used for this purpose.]
Page 19 of 60
DATA CONVERSION PLAN
Data Conversion
Deliverables
Escalation Procedures
Conversion Design
Decision
Business Rules
3.CONVERSION REQUIREMENTS
[Accurately defining and clearly understanding each business and technical
requirement for data conversion is crucial for by these requirements the
project team can determine what data to migrate, whether or not archive
data is included as it may require a different conversion strategy all by itself,
what acceptable downtime is to the business during cutover, etc. These
requirements may take the form of agreements, expectations, and/or
objectives of the conversion.]
Page 20 of 60
DATA CONVERSION PLAN
Page 21 of 60
DATA CONVERSION PLAN
What is the expected timeframe for the overall data conversion effort?
Are there any future business objectives that may require
considerations for growth and scalability?]
Page 22 of 60
DATA CONVERSION PLAN
Page 23 of 60
DATA CONVERSION PLAN
Page 24 of 60
DATA CONVERSION PLAN
Page 25 of 60
DATA CONVERSION PLAN
<< Name of Data Source 1 >> or Platform: Oracle, MS Access, MS Excel, ADABAS, VSAM, ETC
Volume/Population: # of tables & rows, # of records, etc
<< Dataset / Record set >>
Business Function(s):
Key contact:
Data Owner:
Notes:
Page 26 of 60
DATA CONVERSION PLAN
DATA ANALYSIS
Perform data profiling analysis of the legacy source data.
Perform data quality assessment of the legacy source data based on
relevant and current business processes and business rules of the
current system and target system including any new or updated
changes. This process involves a number of tasks to be accomplished
in order to analyze the data, such as:
o Analyzing the target database structure.
o Collecting and analyzing samples of the legacy source data for
possible data discrepancies and potential problem areas. These
issues usually arise from missing fields, incomplete data,
duplicate data, incorrect data, or non-standard characters in
standard fields.
o Identifying any specific application business functionality that
may cause discrepancies in the conversion.
o Developing metrics and data audit and reconciliation reports
based on the quality of the legacy source data.
DATA PROFILING
Data profiling should be the first step of any data conversion project as it
is the most effective and practical way to have visibility and
understanding of the current data sources before any data conversion
planning activity begins. Error: Reference source not found provides an
example of a data profiling statistical analysis and assessment report.
Data profiling process assesses the data structures and data content of
the source systems to understand and determine any challenges
Page 27 of 60
DATA CONVERSION PLAN
Page 28 of 60
DATA CONVERSION PLAN
5.DATA CLEANSING
This section describes the process that will be used to facilitating data
cleansing.
[Data cleansing is required to ensure that legacy system data conforms to
the rules of data conversion. This process may involve manual and/or
automatic updates to legacy system data. Data cleansing should be an
ongoing business activity and as long as the legacy systems are active,
there is the potential that previously cleansed data issues are reintroduced.
Page 29 of 60
DATA CONVERSION PLAN
There are many different types of data issues requiring cleansing. For
example:
Duplicates - multiple records for the same person, same account, same
contract number, or same company.
Page 30 of 60
DATA CONVERSION PLAN
Page 31 of 60
DATA CONVERSION PLAN
Page 32 of 60
DATA CONVERSION PLAN
6.CONVERSION APPROACH
This section describes the approach to data conversion.
Page 33 of 60
DATA CONVERSION PLAN
Page 34 of 60
DATA CONVERSION PLAN
[Data mapping is the process of linking data elements between the legacy
system data models and the target data model. Data mapping is the
fundamental first step in data transformation in that it captures the
transformation rules between the legacy and target data models. It also
determines the relationship between the data elements of the target and
legacy systems and establishes instructions for how the legacy data is
transformed before it is loaded into the target system.
Figure 6-9 illustrates different levels of the mapping process. Once the
project has confirmed what functionality will be implemented in the target
system, it is recommended that the project begin mapping existing
functionality in the current legacy systems to the target system. Next, the
project should begin mapping objects of each function in the current legacy
systems to the corresponding objects of functionality in the target system;
this is followed by mapping the fields of each object in the current legacy
systems to the corresponding fields of object in the target system. Finally,
map the value(s) of each field to the corresponding field value(s) in the
target system, if applicable.
Page 35 of 60
DATA CONVERSION PLAN
Data mapping is the most critical activity that contributes to the data
conversion effort going off-track. This is because data mapping is a manual,
labor intensive process and requires multiple testing cycles to get it correct.
Furthermore, changes to mappings are difficult to manage among the data
conversion team members working in silos. Depending on data architectures
of the target and legacy systems and the condition of the legacy data
sources, transformation logic can also be very complex. These conditions
pose high risk to data conversion efforts in terms of data quality, schedule
slippage, and cost overruns. Therefore, it is recommended that the project
team research some of the tools that are commercially available to help
facilitate data mapping activities.
Moreover, because there are many conflicts among the data in different
legacy data sources, it is recommended that a centralized data dictionary be
established to facilitate data reconciliation. A data dictionary is a centralized
repository of information about data, such as its relationship to other data,
related business rules, its format and default values. It is often housed within
the staging area for the duration of a data conversion effort. Data mapping
is a complex task that requires attention to detail and a comprehensive
understanding of source and target data models. The information contained
in the data dictionary will be useful for data enrichment, transformation,
reconciliation, and data cleansing.]
[Identify what functionality will be needed in the target system and
the legacy data sources that are necessary to support the
functionality in the target system. Determine how the data will be
mapped to the target system and what conversion programs will
need to be developed in order to extract, transform, and load the
target system. Also, describe the process that will be used to
facilitate the data mapping process.
Since the function mapping will continue to be revised throughout
the data conversion lifecycle, rather than providing the information
in the table below, it may be more appropriate to have it included
as an appendix or an attachment. A data mapping template is also
provided as part of this document and a link to it is listed in
Appendix B.]
Page 36 of 60
DATA CONVERSION PLAN
[Data extraction and staging process describes the key steps of extracting
data from the legacy systems and placing them in a universal data store in a
homogeneous format for further interdependency analysis and
transformation. Figure 6-10 illustrates a conceptual process of data
extraction and staging.
Because most data sources reside in diverse environments and formats
(e.g., VSAM, ADABAS, MS Excel, MS Access, Oracle, DB2, etc.), it is
recommended that, especially for mainframe data, all data from every data
source within the data conversion scope first be extracted in its raw, native,
Page 37 of 60
DATA CONVERSION PLAN
stored form and placed in a universal data store in a delimited flat file
format. The purpose is twofold:
Data stored in a delimited flat file format can be easily accessed by
most technology available via an import function. Moreover, since the
target data structure is still unstable during this time for most projects,
the data conversion team can still make substantial progress on the
data extract development.
Extracting every known data element from each of the data sources
that are in scope is critical. Having every data field extracted really
saves time for the data conversion team as they do not have to go
through the process of determining whether or not a data element is
needed before writing the extraction code. In addition to that, they do
not have to modify the extraction code later for any additional data
elements that were initially overlooked.
The followings are the recommended approaches to data extract and staging
with respect to the three most common legacy data formats:
Mainframe Data
For mainframe data (e.g., VSAM, ADABAS, etc.), it is recommended that the
data be extracted in its raw, native, stored form and placed in a universal
data store in a delimited flat file format. These data files will then be
converted to ASCII format, which in turn will be loaded into the staging data
storage.
Desktop Data
For desktop data such as Microsoft Excel, Access, and other similar formats,
it is recommended that the data be extracted directly into a data file in ASCII
format and loaded directly into the staging data storage without any
transformation.
Relational Data
For relational data (e.g., Oracle, DB2, etc.), since the data is already in
relational format, it is recommended that the data be copied over to the
staging environment but not staged to avoid data redundancy.]
Page 38 of 60
DATA CONVERSION PLAN
Source Data what are the data source environments and how will
the data be extracted from each environment?
Staging - once the data from each environment is extracted, what
happens next? Where and how will it be staged? Are there any other
data processes?]
Page 39 of 60
DATA CONVERSION PLAN
Page 40 of 60
DATA CONVERSION PLAN
Page 41 of 60
DATA CONVERSION PLAN
Page 42 of 60
DATA CONVERSION PLAN
dependencies across legacy processes, systems, and data had not been
factored.]
[Describe the process to restore the source data if the need to
revert to a previous back-up is identified at any point during the
conversion process. Also, determine what precautionary measures
can be planned and implemented to minimize the need for
conversion reversal. Some suggestions are as follows:
Define stopping points and check points to terminate data conversion
under predefined conditions and rollback conversion to predefined
segments, if needed.
Determine and plan conversion dependencies, schedule, and
execution sequence of data conversion programs.
Tune and optimize data conversion programs continually to ensure the
entire data conversion will complete within the time allotted for
conversion.
Determine and plan for hardware and network resources to support
data conversion within the cutover window.]
Page 43 of 60
DATA CONVERSION PLAN
Page 44 of 60
DATA CONVERSION PLAN
<<Milestone>>
<<Milestone>>
Page 45 of 60
DATA CONVERSION PLAN
across all data conversion programs and artifacts. For each data conversion
program, the following standards will be followed:
Descriptive header describes the functionality being developed
including relevant references. This helps increases readability and
enables troubleshooting. Each conversion program will have:
o Program name
o List of arguments
o List of return values
o Date created
o Version number and date
o Modification history and author name.
Inline comments contains descriptive notes relevant to the section
being developed.
Indentation - all data conversion programs will be indented to improve
readability and consistency of format according to the established
coding standards document.
6.9.3. NAMING CONVENTIONS
This section provides a set of naming conventions to be used for data files,
databases, staging tables, conversion instances, and related conversion
artifacts.
[Define a set of naming conventions to be used for data files,
databases, staging tables, conversion instances, and related
conversion artifacts.]
Page 46 of 60
DATA CONVERSION PLAN
Page 47 of 60
DATA CONVERSION PLAN
This section describes the logical view of the data conversion environments
as shown in <<Figure ##>>. It provides a high-level layout of what
environments are needed and for what purpose, the inflow and outflow of
data between these environments, and the tools required to support data
conversion activities.
The data conversion environments are composed of the following individual
environments:
Production-Copy
Data Cleansing
Conversion Development
Validation and Reconciliation
Pre-Implementation
Page 48 of 60
DATA CONVERSION PLAN
Page 49 of 60
DATA CONVERSION PLAN
Total FTE
<<Role>> <<Description>>
<<Role>> <<Description>>
<<Role>> <<Description>>
Page 50 of 60
DATA CONVERSION PLAN
Page 51 of 60
DATA CONVERSION PLAN
Page 52 of 60
DATA CONVERSION PLAN
Page 53 of 60
DATA CONVERSION PLAN
[Since the aim of mock conversions is to identify and resolve any conversion
program issues and configuration problems as early as possible, each mock
conversion should have a well-defined set of specific strategic targets of
what it intends to achieve. The following is a suggested format and outlines
the important elements that should be included in the planning of a mock
conversion:]
Title: Mock Conversion <<##>>
Purpose: <<what does this mock conversion intend to achieve? >>
Duration: <<planned start and end dates>>
Key Participants:
<<Consultant key staff or teams>>
<<State key staff or teams>>
Other Participants: <<staff or teams that need to be informed>>
<<Consultant key staff or teams>>
<<State key staff or teams>>
Effort: <<number of hours estimated>
Basis for measuring progress: <<what will be used to measure progress?
>>
Dependencies: <<list all the items that this mock conversion depends
upon>>
Exit Criteria: <<list the criteria or requirements that must be met in order
for this mock conversion to be considered as complete. >>
[Furthermore, the following are some best practices to consider:
A data conversion run book should evolve out of the mock conversions to detail each step
of the conversion process, when each conversion step occurs, dependencies, who is
responsible, and so on.
Each mock conversion should be started with new data extracts, staging (if applicable),
transformation, and then load processes.
All error resolution and data validation processes should be conducted as part of the
overall mock conversion process to identify and resolve errors, determine new error
resolution, verify data validation requirements, and continue to refine the process.
Mock conversions should be conducted in an environment that closely resembles that of
the target environment. Configuration and customizations in this environment should be
frozen including the database instance where the mock conversion takes place. If
Page 54 of 60
DATA CONVERSION PLAN
changes are made to the configuration as a result of necessary adjustments made to the
mock conversion process, they should be documented.]
[Describe the approach that will be used to identify and resolve any
conversion program issues and configuration problems ahead of
time. Also, describe what approach is to be used to assess data
conversion readiness, and to ensure that the entire data conversion
process can be finished within the timeframe allocated for data
conversion cutover.]
Page 55 of 60
DATA CONVERSION PLAN
Page 56 of 60
DATA CONVERSION PLAN
Page 57 of 60
DATA CONVERSION PLAN
Page 58 of 60
DATA CONVERSION PLAN
This section describes the process that will be used to identify, escalate, and
resolve data errors during the data conversion process.
[Each conversion dataset or data domain will have its own set of unique data
errors that will require resolution during conversion testing, mock
conversions, and even during final go-live conversions. Therefore, it is
recommended that a data error resolution process be developed for each
business function in order to effectively address its own unique data errors.
The following are the two common types of errors specific to conversion data
loads.
Critical data errors are those that prevent a record from being loaded
into the target data storage and/or cause data integrity errors. These
types of data errors should be identified and addressed as soon as
possible. If possible, these types of data errors should be corrected in
the legacy system prior to subsequent extracts and loads. Critical
data errors will more than likely prevent continuing with other
conversion loads that are dependent on the failed records and must be
resolved quickly or the records have to be skipped or removed from
subsequent conversions until fixed.
Non-Critical data errors are those that have invalid values or missing
configuration data which will not prevent a record from being loaded.
These types of errors should be identified and reported for resolution.
[Describe the process that will be used to identify, escalate, and
resolve data errors during the data conversion process and the
roles and responsibilities required to facilitate the process including
but not limited to, the following items:
Define process to report any new data defect/issue.
Define mechanism to track issues and resolution.
Define process to identify data defects and exceptions during the ETL
process.
Define process to isolate defective records.
Define process to escalate defective records for resolution either in the
legacy source or in a separate defect resolution environment.
Define process to identify functionality impacted by data defects.
Define process to incorporate corrected records into the ETL process.]
9.CONVERSION IMPLEMENTATION
Page 59 of 60
DATA CONVERSION PLAN
Page 60 of 60
DATA CONVERSION PLAN
Cons:
- Extremely difficult to manage all the risks associated with intricate
relationships between business processes and the underlying data
associated with those business processes
- With parallel option
Risks and costs associated with keeping data current
in both systems
Dual-keying for system users
Requires more resources
Business needs must be the primary driver in determining the best-fit data
conversion implementation strategy for the project. Different business needs
require different implementation approaches and it pays to fully understand
each approach as well as its associated pros and cons so the right decisions
can be made and work can be planned at the outset of the project.]
[Describe the data conversion implementation approach that will be
used for this data conversion project and discuss the pros, cons,
and risks associated with the selected implementation approach
from the business perspective. Consider the following items when
developing the detailed conversion cutover plan for your project.
Depending on the selected implementation approach, some items
may be less applicable than others.
Timing and span of the conversion cutover window.
The need for a plan for freezing the legacy physical data structures.
Data retention requirements for legacy data file extracts and staging
databases.
Page 61 of 60
DATA CONVERSION PLAN
The following describes the activities shown in Figure 9-12 which must be
completed before the legacy data can be loaded to the target system:
1. Legacy System Closedown
Freeze all input - At this point in time, no data input should be
allowed into any of the legacy systems, from which source data will be
extracted, either by direct entry or through the various interfaces.
Complete all data processing - At this stage, verify that all
background data processing jobs such end-of-day financial
reconciliation or posting processes are complete.
Freeze the data - Once all background data processing jobs are
complete, legacy data will be frozen and no data changes will be
allowed until data conversion process is complete and the target
system is operational.
Page 62 of 60
DATA CONVERSION PLAN
Page 63 of 60
DATA CONVERSION PLAN
ensures that the entire data conversion process can be finished within
the timeframe allocated for data conversion cutover.
Conversion programs optimization This consists of keeping track
of all the details associated with each mock conversion, actively fine
tuning and optimizing data conversion programs, and making sure that
a data conversion run book is built, kept current, and the order of
execution for each conversion program is continuously monitored and
optimized.
Data categorization and prioritization special consideration
should be given to the following data categories with respect to
conversion cutover:
o Static data- data that will remain unaltered such as prior fiscal
year data.
o Archive data data that is no longer actively used which is
stored on a separate data storage device for long-term retention.
o Document images paper documents that were scanned and
converted to digital images.
o Dynamic data data that is actively being used, updated, or
newly generated.
o Open data transaction a business transaction that has not
completed its process cycle (e.g., a workflow item or a service
ticket that remains open with additional activities required prior
to being closed).
o Closed data transaction a business transaction that has
completed its business cycle and is subsequently used for
information purposes only, for example a service ticket with all
related activities completed and a ticket status of closed.
o Datasets that require manual conversion.
o Datasets that can be extracted, transformed, and loaded to the
target system ahead of time before the final cutover.
o Datasets that can be migrated incrementally.
O Datasets that can only be migrated at the time of cutover.]
Page 64 of 60
DATA CONVERSION PLAN
This section describes the approach that will be used for determining
whether data conversion meets the established acceptance criteria.
[Data certification is the process by which the state department verifies that
the converted data is of sufficient quality to enter data conversion cutover
and enable initial system implementation. In other words, data certification
is the data conversion readiness verification process.
The data stored within the current legacy systems is the lifeblood of the
state department business and therefore plays a significant role in meeting
business functionality in the new system. Without accurately converted
data, the new solution, regardless of its new look and feel and technology
uplift, will be of limited use to the department business and potential public
Page 65 of 60
DATA CONVERSION PLAN
Page 66 of 60
DATA CONVERSION PLAN
[Inevitably, after the data conversion cutover, data issues will be uncovered
and maybe greater than originally anticipated. Furthermore, there is a steep
learning curve and tremendous pressure to overcome in order for anyone to
become effective in addressing data issues especially during the post-
conversion period, as it requires knowledge and understanding of the source
data and data structure, the target data and data structure, and all the
transformation rules that were applied to the source data during conversion.
Therefore, the project/department ought to plan to retain the data
conversion teams, who have been intimately involved with data conversion,
to continue providing production support during post-conversion period. The
retention period will be determined by many factors, some of which may be:
Number of data errors, types of data errors, severity level, and priority
Growth rate of data errors vs. number of data errors resolved by the
team within a given period
Knowledge transfer and training]
Page 67 of 60
DATA CONVERSION PLAN
cutover:
These are data issues resulting from bugs in the data conversion
programming code discovered during various stages of testing and
validation.
New data issues discovered in the target system after cutover:
These are data issues which are unknown at the time of cutover, and are
discovered after the new system goes live.]
Page 68 of 60
DATA CONVERSION PLAN
Page 69
DATA CONVERSION PLAN
Page 70
DATA CONVERSION PLAN
Page 1
DATA CONVERSION PLAN
Page 1
DATA CONVERSION PLAN
Page 1