Best Practices in Data

Conversion
Best Practices in Data Conversion...............................................................................................................................
Activities for Data Conversion........................................................................................................................................
Conversion Strategy and Planning......................................................
Observed Best Practices in the Federal Sector...................................
Design and Technical Approach...........................................................
Conversion Programs.....................................................................
Mock Conversion............................................................................
Additional se o! Conversion Data.................................................
Elements to Convert.............................................................................................................................................................
Data Readiness......................................................................................................................................................................
"evel #..................................................................................................
"evel $..................................................................................................
"evel %..................................................................................................
"evel &..................................................................................................
Categories of Data Conversion......................................................................................................................................
Roles and Responsibilities.............................................................................................................................................
Conversion approach and associated complexity..........................................................................................
De'nitions o! comple(ity...................................................................
"o)*..............................................................................................
Medi+m*........................................................................................
,igh*.............................................................................................
Sample ASAP Conversion Deliverables...................................................................................................................
Table* Conversion Deliverables -DO . Data O)ner/ S0 . System
0ntegrator1.........................................................................................
20 Toolkit Page i
$&$3&%%#%.doc
4ersion #.5 6+ly $557
Best Practices in Data Conversion
This doc+ment highlights some o! the best practices in data
conversion in partic+lar as it relates to 28P data conversion in the
Federal Sector. 0t o+tlines the scope o! activities related to data
conversions/ common best practices +tili9ed in conversions/ types o!
data elements to be converted/ data conversion tasks/ and 'nally a
disc+ssion on data readiness.
Activities for Data Conversion
Conversion Strategy and Planning
Data conversion is a critical element associated )ith a s+ccess!+l
system implementation. The initial step in planning !or a s+ccess!+l
conversion is the development o! a conversion strategy to act as the
road map !or identi!ying the scope o! activities that need to be
addressed as part o! a s+ccess!+l conversion.
The strategy also serves as the high:level approach !or the design and
e(ec+tion o! the conversion process. 0t de'nes the scope/ sets
parameters o! the conversion/ and identi'es )hat and ho) m+ch data
)ill be converted. 0t does not cover speci'c conversion designs/
conversion b+ild plans/ conversion test plans/ or conversion
time!rames. 8ather/ it establishes the parameters )ithin )hich these
items are de'ned.
A!ter completing the strategy/ an overarching conversion plan sho+ld
be developed. This detailed doc+ment sho+ld be created and approved
by the !+ll conversion team comprised o! legacy system;b+siness
process e(perts/ target system;b+siness process e(perts/ and data
conversion e(perts.
There are several key elements to s+ccess!+l Conversion Strategies
and Conversion Plans and speci'c elements may reside in the
Conversion Strategy/ Conversion Plan or other pro<ect doc+ments
based on the methodology adapted by the program and the program=s
integrator. Beca+se o! these variations/ rather than de'ning speci'c
doc+ment re>+irements/ a single list o! areas that need to be
addressed as part o! a s+ccess!+l conversion are identi'ed belo)*
Issues and Risks associated )ith the data conversion
20 Toolkit Page # o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
Conversion Assumptions/ incl+ding all contract+al ass+mptions
regarding roles and responsibilities bet)een the government
and the integrator
Critical Milestones and dependencies/ incl+des the timeline and
check points in the process
Resource Plans/ incl+ding the timing and level o! e?ort re>+ired
by both internal and e(ternal reso+rces
Primary Points of Contact !or all key technical and !+nctional
e(perts/ partic+larly as they relate to legacy systems
Plan !or developing Memorandum of Agreements (MOAs1 )ith
all stakeholders involved in the design/ development/ testing and
e(ec+tion o! the conversion
Rollback planning/ in the event that prod+ction needs to shi!t
back to legacy system-s1 a!ter conversion has taken place and
the ne) system has gone operational.
The anticipated level and type o! Data Cleansing needed as part
o! the Conversion Plan.
The Scope o! the data conversion/ incl+ding the type o! data/
level o! detail/ and legacy systems
0! applicable/ the potential impact that the conversion strategy
)o+ld have on legacy system Decommissioning Plans -e.g.
placement o! historical data1
The Conversion Approac to be +sed !or each type o! data
!est Plans/ incl+ding clearly de'ned e(it criteria !or s+ccess!+l
test e(ec+tion
Observed Best Practices in the ederal Sector
@hile there is no best )ay to complete a data conversion/ the
!ollo)ing items are generally observed best practices that may to
varying degrees apply to Federal sector implementations*
A key element o! data readiness is to commence data cleansing
activities in )ell in advance o! conversion rather than as part o!
conversion
Conversion on 'scal year breaks
Convert all the AactiveB master data -c+stomers/ vendors/ items/
etc.1. Make s+re d+plicates have been eliminated as part o! the
data cleansing.
Conversion o! open items at the transaction level
Conversion o! closed b+siness and historical activity at the trial
balance level
Consider the implementation o! a data mart !or storing historical
transactions are stored in a de:normali9ed manner. This allo)s
20 Toolkit Page $ o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
!or easy access o! historical data and !acilitates the ability to
decommission legacy systems.
Cancel all o+tstanding open M:Cear Obligations/ Accr+als and
Acco+nts Payable activity prior to e(ec+ting conversion -this is a
key consideration !or e(ec+ting conversion at the 'scal year
break1
Minimi9e the amo+nt o! open transactions immediately prior to
conversion -e.g. !or systems that create ready to pay 'les/ a
!ree9e on all disb+rsement activity s+?iciently in advance o!
conversion so as to be able to con'rm that all payments )ere
s+ccess!+lly disb+rsed prior to conversion1.
Conversion aro+nd peak b+siness cycles -e.g. an ac>+isition
system that has increased b+siness activity d+e to !o+rth >+arter
reprogramming1
@rite:o? all aged debt )ith a lo) likelihood o! collection
8evie) and consider revising +p)ards Agency policy thresholds
!or tracking acco+ntable property and capitali9ation thresholds
8evie) dollar thresholds in legacy system !or tracking
acco+ntable and capitali9ed property and remove items !rom
conversion that !all belo) Agency policy thresholds
System So+rce* All transactions that are converted sho+ld be
identi'able )ith a transaction so+rce type o!
Aconversion;convertedB this r+le applies to inter!aced
transactions a!ter go:live as )ell.
4alidation . Man+al* A!ter e(traction !rom legacy system/
provide +ser !riendly screens and spreadsheets !or the b+siness
+sers to validate and correct data be!ore loading it into the
system.
4alidation . A+tomated* Since all transactions cannot be
man+ally validated plan to have controls in place to validate the
data in an a+tomated manner. 4alidation points are -#1 a!ter
e(tract !rom legacy/ -$1 a!ter trans!ormation into destination
!ormat and -%1 a!ter loading into ne) system. 8emember "egacy
does not e>+al 28P so make s+re yo+ acco+nt !or the data and
transaction controls appropriately.
Post go:live* There is a possibility that post go:live yo+ may need
to convert additional data that )as missed. Plan !or that and
keep the programs;screens developed pre go:live at hand
Closed Transactions* Plan !or the potential risk o! entering
d+plicates and making d+plicate payments on invoices or
shipping prod+cts t)ice or sending d+plicate invoice to
c+stomers. This can not be avoided completely b+t can be
red+ced. A large n+mber o! programs )o+ld make this a man+al
process )here the person entering certain in!ormation )o+ld
20 Toolkit Page % o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
need to man+ally log into the read only version o! legacy and
>+ery the transaction to make s+re an e(isting record does not
already e(ist. This iss+e is compo+nded i! there are m+ltiple
systems that need to be >+eried. By leveraging a data mart !or
conversion o! historical activity simple screens can be developed
to access the data man+ally or a simple database trigger can be
)ritten to go check !or d+plicates against the data mart !or key
elements.
Design and !echnical Approach
The design and technical approach o+tlines all tasks to be per!ormed
and the methodology !or their per!ormance.
An important part o! the design process is data mapping both at the
'eld and val+e level. This )ill +ncover missing data elements re>+ired
to s+pport the b+siness/ reveal data inconsistencies/ and identi!y
re>+ired translation r+les. Care!+l mapping also provides more
acc+rate in!ormation on the time and reso+rces re>+ired !or
developing conversion programs.
@hen mapping data elements/ it is necessary to determine )hich data
is*
To be trans!erred
To be translated ; converted
8ed+ndant
Missing
To be veri'ed ; balanced ; reconciled
Data gaps and iss+es )ill be doc+mented/ in accordance )ith the
pro<ect iss+es management process/ and resolved early in the process
to minimi9e the overall impact to the design o! the ne) system. Tools
and data dictionaries )ill be +tili9ed to complete the mapping process
e?iciently.
Data conversion design determines the a+tomated or man+al method
o! implementation and the overall design speci'cation. Depending
+pon the data acc+racy/ comple(ity/ n+mber o! records/ technology
+sed and time constraints/ data conversion can be a+tomated or
per!ormed man+ally. For a+tomated methods/ detailed speci'cations/
+nit test plans/ and reconciliation proced+res m+st be designed. For
man+al processes/ data entry proced+res m+st be developed.
20 Toolkit Page & o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
Conversion Programs
By +sing the designs/ technical approach/ and other program
speci'cations conversion programs are developed along )ith
reconciliation >+eries/ and a+tomated scripts -e.g./ batch scripts1.
2ach is +nit tested according to test plan approved earlier in the
process.
Mock Conversion
The mock conversions serve as Adry r+nsB o! the entire data
conversion process and provide the opport+nity to record timing
statistics. This tests the programs and allo)s !or 'ne t+ning that )ill
e(pedite the conversion itsel!.
Once the mock conversion tests have been e(ec+ted/ the res+lts are
analy9ed and doc+mented to note any per!ormance iss+es/ timing and
dependency constraints/ and changes re>+ired to the conversion
proced+res and programs. O+tp+t !rom this task is recommendation
!or the c+t over Plan/ )hich also incl+des timing o! the conversion
e(ec+tion. The time re>+ired !or the !+ll conversion o! data !rom
so+rce to target systems is an important consideration in the
implementation stage o! the li!ecycle/ since it )ill be necessary to
have acc+rate sched+ling in!ormation available )hen the system is
bro+ght live.
Additional Use of Conversion Data
D+ring the mock r+ns the conversion so!t)are )ill be e(ec+ted to
convert legacy tables into a test environment to s+pport the testing
according to the sched+le re>+irements de'ned in the pro<ect plan.
This activity involves the loading and reconciling o! converted data
and is comprised o! the iterative process o! e(ec+ting the test/
correcting any deviations/ and re:testing as needed. "essons learned
!rom the per!ormance test data conversion )ill be incorporated into
the 'nal conversion plan.
Elements to Convert
Data conversion involves identi!ying )hat data needs to be converted/
identi!ying ho) m+ch data to convert/ determining the best method to
convert the data/ and veri!ying that the data )as converted acc+rately
and completely. The data conversion e?ort )ill consist o! speci'c
stages )ith e(it and entry criteria.
20 Toolkit Page D o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
There are a !e) conversion options available* man+al entry/
a+tomated entry/ or no entry. 0t is important to note that the
conversion approach is chosen on a table:by:table basis/ the decision
+s+ally driven by the vol+me o! data stored in the table. 0n addition to
sheer vol+me playing a role in the +ltimate decision/ the comple(ity o!
de'ning 'eld val+es speci'c to ne) system may become the deciding
!actor. 0n some cases/ COTS tables call !or data that cannot be
e(tracted or derived !rom a legacy system. 8ather than develop
comple( programs to handle these individ+al cases/ it is more e?icient
to designate the tables as man+al entry.
For those tables that are to be converted +sing the a+tomated
approach/ programs sho+ld be )ritten to e(tract and !ormat the data
so that it is compliant to standards. These conversion programs
sho+ld !ollo) the same SD"C as the base so!t)are. 0t is also important
to test the programs thoro+ghly as one )o+ld the so!t)are itsel!.
The )rong strategy*
Convert nothing . start !resh
Convert everything . get all the data !rom the legacy system so
that it is readily available -remember "2EACC does not e>+al to
28P1
The right ans)er is in the middle and it tr+ly depends on the
organi9ation/ level o! BP8 being done/ scope o! the pro<ect/ vol+me o!
legacy data/ daily transaction vol+mes/ n+mber o! +sers/ and b+siness
criticality o! the application/ organi9ational mat+rity and 'nally
n+mber o! legacy systems being migrated;s+bs+med.
Data Readiness
Data cleansing activities sho+ld commence )ell in advance o!
conversion activities/ pre!erably in advance o! the act+al solicitation
process !or the system integrator. The !oc+s o! the data cleansing
e?ort is to achieve a high level o! data readiness. n!ort+nately/ the
typical approach to data cleansing is to signi'cantly +nder:estimate
the level o! data cleansing re>+ired !or a s+ccess!+l conversion e?ort.
This entails a high level o! b+siness risk and s+bse>+ently cost in
error correction/ d+plication and contin+ed cleansing.
The diagram belo) provides an overvie) o! the !o+r levels o! data
readiness.
20 Toolkit Page 3 o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
"evel #
The 'rst level o! data readiness/ )hich is o!ten re!erred to as "good
enoug to #o$%ive&/ is the point )here a company accepts an error
rate simply to get the system +p and r+nning rather than risk !+rther
delays/ !re>+ently beca+se the pro<ect has already e(tended !ar
beyond the estimated dead:line or may !ace the dreaded costly delay
postponing go:live. Most implementations !ace this critical point
regarding data/ and the b+siness rami'cations o! that AacceptableB
level o! error are o!ten +nkno)n !or some time. The problem is mainly
that this process is common practice and most companies are never
presented )ith alternatives other than accepting the Aapparent stat+s
>+oB o! data chaos.
"evel $
8eali9ing that the bar can be raised beca+se there is no reason to
settle )ith an AacceptableB error rate and that data m+st be error !ree
is the 'rst step in moving to)ards the second level o! data readiness.
At this level/ all data that is loaded into COTS is acc+rate. One might
20 Toolkit Page 7 o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
)onder )hy error !ree is not the standard/ b+t the reality is that many
managers are !orced to compromise their e(pectations thro+gh a
pro<ect=s li!espan beca+se o! a Fa)ed or absent data migration
methodology that leaves them s)inging in the )ind as con'g+ration
and other problems dominate the planning !oc+s o! the
implementation team.
"evel %
To most people it may seem that error !ree is the highest level o! data
readiness . )hat else is there to gainG @ell/ at this level yo+ are only
ass+red that the data that has been loaded is error !ree. Hot that all
b+siness critical data has been loaded. So to make s+re that no data is
omitted it is necessary to climb one more step to become b+siness
ready. This means that the data as b+siness ob<ects is tracked thro+gh
normal b+siness proced+res ass+ring that all necessary data is
available and loaded error:!ree and )ill have 9ero negative impact on
the daily b+siness o! the 'rm )hen e(ec+ted on go:live.
"evel &
Thro+gho+t all levels o! data readiness/ data sho+ld be validated and
traceable b+t !or partic+lar ind+stries needing to adhere to legal
restrictions/ this 'nal step o! validation is a legal or moral necessity.
As an e(ample/ a company dealing )ith li!e sciences not only needs to
validate and trace the changes b+t an a+thentication o! these changes
m+st be recorded as )ell/ so that responsibility can be determined as
necessary to meet !ederal reg+lations.
Categories of Data Conversion
The table belo) provides an initial list o! categories o! b+siness data
that sho+ld be converted to an 28P. The 'nal list )ill depend +pon the
so+rce systems and the scope o! the pro<ect. Partic+lar emphasis
sho+ld be placed on data cleansing activities )here data has a ,igh
COTI Comple(ity and a high vol+me.
No. Category Conversion
Item/Type
Attributes COTS
Complexity
20 Toolkit Page J o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
#.# Set+p Data
-Master Data1
S+ppliers
-4endors1
Active and inactive
vendors that are
associated to any
doc+ment that )ill be
converted
"o)
#.$ C+stomers Active and inactive
c+stomers that are
associated to any
doc+ment that )ill be
converted
"o)
#.% 2mployees Active employees "o)
#.& 0nventory;Service
"ogistics 0tems
Active or re!erenced
items
"o)
$.# B+dgets Appropriation Data All open/ e(pired/ and
non:cancelled
appropriations
Medi+m
$.$ B+dgets -F+nds
Control "imits1
All open b+dgets ,igh
%.# 0ntra De!ense
Organi9ation
Orders
n:!+l'lled
c+stomer orders
All +n!+l'lled
c+stomer orders
Medi+m
&.# Eeneral
"edger
Acco+nt Balances All open E"s ,igh
D.# Cost and
Payment
Management
Commitments All open commitments Medi+m
D.$ Obligations All open obligations Medi+m
D.% 0nvoices;2ntitleme
nts
All invoices that are
+npaid -!+lly or
partially1
Medi+m
3.# Proc+rement Contracts All open contracts Medi+m
20 Toolkit Page K o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
3.$ 8eceipts All partial and !+ll
receipts
Medi+m
7.# Billing and
Acco+nts
8eceivable
8eceivables All open receivables Medi+m
7.$ Bills All bills that have not
been collected -!+lly or
partially1
Medi+m
J.# Asset
Management
Assets All records associated
)ith assets s+ch as
C0P/ PPL2/ and
military e>+ipment
Medi+m
K.# Cost
Acco+nting
Costs Costs !or labor/ travel/
and other
miscellaneo+s items
that are costed
,igh
K.$ Pro<ect Tasks L
Task elements
All open pro<ects and
task elements -either
open or closed1 related
to these open pro<ects.
,igh
Roles and Responsibilities
Both the Eovernment and the System 0ntegrator-s1 have a role in data
conversion. The Eovernment is primarily responsible !or
+nderstanding the b+siness process and the data elements associated
)ith them. They )ill also have responsibility !or the legacy system
environment.
This table provides an ill+strative overvie) o! the types o! tasks L
responsibilities o! the entities that are involved in a data conversion
e?ort.
!able' Conversion Roles ( Responsibilities )DO * Data O+ner, S- * System -ntegrator.
No. Task/Activity Primary Responsibility
#. Con'rm legacy so+rce systems -systems o!
record1 and inventory o! data to be converted
incl+ding appro(imate data vol+mes
DO
$. Develop Baseline Detailed Conversion Plan S0
%. Assess data >+ality S0
&. 8ecommendations and options !or data cleansing S0
D. Data cleansing DO
3. 8ecommendation on conversion method S0
20 Toolkit Page #5 o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
No. Task/Activity Primary Responsibility
-a+tomated vs. man+al1
7. Develop detailed B+siness 8econciliation Plan S0
J. Test and sim+late B+siness 8econciliation Plan S0
K. 2(ec+te B+siness 8econciliation Plan -post:
conversion1
DO
#5. Develop legacy data e(tract strategy/ approach/
logic and !ormat
S0
##. Develop legacy data e(tract programs and scripts DO
#$. 2(ec+te legacy data e(tracts DO
#%. Make recommendations on conversion method S0
#&. Design data mapping !rom legacy e(tracts to
COTS
S0
#D. Prepare and commission Conversion 0nstance S0
#3. Design/ develop/ and test conversion programs
incl+ding a+tomated conversion tools
S0
#7. Develop detailed conversion test plans S0
#J. System testing o! converted data DO
#K. Cond+ct man+al conversions DO
$5. Develop Conversion Fallback Plan DO
$#. Test and sim+late Conversion Fallback Plan S0
$$. Make recommendations on conversion @aves !or
conversions spanning m+ltiple 'scal years
S0
$%. Make decisions on recommendations on
conversion increments !or conversions spanning
m+ltiple 'scal years
PM
Conversion approach and associated complexity
The Eovernment )ill have primary responsibility !or per!orming the
tasks associated )ith the "egacy Comple(ity Stage -sho)n to the le!t
o! the dotted line1 and the System 0ntegrator-s1 )ill have primary
responsibility !or per!orming the tasks associated )ith the COTS
Comple(ity Stage -sho)n to the right o! the dotted line1.
20 Toolkit Page ## o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
Definitions of complexity
"egacy comple(ity is de'ned as the comple(ity inherent in data
cleansing/ cross )alking legacy data elements bet)een tr+e so+rce
system-s1 and other systems o! re!erence -i.e. !eeder systems1/ and
designing and developing programs to e(tract data !rom the legacy
and !eeder systems. The data that is e(tracted at this stage )ill !eed
the MData Staging= system in the !ollo)ing stage.
Assessment o! legacy comple(ity is Mhigh= !or the !ollo)ing reasons*
There are m+ltiple so+rce systems !or data in the legacy
environment
The COTS package )ill re>+ire additional data attrib+tes that
are not readily available in the legacy environment. For e(ample/
in!ormation that )ill be re>+ired !or SF0S may be missing/ and
The c+rrent M>+ality= o! legacy data may not meet a+dit
standards
The Systems 0ntegrator-s1 )ill be responsible !or the COTS
Comple(ity Stage. COTS comple(ity has t)o main activities/ data
staging and COTS conversion. D+ring data staging/ the Systems
0ntegrator-s1 )ill design and develop the data staging system. "egacy
data +sing e(tract programs )ill be imported into the data staging
system/ data +pdates incl+ding assigning a mapping to SF0S elements
20 Toolkit Page #$ o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
Prime is
Government
Prime is Systems Integrator
Total Complexity
Legacy
System
Legacy
System !
Legacy
System "
#xtract
Programs
#xtract
Programs
#xtract
Programs
$ata Staging
$ata %rom
Legacy
$ata &p'ate
( )an*al
$ata &p'ate
( Script
#xtract
Reconciliation
API
Rea'iness
C+TS Package
General
Le'ger
Acco*nts
Receivables
Acco*nts
Payables
,ixe' Assets
Legacy Complexity C+TS Complexity
Legacy
Systems
C+TS
Conversion
Programs
,ee'er
Systems
,ee'er
,ee'er !
,ee'er "
,ee'er -
)ill be per!ormed by script or man+ally/ reconciliations o! the e(tracts
)ill be per!ormed and the !+nctional S+b<ect Matter 2(perts )ill help
per!orm and con'rm the mapping d+ring the AP0 8eadiness process.
A!ter the data staging activity/ the Systems 0ntegrator-s1 )ill per!orm
the COTS conversion. For COTS conversion/ COTS conversion
programs )ill be designed and developed that )ill import data !rom
the data staging system into the COTS package. The COTS conversion
programs )ill ens+re that the necessary data 'lls the re>+ired data
tables in each o! the COTS areas -i.e. Eeneral "edger/ Acco+nts
8eceivables/ Acco+nts Payables/ Fi(ed Assets/ etc.1.
The matri( given belo) provides an initial assessment o! the COTS
comple(ity o! conversions proposed !or the listed data categories.
COTS comple(ity is rated on a scale o! ,igh/ Medi+m/ and "o).
De'nitions o! COTS comple(ity rating are as given belo)*
Low:
Data is being e(tracted !rom one so+rce system -a system or set
o! systems )ith identical con'g+rations1
Ho historical data is being converted
2?ort to design/ develop/ and +nit test conversion
programs;scripts is in the range o! #$5 . #KK person ho+rs
Standard o?:the shel! conversion tool-s1 )ith basic tool set+ps
can be +sed to per!orm conversion
Programs;scripts that re>+ire #5 . &5 person ho+rs o!
development e?ort to cond+ct e(tract and conversion
reconciliations
Medium:
Data is being e(tracted !rom # . % so+rce systems -a system or
set o! systems )ith identical con'g+rations1
Some -# . #J months1 historical data is being converted
2?ort to design/ develop/ and +nit test conversion
programs;scripts is in the range o! #KK . %D5 person ho+rs
Standard o?:the shel! conversion tool-s1 re>+iring advanced
set+ps and other +pdates;modi'cations to the tool to per!orm
conversions
Programs;scripts that re>+ire &# . J5 person ho+rs o!
development e?ort to cond+ct e(tract and conversion
reconciliations
20 Toolkit Page #% o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
High:
Data is being e(tracted !rom more than % so+rce systems -a
system or set o! systems )ith identical con'g+rations1
Signi'cant -more than #J months1 historical data is being
converted
2?ort to design/ develop/ and +nit test conversion
programs;scripts is greater than %D5 person ho+rs
Standard o?:the shel! conversion tool-s1 re>+iring advanced
set+ps and other +pdates;modi'cations to the tool to per!orm
conversions
Programs;scripts that re>+ire J# . #$5 person ho+rs o!
development e?ort to cond+ct e(tract and conversion
reconciliations
Sample ASAP Conversion Deliverables
This section provides a sample list o! Deliverables based on SAP=s
ASAP implementation methodology. This is not meant as an
a+thoritative list given that there can be signi'cant variations the
n+mber and types o! deliverables based on the nat+re o! the
conversion and the methodology being +sed. 8ather/ this list is
provided !or ill+strative p+rposes to provide insight into the types o!
deliverables that may be created.
Table: Conversion Deliverables (DO Data Owner, SI System Integrator)
No. $eliverable Name Primary Responsibility
#. 0nventory o! data to be converted/ incl+ding
appro(imate data vol+mes
DO
$. Conversion approach and plan/ incl+ding
recommendations on conversion method/ data
e(tract strategy/ conversion reso+rces/ and
timelines.
S0
%. Data >+ality assessment report incl+ding
cleansing assessment/ approach/ and tools.
S0
&. Conversion b+siness reconciliation plan S0
D. Conversion b+siness reconciliation and a+dit
reports
S0
3. Conversion design doc+ments incl+ding detailed
data mapping
S0
7. A+tomated conversion scripts and a+tomated tool S0
J. Conversion test plans S0
K. Conversion instance strategy and plan S0
#5. Conversion test res+lts L reports S0
##. Conversion iss+es/ recommendations/ and
resol+tions
S0
20 Toolkit Page #& o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557
No. $eliverable Name Primary Responsibility
#$. Fallback Contingency Plan S0
#%. Conversion test res+lts and reports !rom
conversion contingency plan
S0
#&. COTS instance )ith converted data that s+pports
Organi9ation Operations
S0
20 Toolkit Page #D o! ##
$&$3&%%#%.doc
4ersion #.5 6+ly $557