Professional Documents
Culture Documents
PAGE 1
DATA MIGRATION
METHODOLOGY
FOR SAP
Y !HRISTIAN ERGERON " cvcby@yahoo.com
If one can manage small decisions now, the
large ones will gradually disappear or might
never appear in the first place.
Anonymous
Data Migration Methodology for SAP
PAGE #
AO$T THIS DO!$MENT
Thi% do&'(ent i% free) Yo' &an '%e it and di%tri*'te it freely+ a% long a% yo' do not
&hange any of it% &ontent or %ell it)
Goal of thi% do&'(ent
This document provides you with a procedure to assist you organizing and performing the data transfer from the legacy
system.
It describes a methodology for data migration I used successfully in different implementations. It is base upon my previous
eperiences. There is no warranty on its content or on the results. This guide gives you suggestions. It is up to you to ta!e
the hints and ma!e up your own methodology.
All the templates are derived from models I used in specific implementations and may come from older version of "A# $%.
It most probably will not be &''( accurate or ade)uate for your use. There may be omissions and the templates can be for
different "A# versions. It is a base to help you build your own template. *ou can start from them, but do not ta!e for
granted that everything is there.
,ho( i% thi% g'ide for -
& "ection & is for every one involves in the data conversion process.
+ "ection + is for the pro,ect manager and the data conversion manager
% "ection % is for the data conversion manager and the members of your team responsible of converting -usiness
.b,ects, both technical and functional.
Data Migration Methodology for SAP
PAGE .
Ter(inology and A**re/iation%0
/ote0 The terms "A# and $1% are both use interchangeably to refer to "A# $1% system.
ig Fi/e 0 2hen referring to the -ig 3ive, it means 4aterial 4aster, 5ustomer 4aster, 6endor 4aster, -ill .f
4aterials 7-.48 and $outings.
'%ine%% O*1e&t% 0 To help in the analysis and transfer process, the data are not treated as tables or field contents
but rather as ob,ects in term of business operational. These are called -usiness .b,ects.
'%ine%% O*1e&t D! re%2on%i*le 0 $esponsible of the conversion process 79egacy data source and integrity,
mapping, conversion rules, etc.8 and for the respect of the planned schedule for his -usiness .b,ect.
'%ine%% O*1e&t O3ner 0 The one that owns the information in the every day business. This is the person that will
ma!e the strategic choices on functional re)uirements for the business ob,ect and that will do the final validation
of the converted data. 5an be identified by finding The highest hierarchical person who will be directly and
mostly affected if the business ob,ect does not wor!
Data !on/er%ion 4 Data Migration 0 The data conversion process. :ata conversion and :ata 4igration
terms are used interchangeably in the document.
D! 0 Abbreviation for the data conversion process.
Do(ain0 3unctional domain within the pro,ect, li!e 3inance, "ales, #roduction, etc.
Flat File 0 A file format used to import data into "A#. The flat file is a plain tet file with a tab separator between
fields. It can be easily generated from ;cel or Access.
Inter(ediate file 0 An ;cel, Access or other type of file, which is manually manipulated in a process between
the 9" etraction and the flat file generation.
LS 0 Abbreviation for 9egacy "ystem
LSM or LSM, 0 9egacy "ystem 4igration 2or!bench. It is a "A# tool for conversion that permits data loading
using flat files etracted from the 9egacy "ystem.
Tran%&odifi&ation Ta*le+ !ro%% referen&e ta*le or 5"Ref ta*le 0 A table that shows the relation between fields
when one value is related to a parent field. 3or eample, the <"ales .rganization< will be set accordingly to the
material type.
,S 0 2or! -rea!down "tructure.
Data Migration Methodology for SAP
PAGE 6
TALE OF !ONTENTS
SE!TION 1 " INTROD$!TION TO DATA !ON7ERSION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))8
&.& I/T$.:=5TI./...........................................................................................................................................>
.verview..................................................................................................................................................>
-ases from which this methodology was made.......................................................................................>
#hilosophy 6" techni)ues........................................................................................................................?
A few facts...............................................................................................................................................?
5onversion rules and business ob,ect ownership.....................................................................................?
4ain steps of the conversion methodology.............................................................................................@
2here you will, for sure, have a timing problem....................................................................................@
There is no such thing as a free lunch....................................................................................................&'
The computer will have the last word....................................................................................................&'
&.+ :ATA 5./6;$"I./ A=I:;9I/;"..........................................................................................................&&
Thin! "A#..............................................................................................................................................&&
#repare the 9egacy :atabase.................................................................................................................&&
-efore the last test run, ta!e into account the customizations of your new system...............................&&
$educe the amount of historical data to be transferred..........................................................................&&
=se controls edition in "A#...................................................................................................................&&
"mall is beautiful....................................................................................................................................&&
-e wise...................................................................................................................................................&&
#lay it safe..............................................................................................................................................&&
&.% "=AA;"T;: A::ITI./A9 $;A:I/A".................................................................................................&+
SE!TION # " ORGANI9E THE DATA !ON7ERSION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))1.
+.& .6;$6I;2..................................................................................................................................................&B
+.+ :ATA 5./6;$"I./ #9A/.......................................................................................................................&B
-usiness .b,ects....................................................................................................................................&B
:ata type................................................................................................................................................&B
Information to complete in the conversion plan....................................................................................&C
4ain -usiness .b,ects se)uence of conversion....................................................................................&>
+.% 2-" 7 2.$D -$;AD:.2/ "T$=5T=$;8.......................................................................................................&?
2hy a 2-" E.........................................................................................................................................&?
Fow to....................................................................................................................................................&?
"uggested 2-" content for data conversion.........................................................................................&@
Are you sure E........................................................................................................................................&@
$e)uest to reGevaluate your 2-"..........................................................................................................&@
"ome pointers to figure out numbers.....................................................................................................+'
-allpar! figures......................................................................................................................................+&
A formula to help H. Fandle with care.................................................................................................+&
+.I 5A9;/:A$ #9A//I/A............................................................................................................................+%
.verview................................................................................................................................................+%
4"G#ro,ect or not...................................................................................................................................+I
"e)uencing the tas!s..............................................................................................................................+I
Dey users and consultant availability to wor! on 4aster :ata..............................................................+I
;nd Jat bestJ 6" Jmost probableJ.............................................................................................................+I
Data Migration Methodology for SAP
PAGE :
Are you sure E........................................................................................................................................+I
2or!load analysis..................................................................................................................................+B
SE!TION . " !ON7ERTING A $SINESS O;E!T)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))#8
%.& .6;$6I;2..................................................................................................................................................+?
-efore you begin....................................................................................................................................+?
:ocumentation of your wor! 7conversion spec. and mapping sheet8....................................................+?
%.+ :ATA #=$AI/A A/: 59;A/"I/A.........................................................................................................+?
%.% 4A##I/A A/: 5./6;$"I./ $=9;"....................................................................................................+?
About the rules.......................................................................................................................................+@
A special case for 4aterial 4aster.........................................................................................................%'
All other business ob,ects......................................................................................................................%I
:irectory organization...........................................................................................................................%>
6ersion management of conversion rules..............................................................................................%>
4urphyJs protection 0 "ave it often H and get good bac!ups...............................................................%?
%.I ;KT$A5T A/: 9.A: #$.A$A4"...................................................................................................................%?
%.B :ATA A/: $=9;" A:A#TATI./......................................................................................................................%@
%.C 9.A: =/IT T;"TI/A......................................................................................................................................I'
%.> ;KT$A5T L 9.A: M 3=99 "IN; T;"TI/A A/: :ATA 6A9I:ATI./...............................................................I'
%.? A55;#TA/5; "*"T;4 3=99 9.A:................................................................................................................I'
%.@ #$; #$.:=5TI./ A/: #$.:=5TI./ 9.A:...................................................................................................I&
%.&' "=AA;"TI./" ./ TF; :ATA 5./6;$"I./ 9A/:"5A#;................................................................................I&
!ON!L$SION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6#
APPENDI5 < 7ARIO$S TEMPLATES))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6.
A G 5onversion plan template.................................................................................................................II
- G 2-" template..................................................................................................................................II
5 M 4aterial 4aster G 3ields selection sheet..........................................................................................II
: G :ata conversion specification G Aeneric template...........................................................................II
; G :ata conversion specification M -.4 L $outing Template "amples.............................................II
3 G 4aterials 5lasses and 5haracteristics structure...............................................................................II
Data Migration Methodology for SAP
PAGE 8
SECTION 1 - INTRODUCTION TO DATA CONVERSION
Data Migration Methodology for SAP
PAGE =
1.1 INTRODUCTION
O/er/ie3
Implementing "A# is an important challenge, both in terms of resources 7people, money, time8 and in business process. A
lot is at sta!e and, for most of you, failure is not an option you can afford. To put all odds on your side, you need a good
methodology. .ne that will provide you with a realistic planning, a solid organization, a way to manage the process and
control tools to detect and correct slippage before it becomes a problem.
An important part of this challenge will be the data conversion. #revious implementations of "A# have shown that data
migration can amount up to about I'( of the entire pro,ect. #oor data conversion will ma!e your Ao 9ive very difficult,
if not impossible.
This guide is aimed at helping you organize the data conversion process, which in turn, will lead to a successful
implantation.
a%e% fro( 3hi&h thi% (ethodology 3a% (ade
2hen I was originally as!ed to come up with a method to convert data, I started by analyzing passed eperiences. There I
found the following recurring problems 0
2hile the pro,ect is going on0
There are many things being wor!ed on at the same time. *et, most of them are not progressing.
There are documents all over the place and, somehow, they always seem to be outdated.
:ata loaded is regularly incomplete and inconsistent.
3unctional changes are not impacted on the converted data.
:ata previously loaded with success is suddenly re,ected by "A#.
There is a lot of misunderstanding, friction and frustration between the functional and technical team.
At Ao 9ive
4aster data deadlines where constantly busted and production load is done in JJrush modeJ at the last
minute.
"ome !ey parts of the data cannot be loaded in production. #atches are applied to the master data in order
to forceGload.
"ome data ,ust will not get in at all, they will have to be entered after A. 9ive.
After Ao 9ive
"ome :ata need to be corrected L entered after Ao 9ive. -ecause the production system is now living,
data are moving targets. This ma!es the process difficult and time consuming H. This translates into a
costly operation.
After discussing with people who lived these situation 7manager, functional and technical8, we identified the following
points 0
#lanning and resources load estimates where way out 7when they eisted8.
4ost of the problems encountered are actually functional issues.
Information does not travel well between functional and technical team. As we get near the Ao 9ive, this
becomes much worst.
Data Migration Methodology for SAP
PAGE >
This methodology was made to solve these issues.
Philo%o2hy 7S te&hni?'e%
The approach I ta!e to the data conversion is as much a state of mind as a techni)ue. -oth aspect of it must be applied for
results to show up. This is actually true of any concept. 4ost of concept failures are due to application of the techni)ue
while neglecting the philosophical aspect of it.
The mindset re)uired in our case is that we must do things right from the start and solve issues as they occur. Ta!e the time
that it re)uires to do thing properly and thoroughly. /o epediting, no bypassing of step, no piling of unsolved issue to !eep
going.
$esults will initially be slower to come. Fowever, because you will get things right on the fist time, you will eventually
pic!Gup an impressive speed. As in car racing, it is not the speed at which you enter a turn that is most important, it is the
one at which you get out of it.
A fe3 fa&t%
The data conversion is not some technical stuff to give to the programmers and wait until it comes bac!. 4ost, if not all, of
the issues and problems you will encounter in the conversion process will be functional. Although the etract 1 load process
itself will not be effortless, it is the part between the etract and the load that is the most difficult. Aetting the right data at
the right place with the values re)uired for your business process is always a functional problem.
"A# is a processGoriented system and master data is an integral part of this process. /ice, but what does it meansE The
answer is that everything is tied together. 4aster data is dependent of the customizing, the customizing is made accordingly
to the way you do your process, and master data is needed to run your process. If you change master data, it will most
probably change the behavior of the process. If you change customizing, your master data may become incomplete or
incorrect.
2hichever phases you are in the pro,ect, data conversion always seem to be the one step that can be pushed a little bit
forward in time when you run behind in the overall schedule. :oing this will put the conversion process too close to the end
of the pro,ect. In that situation, you will end up shoveling a ton of data into "A# at full speed with little control, if any, on
data )uality and coherence. $emember the old saying <garbage in, garbage out<.
There is no Jeasy does itJ way to do the data conversion and it ta!es time. :ata conversion is made with lot of brain stuff
mied with hard wor! and some programming. /o technological gadget or guru will ma!e this otherwise.
!on/er%ion r'le% and *'%ine%% o*1e&t o3ner%hi2
.!, we now !now :5 is a functional thing, data must not be shoveledGin and it will ta!e lot of wor! and time. Fow do we
manage his E
To solve this, I ma!e the :5 process part of the functional process, both in term of timing and deliverable. Dey users must
do a thorough analysis of the master data and lin! their usage to the process as they are customizing. They must understand
which data does what, which are needed, how it relates to the customizing L process flow and figure out where it will come
from. This !nowledge will get things to fit progressively one into the other li!e a set of bloc!s.
3or !ey user to get this !nowledge, I give them the responsibility and ownership of the 4apping and conversion rules. It is
OtheirP master data and they will do mapping L rules documents. At first, this process will not simplify the technological
aspect of the conversion, nor will it ma!e it shorter or easier H say whatQ As I already mentioned speed will come,
eventually. The goal of the mapping and rules writing is to get !ey users to sweat it out and understand "A# way of doing
things. This will also help the !nowledge transfer between consultants and !ey users. 2hen they are done with this, their
brain will play that master data G business process G customizing G game without even thin!ing about it.
The mapping document and conversion rules will become the common ground for discussions between the different
domains. 5ross reading of :5 specs is essential as, for eample some action ta!en by ## may affect ": and 3I. :o not
underestimate this, a small change in ## can bloc! all epeditions. I saw this !ind of issues in all the pro,ects I wor!ed on.
It will also be the only common language document between the functional team and the technical team.
Data Migration Methodology for SAP
PAGE @
The mapping document and conversion rules will become the technical staff road map. If it is not in the rules, it does not
eist. "o any discussion, decision or answer must be documented in the rules. *ou will be surprised to see how things
change between verbal decision, sometime made in the hallway between meetings, and written decision which re)uired
thin!ing about it and assuming responsibility for it.
Again, ta!e the time that it gets to have clear and unambiguous :5 rules. 2hen the spec has no ambiguity and has been
cross read and validated by all domains and the technical team, and only then, can you start the development of the etract
and load programs. That will be the point where will start pic!ing up speed, lots of it.
Main %te2% of the &on/er%ion (ethodology
-efore you even start to wor! on specs, you must first get organized. Aetting a good planning and organization structure
ta!e about two wee!s for the first draft, which will leave you with some )uestions on pro,ect organization. Aetting a
complete and final planning will ta!e at least one more wee!. Any unsolved issues on these will haunt you throughout the
pro,ect, so finish this completely before stating any other step.
The data conversion re)uires functional and technical resources from most departments. These same resources will most
probably be involved in other part of the pro,ect. 3or this reason, the ris! of conflicting tas! is high and can )uic!ly lead to
a bottlenec! where !ey peoples are overloaded. 3or this reason, you should consider the data conversion as a pro,ect within
the pro,ect. This translates into the preparation of a complete conversion plan that will help you go through the process and
will permit to foresee and solve the conflicting resources usage before the bottlenec! ever occurs.
The methodology is based on a top down process. Aoing through this will permit to plan, organize, eecute and followGup
your conversion. As the pro,ect is going, you will control the evolution of the data conversion process. ;ach step has its
own use. *ou may sometime feel li!e you are not going to the end by the shortest route. $emember, the goal is not to get
first results faster, it is to finish the OwholeP process faster. This method is based on many pro,ects eperience and will help
you to avoid the pitfall usually associated with data conversion.
The main steps of the data conversion are0
.rganization of the data conversion 7#ro,ect manager L data conversion coordinator8
:ata conversion plan
The 2-" with wor!load estimates
The calendar planning with resources loading
Aoing on with the -usiness .b,ects data conversion 7The resource responsible of the -usiness .b,ect :58
:ata #urging and 5leansing
4apping and conversion rules
;tract and 9oad #rograms from rules
:ata and $ules Adaptation 7ad,usting rules and programs following testing8
9oad =nit Testing 7unitary testing G small volume of manual data8
;tract and 9oad 3ull size testing 7data test and validation G large volume with real etracted data8
3ull data loading into A55;#TA/5; "*"T;4
3ull data loading into #$; #$.:=5TI./ "*"T;4
6alidation of converted data and Dey =ser R -usiness .b,ects .wner "ignoff
3ull conversion into #$.:=5TI./ "*"T;4 and final "ignoff
,here yo' 3ill+ for %'re+ ha/e a ti(ing 2ro*le(
The business process analysis is done by the !ey users, business issues are dealt with by !ey users, tests are done by !ey
users, functional issues are solved by !ey users, training is prepared by !ey users, data conversion rules are done by !ey
users, data validation is done by !ey user, master data issues are solved by !ey users H. In addition, when you start
validating master data, it is usually that time where !ey users are out giving training.
If you try to identify where there will most probably be a bottlenec!, do not loo! any further. The intersection of 4aster
:ata validation, integration testing and training will be JitJ. *ou will need a very realistic wor!load estimate and resources
wor!load planning to avoid !ey users being schedule I? hours of wor! per day.
Data Migration Methodology for SAP
PAGE 1A
There are not many solutions to this. Assuming your team is sized correctly, doubling the resources will double the cost,
double problems but probably not double the output. Therefore, we are bac! to the basic rule, this !ind of pro,ect ta!es time
and the best way to minimize it is to plan for it correctly. *ou will have no other choice than spreading the load throughout
the entire pro,ect.
5omplaisance planning will ,ust ma!e a long pro,ect longer, sometimes much longer and always a lot more epensive.
Trying to go too fast with insufficient resources is usually the basic recipe of most horror story you hear about "A#
implementations.
There i% no %'&h thing a% a free l'n&h
This is a simple system, but simple does not mean easy. :oing things right the first time is an investment and li!e any
investment it has a cost 7money, people, time8 to be paid before you gets profits. /o free lunch here.
*ou will need discipline, lots of it. :o no pile up delay or issue. -etter to slow down, cut your loss and figure out how to
resolve problems than trying to !eep going the wrong way.
*ou must give &''( at all steps to achieve the point where the result will be bigger than the sum of your efforts.
;pediting, bypassing or neglecting a tas! will have a negative effect further down the road, which will eventually create
important delays.
There is no Oeasy does itP way to do data conversion, there are ,ust some path easier than others.
The &o(2'ter 3ill ha/e the la%t 3ord
5omputer does not do politic and cannot be <convinced< of anything. If the final data set is not accurate and well structure,
your computer will bring you bac! to reality the hard way.
Data Migration Methodology for SAP
PAGE 11
1.2 DATA CONVERSION GUIDELINES
ThinB SAP
3orget your actual system and understand "A#. 3irst and foremost, get familiar with the "A# business process you will be
implementing. Then, according to the "A# process needs, establish what the 4aster :ata re)uirements are. Then, and only
then, see what can be salvage from your legacy system.
Thin! "A#, do not try to fit in your old system into it.
Pre2are the Lega&y Data*a%e
5lean the data on your legacy system. It is easier to start from a sound legacy system than trying to fi inconsistencies
during the conversion. :elete obsolete data and ma!e the rest of it coherent. These two steps are called data purging and
data cleansing.
This can be done without specific !nowledge of "A# and can begin way before the pro,ect Dic! .ff. It will save you a lot
of time.
efore the la%t te%t r'n+ taBe into a&&o'nt the &'%to(iCation% of yo'r ne3 %y%te(
-ecause both the organizational structure and the actual customizing influence the data you transfer for business ob,ects,
finalize all customizations before the last test run. 5ustomizing changes after the final transfer may result in additional
re)uired fields, this re)uires preparing and transferring more data. It can also invalidate the loaded data, which leaves you
with an incoherent data set that will be very costly to correct after Ao 9ive.
Red'&e the a(o'nt of hi%tori&al data to *e tran%ferred
If your system has lot of historic data, thin! about archiving data. There is no need to spend large amount of money to !eep
live data that are otherwise used sporadically and could very well be stored in an archive database.
9arge data set due to nonGarchiving of your 9" will add a lot of strain on your "A# implementation and will ma!e the data
conversion more difficult because of the volume. Also, because data tend to be less accurate when they where created a
long time ago, it will be much more difficult to adapt them to "A#.
$%e &ontrol% edition in SAP
:ata entered in "A# should de chee!ed using some controls reports. This is especially useful for manual data entry and
transactional data.
S(all i% *ea'tif'l
"tart small. The first time you transfer data, begin with a few records of a business ob,ect. This way, you learn how the
program wor!s. After transferring some records successfully, try transferring a larger amount of data. 4a!e sure that you
transfer each different type of data before you transfer on a larger scale.
e 3i%e
The full data integration in your production system is the end of the process and should mostly be a technical operation
where we push some buttons to get some results. To reach this goal, it implies that all functional and technical issues where
dealt with before starting the full size transfer from the 9egacy "ystem. The hard wor! is in the mapping and establishment
of conversion rules from the old to the new system. That is where you will ma!e or miss your conversion. :onJt even thin!
about loading large volumes into production if you are not completely ready.
Play it %afe
I strongly suggest that you perform a system bac!up 7or client copy8 after transferring a significant amount of data. The
bac!up allows you to secure a specific level you have reached during the data conversion process. If you have any
problems, you can return to this level, and you do not have to begin the process all over again.
Data Migration Methodology for SAP
PAGE 1#
1.3 SUGGESTED ADDITIONAL READINGS
"A# :ata Transfer 4ade ;asy guideboo!. It can be found on the "A# "implification Aroup web site
"ystem 9andscape 79andscapeGII.pdf8 fount on "ap9abs website
Suic! $eference Auide 9"42 7Fow to H8 and #resentation of 9"42. 5an be found on web site
http011service.sap.com1lsmw It re)uire a user name a password
Data Migration Methodology for SAP
PAGE 1.
SECTION 2 - ORGANIZE THE DATA CONVERSION
Data Migration Methodology for SAP
PAGE 16
:ata 5onversion #lan
2-"
5alendar planning
Data Migration Methodology for SAP
PAGE 1:
2.1 OVERVIEW
This section describes the organization of the conversion. This is the first building bloc! of your conversion process and
must be completed right at the beginning of the pro,ect. This part of the process is to be done by the pro,ect manager and
the data conversion coordinator.
2.2 DATA CONVERSION PLAN
'%ine%% O*1e&t%
A -usiness ob,ect is a general category for data that defines something li!e material master, vendor master, stoc!s, orders,
purchase re)uisitions or organizational units. The first step is identifying which business ob,ects are re)uired in your "A#
implementation.
Data ty2e
There are three types of data involved in a "A# system0 master data, transactional data, and historical data.
Ma%ter Data) Application master data tends to be more static once defined. 4ost master data can be driven by the
legacy applications. ;amples include vendors, customers, charts of accounts, assets, bills of materials, material
masters, info records, and so on.
Tran%a&tional Data) Transactional data is current and outstanding transaction data that needs to be captured from the
legacy system and defined to the "A# $1% applications for business process completion. ;amples include accounting
documents, open purchase orders, open sales orders, bac! orders, and so on.
Hi%tori&al Data) Fistorical data needs to be brought over from the legacy system to the "A# $1% "ystem for reference
purposes. ;amples include closed purchase orders, closed sales orders, summary general ledger information, and so
on.
Data &on/er%ion 2lan %a(2le
Data Migration Methodology for SAP
PAGE 18
Infor(ation to &o(2lete in the &on/er%ion 2lan
,hat 2hich business ob,ects will be converted from the legacy system into "A#.
,here 2here are the data, which 9egacy "ystemJs are involved for the etraction.
Ho3 ('&h ;stimate the number of records to be ultimately loaded into "A#.
Ho3 There are two aspects to be considered 0
The way data is etracted from the 9egacy "ystem
Automatically etracted from the 9egacy system without manual intervention.
4anually filled spreadsheet
5ombination of an automatic 9egacy "ystem etraction R 4anual ;ntry into a spreadsheet
The way data is in,ected into "A# 0
Automatic data transfer from a flat file into "A#
4anually entering data with online transactions into "A#
5ombination of both
The data transfer method you choose will determine the types of resources you need. 3or eample, you
may need temporary employees for the manual data entry and programmers for writing your own
etraction programs. *ou need to !now both what data is in your legacy system and which "A#
applications correspond to the business ob,ects that will be transferred. .ne person does not have to !now
all of this, but the people who !now this information should wor! closely together.
,ho 2ho is involve on each -usiness .b,ect 0
Dey user 73unctional responsible of -. conversion 0 $ules, manual data corrections, test, validations8
5onsultant
$esponsible of data cleaning and purging in the 9egacy "ystem
$esponsible of the etraction
$esponsible of loading data in "A#
-usiness .b,ect 4anager 7Fierarchic owner who is responsible of day to day use and integrity of
information and the one which will be signing off for data acceptance8
This part seems easy enough. Fowever, you will )uic!ly see that getting a clear answer to these )uestions
is no easy tas!. Ta!e the time and energy it needs to answer these )uestions meticulously. It will avoid a
lot of turning in circle and save you lot of time throughout the pro,ect.
Fa yes, I forgot one thing, 4AD; "=$; that all whose name is on the document are aware of it,
understand what it mean and approve it.
Data Migration Methodology for SAP
PAGE 1=
Main '%ine%% O*1e&t% %e?'en&e of &on/er%ion
G A9 account 4aster
7Include primary cost L revenue elements8
G #rofit centers hierarchy
"torage -ins
G #rofit centers
G 5ost centers hierarchy
G 5ost 5enters
#reG$e)uired
- . 4
#urchase
info records
5ondition record
G :iscount
G #ricing
$outing Tet
"toc!s 7648
"toc!s 7I48
.pen "ales .rders
5ontracts
.pen #urchase .rders
.pen A1#
.pen A1$
.pening -alances
.pen #roduction .rders
5ustomer 4aster
2or!
5enters
6endor 4aster
4aterial 4aster
G 5haracteristics
G 5lasses
.ptional
Internal orders
2-" elements if #" module.
G Activity types
-an!s
"ource lists
"ales
info records
:oc 4ast
$outing 1 Tas! list
Data Migration Methodology for SAP
PAGE 1>
2.3 WBS ( work br!k"ow# $%r&'%&r(
,hy a ,S -
;stimates for a pro,ect planning must be deducted and ,ustified from a logical process. They represent the real wor!load
re)uired for the different tas!s of the pro,ect. The 2-" is a great tool to figure out these numbers. It will permit to estimate
the wor!load of each tas! without any duration or calendar consideration. Ignoring the date factor help in getting as
ob,ective as possible. The wor!load is calculated in #erson1:ays. 2hether there is one or five persons assigned to a tas!,
the wor!load is always the same. The usage of #erson1:ays will help in getting a more precise calendar planning and will
ma!e evaluation of the conversion progress easier.
,S Sa(2le
Ho3 to
The idea is to brea! the pro,ect in chun!s and then brea! each of these in tas!s. *ou then proceed to evaluate the wor!load
re)uired for each of these elements. It will be much easier to get accurate and ob,ectives numbers on small specific tas!s
than on a large chun!. Fow to brea! it and at which level is more an art L eperience mi than it is a science. The more
2-" you do, the better you will get at it.
If your 2-" is not granular enough, your estimate is more difficult to get and will be less accurate. An error on one
element will also have a greater impact. As for progress followGup, it will be less accurate, since any detected slippage will
involve higher number because the element is itself too big.
If the 2-" is too granular, you will get lost in a forest of details and numbers. The followGup will also be much more
difficult and it will be difficult to get the whole team to use it 7too comple8.
In this methodology, the 2-" I suggest is a middle ground between these two limits. I got to this one by trials L errors on
different pro,ects. I thin! it is granular enough to be precise and usable for efficient followGup. *et, simple enough, for the
whole team to easily contribute in evaluating the numbers.
Data Migration Methodology for SAP
PAGE 1@
In order to get a successful evaluation, follow these guidelines 0
;valuate each and every element of the 2-" while ma!ing abstraction of the other tas!s. This gets you an ob,ective
evaluation of each tas! independently of each other.
It is important at this point to ma!e complete abstraction of calendar planning or any target date. 3orget when this
should be finish or how long should it last. Tust try to figure out the real wor!load needed to complete each element of
the :5 process. After that, we will see how we can meet deadline by acting on the organization of the pro,ect rather
than <fiing up< the estimate. "tarting a 2-" while ta!ing into consideration a goal to meet, li!e a specific date or
target total of #erson1:ays, will only lead to complaisance planning which will be false and get you in trouble.
S'gge%ted ,S &ontent for data &on/er%ion
7ol'(e%
Suantity of records
Suantity of fields
( 4anual fields
'%ine%% O*1e&t% Ma22ing 4 !on/er%ion D 3or detailed information on these items, refer to section % E
:ata #urging and 5leansing
4apping and conversion rules
;tract and 9oad #rograms from rules
:ata and $ules Adaptation 7ad,usting rules and programs following testing8
9oad =nit Testing 7unitary testing G small volume of manual data8
;tract and 9oad 3ull size testing 7data test and validation G large volume with real etracted data8
A&&e2tan&e load and /alidation
3ull data loading into A55;#TA/5; "*"T;4
3ull data loading into #$; #$.:=5TI./ "*"T;4
6alidation of converted data and Dey =ser R -usiness .b,ects .wner "ignoff
3ull conversion into #$.:=5TI./ "*"T;4 and final "ignoff
Total
Total G at best 7total in #erson1:ays of each business ob,ect8
Total G most probable 7total at best R +' to +B( buffer8
Are yo' %'re -
<That much, are you sure E< This is probably the first thing you will hear when showing your 2-". In many pro,ects, the
notion of estimating wor!load in #erson1:ays eists in theory only. 2hen you actually get the numbers, it seams a lot of
time and a lot of money ,ust for converting data.
2ell <,ust converting data< is an understatement, as stated earlier this is an important part of the pro,ect. A value of &''
#erson1:ays on a +' people team is not a lot of time. It adds up very )uic!ly. Tust have a + hours meeting once a wee! with
seven people and it will consume two #erson1:ays each wee! throughout the pro,ect. "tretch the meeting ,ust a little hour
more than epected 7sounds familiarQ8 and the e)uivalent of a whole day of wor!, for one person, ,ust went by. Add to this
the little informal meetings between !ey users, consultants and :5 team members for each business ob,ect to convert. This
)uic!ly adds up to a nonGnegligible amount, and that is ,ust for meetings, no tangible deliverable is produce yet.
Re?'e%t to re"e/al'ate yo'r ,S
"ometimes, after the <are you sureE<, comes the <please reGevaluate with the !ey users L consultants<. This is a very
,ustified re)uest H but. -e careful, this usually results in trying to reduce the largest numbers by hammering them down
with various theories, totally forgetting the smaller values.
Data Migration Methodology for SAP
PAGE #A
2hen getting the numbers for the original 2-", you average each element. .verall, you under estimate some and over
estimate others, but the average law will ma!e it a globally reasonable measure. Fowever, if you start concentrating on
some numbers while forgetting others, the average law is out the window. This is why you must consider, both the large and
small values, when reGevaluating a 2-".
Fere are some suggestions I give to those concerned when reGevaluating a 2-" 0
;plain clearly what a #erson1:ay is0 <letJs say you have only this to one tas! to do and you have to do alone, how
many days will it ta!eE<.
;plain the wor! to evaluate. 3or eample, ma!ing the conversion rules mean U tal!ing about it with the consultants
and 9egacy "ystem epertsU writing the first version U having meetings to answer gray areas U doing some tests for
uncertain fields U cross reading the documents and finally, some reflection time. Therefore, as you see, it is lot more
than ,ust figuring how long it would ta!e to write some lines of rules.
5ount everyoneJs time. In the above eample, you must count time for you, the consultants, the 9" ;perts, those
present at the meetings, those doing tests, etc. It adds up very )uic!ly.
;plain the average law I mentioned above and ma!e sure they do reGestimate all the elements with the same scrutiny.
2hile some high wor!load tas!s may be overestimated, some smaller one are probably underestimated as well.
Avoid tal!ing about deadline or total wor!load. They have to evaluate all elements independently from each other.
I personally went through that process a few times. Interestingly in all cases, the reGevaluation turned out with a slightly
higher global number. 4ainly because they realize there is more, small but still time consuming, tas!s than originally
thought so.
So(e 2ointer% to fig're o't n'(*er%
These are pointers to help you come up with the first draft. *ou need that first draft as a starting point of discussion before
you start trying to get help from the rest of the team.
If there are two legacy systems, it will ta!e twice the time 7see net title J-allpar! figures for more info8.
As mentioned earlier, avoid thin!ing about deadline or total wor!load. Tust honestly evaluate each element
independently from each other.
3or some elements, you are clueless. It is very difficult to find someone who !nows all, but there is always someone
who can help you on a specific topic. This is where splitting a pro,ect in small elements will help. :o not hesitate to
as! around.
Ta!e into account the number of fields you need for each -usiness .b,ect. If you have no clue, ta!e +'' for 4aterial
4aster, &'' for 5ustomers, &'' for 6endors, I' for -.4, I' for $outings. These figures are for an implementation
with modules 3I, 5., 44, ## and ":. 9ater on, you can ad,ust to values that are more eact.
3or -.4 and $outings, if they are merged in a single structure in your 9" 7i.e. multilevel8, count that -.4 will ta!e
double the time you originally estimated and $outing will most probably have to be done manually from scratch. "A#
is "ingle 9evel 7unless it changed in newer versions8 which mean that materials hierarchy is in the -.4 and the
operations se)uences are in routings.
4aterial 4aster is huge. It re)uires time and energy, lots of it. .n top of being a difficult one, it is the first one you will
have to do.
It involves many of people from different domains.
There is much to learn while doing 4aterial 4aster, and this learning will put in )uestion the process, which
!ey users though they had already cornered.
:ifferent people come up with their own set of rules, which need to be put together in a single 4aterial
Data Migration Methodology for SAP
PAGE #1
4aster. This will create collisions and conflicts, which will need meetings, discussions and testing before the
issues are solved.
The conversion rules are different for each 4aterial Type and it is not always the same !ey users who have the
info for the different types.
.ther than the -ig 3ive, wor!load estimates are rarely lin!ed to the number of fields. The !ey is then the )uality of the
9egacy "ystem data. Fere are some factors on that will ma!e the process much longer0
Fistorical data that was never purge
Inconstant data 7well, no one have these in their systems, rightQ8
#art of the data eisting aside in ;cel, Access or other non formal system
Information spread into different systems
/o clear owner or manager of a business ob,ect in the 9egacy "ystem 7then it is probably messy8
-e conservative, in doubt, over estimate rather than under estimate. /ever mind how much you investigate or !now the
9". There is always one business ob,ect where you will discover, at the last minute, that it ,ust will not fit into "A#
without ma,or unplanned efforts. It is not bad luc!, it ,ust happens every time. -ad luc! is when you did not consider it
in your planning.
If the data is not etracted from the 9" but generated manually, it will ta!e longer. The time is however more
predictable as manual data is rarely bugged.
2hen you etract data automatically from the 9", it should be faster. Fowever ta!e into account that programming
means possible bugs. It also needs modifications when the rules change 7and change they will8, which again may bring
bugs
If you have part automatic and part manual, li!e <yes we can etract most of it, but need to do some ad,ustments in
;cel<, add etra time 7B' to &''( more8. At first glance, this seems li!e the easiest way to go. 2ell, itPs notQ Trust
me, these will be real headaches. Although almost impossible to avoid them, try having as little as possible of these. In
all cases, prefer maimum usage of conversion rules.
all2arB fig're%
Fere are some figures to give you a ballpar! of the pro,ects I wor!ed on. These are not absolute figures, as they vary from
one pro,ect to another.
In pro,ects involving the modules 3I, 5., 44, ## and ":, having from +' ''' to I' ''' material master items with all
related -.4 and $outings, about + ''' vendors1customers, &' ''' inventory records and all other basic :5 stuff, it gave
me something between I'' to C'' #erson1:ays per legacy system.
I say per legacy system and this is something important to consider. If you have different legacy systems, you tend to thin!
the second one will go faster than the first. There is absolutely no gain. ;ach system must be evaluated as if it was a
different pro,ect. If one ta!e B'' #erson1:ays, than two 9" will ta!e &''' #erson1:ays. This will probably be a ma,or
disagreement point among the team when you will show your numbers. Deep in mind that for all the pro,ects I wor!ed on,
it proved to be true. 4apping is different, conversion rules are different and issues with 9" data will not be the same. "ince
these three items represent the bul! of the :5 process, you can see why two 9" will be twice the energy.
A for('la to hel2 F) Handle 3ith &are
Fere is a formula for the -ig 3ive. I came up with it when I started doing data conversion. I established it by loo!ing bac!
on previous pro,ects. I as!ed how many #erson1:ays it too! in average to do each of the -ig 3ive. This was the total time
including meetings, writing rules, updating data manually, programming loading tool, etc. Then, with the precious help of
people who had first hand eperiences doing :5, we came up with a formula to calculate a first estimate.
As I went on different pro,ects, I realized it was good enough to give me a first estimate in all cases. Fowever, handle this
with care. This really needs to be used as a tool that will help on a first draft. *ou need to challenge these numbers and use
your ,udgment to ad,ust the values.
Data Migration Methodology for SAP
PAGE ##
-ase on the volume data from your 2-", you can calculate as follow 0
3or mapping 0 5ount &' min per field 7'.'+ day per field8 and add & day to the total for set up and eplanations
5onversion rules 0 5ount &' rules per day 7'.& day per field8
:ata and $ules Adaptation 0 5ount &+ seconds 7V'.'''I&C day8 per record and by field 7number of fields number of
records '.'''I&C8. There is more, later on, eplaining what is O:ata and rules adaptationP.
As you see, you need to establish how many fields need :ata and $ules Adaptation. I use a percentage in the 2-" so that I
can recalculate all the wor!load easily as I learn more about the 9". -ase this on the number of fields you will populate in
"A#. I usually count that about ?'( of the fields are solved by conversion rules and +'( will need data and rules
adaptation. If the data are in bad shape in the 9", go toward >'(G%'(.
This formula is most pertinent for 4aterial, 5ustomer and 6endor masters. 3or -.4 and $outing, the time is less
dependent on the number of fields than on the compleity of the data to etract. 3or those two, you can use the formula and
then add between B'( to &''(, depending on the legacy data compleity. As stated earlier, if -.4 and $outing are
merged in a single structure in your 9" 7i.e. multilevel8, count that -.4 will ta!e double the time you originally estimated
and $outing will most probably have to be done manually from scratch.
.ther than the -ig 3ive, the number of fields has little to do. It is the compleity of the process, which needs to be ta!en
into consideration. If you really count all the time spent on one business ob,ect, none will ta!e less than &' #erson1:ays.
=se you ,udgment and apply between &' to %' #erson1:ays per business ob,ect according to epected compleity. ;ach
time someone tells you <this is a one day thing<, ma!e a note of it and follow the time it really too! from start up to a
loaded and validated data set H you will see, nothing ta!es less than &' days.
Another business ob,ect, which is also special, is inventory. At first it loo! simple enough, but getting &''( of the data in
"A# will prove to be a challenge... if you plan to shoot less than &''(, go bac! to page & of this document.
If you use 24 in "A#, it will be even more challenging.
If you have a good wor!ing 24 in your 9", it will be a challenge.
If you use 24 in your 9" and it is not wor!ing perfectly, it will be a great challenge.
If you do not have 24 in your 9" and want to use 24 in "A#, than you are in for a hec! of a ride. In this situation,
consider converting without 24 and implementing it later, once you system has been stable for a while in production.
3or Inventory, count %' days for I4 R up to &'' days for 24 according to the three possible scenarios I ,ust mentioned. If
you have a doubt, try finding someone who went through it before. :one right the inventory load ta!es lots of wor! but the
process will go well. -adly managed it will !eep you up +Ihrs1day for a few days before A. 9ive H and after.
Data Migration Methodology for SAP
PAGE #.
2.) CALENDAR PLANNING
O/er/ie3
At this point, you have assigned resources in the :ata 5onversion #lan and estimated the charge for each of the 2-"
elements in #erson1:ays. *ou must now transform this information in duration for each tas!, this is the calendar planning.
To do the calendar planning, using 4"G#ro,ect or other planning tool, you will enter the tas!s and complete it with the
following information 0
Tas!s efforts in #erson1:ays
Tas!s dependency
/ames of the resources assigned to each tas! and the percentage of their availability on it
/on wor!ing days and Foliday.
This will not only give you a calendar date planning based on an ob,ective wor!load estimate, but it will also permit a )uic!
identification of resource overGallocation, overlapping of dependant tas!s, and delay due to non wor!ing time and
bottlenec!s.
.n most conversion, the overload on !ey user is always a ma,or problem. *our !ey users will be strongly solicited right
from the beginning of the pro,ect. Deep in mind that the more you go on with your pro,ects, the more they will be solicited
to troubleshoot problems, and this will be on top of their normal conversion wor!. The result is that their availability will
only get lower as the pro,ect is going on. :o not under estimate this fact in your planning.
.nce you will be done with the :5 calendar planning, you must integrate it in the overall pro,ect planning and do a
resources load analyses. This tas! is most difficult, time consuming and very frustrating 7especially if you do not master
4"G#ro,ect8.
!alendar 2lanning %a(2le
Data Migration Methodology for SAP
PAGE #6
MS"Pro1e&t or not)
4ost probably, the only planning tool youJll have available will be 4"G#ro,ect. Although it is a nice tool, it also has great
talent in Jauto messingGupJ your schedules 7ma!e bac!up copies H and ma!e them often8.
4y first advice is that you should learn the basics of 4"G#ro,ect before you get into it. It will be a much less frustrating
eperience. "ome )uic! learning boo!s can be found and are useful
2hichever tool you use must be able to give you a resources load analysis. This will be a !ey element of you planning.
Se?'en&ing the ta%B%
2hen I se)uence the tas! within one business ob,ect, I never overlap two tas!s. *es, since the process between test and
rules and loading is iterative, we should be able to do them in parallel. Fowever to do this realistically you would need to
consider the effort on each tas! to be nonGlinear. If you get into this, your planning will ta!e forever H if ever you finish it.
;perience has proved that the best way to get an accurate calendar planning for the :5 process, while !eeping it simple
enough, is to never put tas! in parallel within a business ob,ect.
Gey '%er% and &on%'ltant a/aila*ility to 3orB on Ma%ter Data
2hen assigning !ey users and consultant to the :ata 5onversion tas!s, count only +'( of their time available. This gives
you an average of the time they will be able to give you throughout the entire pro,ect. "ometime it will be less, sometime it
will be more, but overall it will be +'(.
<+'(, that is only one day a wee!Q<. *es, remember that bottlenec! we mentioned before. *ouJll see that getting this much
attention from !ey users will be )uite a challenge when you get towards that bottlenec!.
And remember, if you ta!e +'( of the !ey userPs time for :5, whoever is planning other wor! on the pro,ect must ta!e
into account that the key users are available at only 80( for them.
End Hat *e%tH 7S H(o%t 2ro*a*leH
In the 2-" you estimated all the tas!s as honestly as possible, which gives you the re)uired wor!load at best. Then you
added +' to +B( buffer, which gives you the most probable effort.
In the calendar planning, all tas!s are entered with the 2-" value at best. The end date will then be the <at best<. To get
the most probable end, you need to add a single tas! at the very end of that planning which is e)ual to the buffer in the
2-" is entered. The resources allocation is to all !ey users at +'( 7ta!e into account only lead !ey users for each domain,
not support consultants8.
3or eample,
At the very end of the calendar planning, I will add a +'' days tas! with B resources. This will translate as a
+' days duration buffer for the lead !ey users.