Data Migration Methodology for SAP

“If one can manage small decisions now, the large ones will gradually disappear or might never appear in the first place.” Anonymous

PAGE 1

DATA MIGRATION METHODOLOGY FOR SAP
Y

!HRISTIAN

ERGERON

" cvcby@yahoo.com

Data Migration Methodology for SAP

PAGE #

A O$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 e periences. 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
Ter(inology and A**re/iation%0 /ote0 The terms "A# and $1% are both use interchangeably to refer to "A# $1% system.

PAGE .

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 te t 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" e traction 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 e tracted 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 e ample, the <"ales .rganization< will be set accordingly to the material type. , S 0 2or! -rea!down "tructure.

Data Migration Methodology for SAP

PAGE 6

TA LE 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

........................................ G :ata conversion specification M -............................................................................................+ :ATA #=$AI/A A/: 59....KT$A5T A/: 9..............................."TI/A A/: :ATA 6A9I:ATI.....I& !ON!L$SION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6# APPENDI5 < 7ARIO$S TEMPLATES)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6................................................................+? %............................$"I........C 9...............................%? %.....II ......................II ............. • • • • • • A G 5onversion plan template........................+? :ocumentation of your wor! 7conversion spec.................................:=5TI.....................................................4 L $outing Template "amples...................."TI................................% 4A##I/A A/: 5............................................................%> 4urphyJs protection 0 "ave it often H and get good bac!ups..... :ATA 5.........................................................II ....................................................................................E!T)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))#8 %..............6..............................................................................II 3 G 4aterials 5lasses and 5haracteristics structure.....................................................#TA/5..............................%I :irectory organization...................................."TI/A.................................................. and mapping sheet8...................+B SE!TION .............A:....................." A:A#TATI....................+I 2or!load analysis..............................................................................................A:....................................................../ TF......................../" ...........................+? %.........$6I............................................../ $=9..........I' %.........................A: =/IT T........................................ #$.......................................G 2-" template.......................................A/"I/A................2......................................./ 9.................................%' All other business ob......................................................................................./ 9A/:"5A#..............................II : G :ata conversion specification G Aeneric template..................................................................... T.ects...........?A55..A$A4"..........................I' %............... "*"T....................Data Migration Methodology for SAP • • PAGE : Are you sure E..........................................%> 6ersion management of conversion rules................................................./.......B :ATA A/: $=9.......................A: M 3=99 "IN.................................................................................................@#$.....................................................+? • • • • • • About the rules....../6.......A: #$....................................................................I& %..........................................+@ A special case for 4aterial 4aster..............................................................................................I .........................................%@ %......./ A/: #$................KT$A5T L 9......................................................................................& .......................&'"=AA.........."........II 5 M 4aterial 4aster G 3ields selection sheet...I' %.......> ................... " !ON7ERTING A $SINESS O .........................%? %..................................$"I..............................:=5TI.........................................../...../6...............................................................................................4 3=99 9.........................................................+? • • -efore you begin...............

INTRODUCTION TO DATA CONVERSION .Data Migration Methodology for SAP PAGE 8 SECTION 1 .

*et. This guide is aimed at helping you organize the data conversion process.ust will not get in at all. money. An important part of this challenge will be the data conversion. time8 and in business process. • At Ao 9ive • • • 4aster data deadlines where constantly busted and production load is done in JJrush modeJ at the last minute. #oor data conversion will ma!e your “Ao 9ive” very difficult. a solid organization. 9ive. As we get near the Ao 9ive. which in turn.ne that will provide you with a realistic planning. 3unctional changes are not impacted on the converted data. you need a good methodology. somehow. functional and technical8. This ma!es the process difficult and time consuming H. a%e% fro( 3hi&h thi% (ethodology 3a% (ade 2hen I was originally as!ed to come up with a method to convert data. if not impossible. data are moving targets. a way to manage the process and control tools to detect and correct slippage before it becomes a problem. This translates into a costly operation. for most of you.ect. both in terms of resources 7people. . most of them are not progressing. To put all odds on your side. "ome !ey parts of the data cannot be loaded in production. they will have to be entered after A. they always seem to be outdated. . #revious implementations of "A# have shown that data migration can amount up to about I'( of the entire pro. #atches are applied to the master data in order to forceGload. friction and frustration between the functional and technical team. failure is not an option you can afford.1 INTRODUCTION O/er/ie3 Implementing "A# is an important challenge.Data Migration Methodology for SAP PAGE = 1. this becomes much worst. • 4ost of the problems encountered are actually functional issues. A lot is at sta!e and. :ata loaded is regularly incomplete and inconsistent. will lead to a successful implantation. • Information does not travel well between functional and technical team. There is a lot of misunderstanding. After discussing with people who lived these situation 7manager. we identified the following points 0 • #lanning and resources load estimates where way out 7when they e isted8. There are documents all over the place and. I started by analyzing passed e periences. -ecause the production system is now living. • After Ao 9ive • "ome :ata need to be corrected L entered after Ao 9ive.ect is going on0 • • • • • • There are many things being wor!ed on at the same time.ected by "A#. There I found the following recurring problems 0 • 2hile the pro. :ata previously loaded with success is suddenly re. "ome data .

PAGE > 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. A fe3 fa&t% The data conversion is not some technical stuff to give to the programmers and wait until it comes bac!. the customizing is made accordingly to the way you do your process. The mapping document and conversion rules will become the common ground for discussions between the different domains. /ice. and master data is needed to run your process.!. 5ross reading of :5 specs is essential as. on data )uality and coherence. !on/er%ion r'le% and *'%ine%% o*1e&t o3ner%hi2 . At first. this process will not simplify the technological aspect of the conversion. $esults will initially be slower to come. Although the e tract 1 load process itself will not be effortless.ect. :o not underestimate this. There is no Jeasy does itJ way to do the data conversion and it ta!es time. 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. . The goal of the mapping and rules writing is to get !ey users to sweat it out and understand "A# way of doing things. if not all. They must understand which data does what. both in term of timing and deliverable. data must not be shoveledGin and it will ta!e lot of wor! and time. /o e pediting. you will end up shoveling a ton of data into "A# at full speed with little control. $emember the old saying <garbage in. because you will get things right on the fist time. no bypassing of step.ects I wor!ed on. a small change in ## can bloc! all e peditions. I saw this !ind of issues in all the pro. it is the one at which you get out of it. your master data may become incomplete or incorrect. It is OtheirP master data and they will do mapping L rules documents. no piling of unsolved issue to !eep going. As in car racing. I give them the responsibility and ownership of the 4apping and conversion rules. garbage out<. This is actually true of any concept. Fowever. -oth aspect of it must be applied for results to show up. but what does it meansE The answer is that everything is tied together. Aetting the right data at the right place with the values re)uired for your business process is always a functional problem. of the issues and problems you will encounter in the conversion process will be functional. It will also be the only common language document between the functional team and the technical team.ect. 3or !ey user to get this !nowledge. I ma!e the :5 process part of the functional process. 2hichever phases you are in the pro. "A# is a processGoriented system and master data is an integral part of this process. The mindset re)uired in our case is that we must do things right from the start and solve issues as they occur. it is not the speed at which you enter a turn that is most important. /o technological gadget or guru will ma!e this otherwise. :ata conversion is made with lot of brain stuff mi ed with hard wor! and some programming. it is the part between the e tract and the load that is the most difficult. eventually. which are needed. This will also help the !nowledge transfer between consultants and !ey users. 2hen they are done with this. 4ost. it will most probably change the behavior of the process. :oing this will put the conversion process too close to the end of the pro. how it relates to the customizing L process flow and figure out where it will come from. nor will it ma!e it shorter or easier H say whatQ As I already mentioned speed will come.Data Migration Methodology for SAP This methodology was made to solve these issues. you will eventually pic!Gup an impressive speed. 4aster data is dependent of the customizing. Fow do we manage his E To solve this. Dey users must do a thorough analysis of the master data and lin! their usage to the process as they are customizing. if any. This !nowledge will get things to fit progressively one into the other li!e a set of bloc!s. In that situation. their brain will play that “master data G business process G customizing G” game without even thin!ing about it. 4ost of concept failures are due to application of the techni)ue while neglecting the philosophical aspect of it. we now !now :5 is a functional thing. for e ample some action ta!en by ## may affect ": and 3I. If you change master data. If you change customizing. Ta!e the time that it re)uires to do thing properly and thoroughly.

ects data conversion 7The resource responsible of the -usiness . you should consider the data conversion as a pro.ach step has its own use. "o any discussion. 2hen the spec has no ambiguity and has been cross read and validated by all domains and the technical team. data validation is done by !ey user. 3or this reason. In addition. e ecute and followGup your conversion. If you try to identify where there will most probably be a bottlenec!. Aetting a complete and final planning will ta!e at least one more wee!. ta!e the time that it gets to have clear and unambiguous :5 rules. #$.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 . The main steps of the data conversion are0 • . If it is not in the rules. you must first get organized. the ris! of conflicting tas! is high and can )uic!ly lead to a bottlenec! where !ey peoples are overloaded./ "*"T.ect :58 • :ata #urging and 5leansing • • • • • • • • • 4apping and conversion rules . can you start the development of the e tract and load programs. Aoing through this will permit to plan. lots of it. you will control the evolution of the data conversion process.4 3ull data loading into #$. $emember. it is usually that time where !ey users are out giving training.Data Migration Methodology for SAP PAGE @ The mapping document and conversion rules will become the technical staff road map. *ou will be surprised to see how things change between verbal decision. functional issues are solved by !ey users./ "*"T. tests are done by !ey users.here yo' 3ill+ for %'re+ ha/e a ti(ing 2ro*le( The business process analysis is done by the !ey users.#TA/5. The methodology is based on a top down process. The intersection of 4aster :ata validation. when you start validating master data.ects e perience and will help you to avoid the pitfall usually associated with data conversion. As the pro. "*"T. integration testing and training will be JitJ. Main %te2% of the &on/er%ion (ethodology -efore you even start to wor! on specs. 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. do not loo! any further. and written decision which re)uired thin!ing about it and assuming responsibility for it.b. business issues are dealt with by !ey users. .usting rules and programs following testing8 9oad =nit Testing 7unitary testing G small volume of manual data8 . These same resources will most probably be involved in other part of the pro. master data issues are solved by !ey users H.b. it is to finish the OwholeP process faster.ect within the pro.ect.rganization of the data conversion 7#ro. Again. *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.4 and final "ignoff • . which will leave you with some )uestions on pro.ect. data conversion rules are done by !ey users. Aetting a good planning and organization structure ta!e about two wee!s for the first draft.:=5TI.wner "ignoff 3ull conversion into #$. sometime made in the hallway between meetings. organize.:=5TI. *ou may sometime feel li!e you are not going to the end by the shortest route. decision or answer must be documented in the rules.ect is going. 3or this reason. The data conversion re)uires functional and technical resources from most departments. the goal is not to get first results faster. training is prepared by !ey users. This method is based on many pro. tract and 9oad 3ull size testing 7data test and validation G large volume with real e tracted data8 3ull data loading into A55. tract and 9oad #rograms from rules :ata and $ules Adaptation 7ad. and only then. That will be the point where will start pic!ing up speed.ect organization.ects .b.4 6alidation of converted data and Dey =ser R -usiness . . Any unsolved issues on these will haunt you throughout the pro. it does not e ist. so finish this completely before stating any other step.ect.

there are . *ou will have no other choice than spreading the load throughout the entire pro. *ou must give &''( at all steps to achieve the point where the result will be bigger than the sum of your efforts.ect longer. your computer will bring you bac! to reality the hard way. /o free lunch here. There is no Oeasy does itP way to do data conversion. . pediting. If the final data set is not accurate and well structure. sometimes much longer and always a lot more e pensive.Data Migration Methodology for SAP PAGE 1A There are not many solutions to this. bypassing or neglecting a tas! will have a negative effect further down the road.ust ma!e a long pro. :oing things right the first time is an investment and li!e any investment it has a cost 7money. we are bac! to the basic rule. *ou will need discipline. 5omplaisance planning will . this !ind of pro. Therefore. Assuming your team is sized correctly. Trying to go too fast with insufficient resources is usually the basic recipe of most horror story you hear about "A# implementations. lots of it.ust some path easier than others. There i% no %'&h thing a% a free l'n&h This is a simple system. time8 to be paid before you gets profits. .ect. people. doubling the resources will double the cost. cut your loss and figure out how to resolve problems than trying to !eep going the wrong way. double problems but probably not double the output. :o no pile up delay or issue. The &o(2'ter 3ill ha/e the la%t 3ord 5omputer does not do politic and cannot be <convinced< of anything. -etter to slow down. which will eventually create important delays. but simple does not mean easy.ect ta!es time and the best way to minimize it is to plan for it correctly.

this re)uires preparing and transferring more data. This is especially useful for manual data entry and transactional data. Pre2are the Lega&y Data*a%e 5lean the data on your legacy system.Data Migration Methodology for SAP PAGE 11 1. 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. establish what the 4aster :ata re)uirements are. .ff. This can be done without specific !nowledge of "A# and can begin way before the pro. it will be much more difficult to adapt them to "A#. which leaves you with an incoherent data set that will be very costly to correct after Ao 9ive.2 DATA CONVERSION GUIDELINES ThinB SAP 3orget your actual system and understand "A#. Red'&e the a(o'nt of hi%tori&al data to *e tran%ferred If your system has lot of historic data. 3irst and foremost. get familiar with the "A# business process you will be implementing. It can also invalidate the loaded data.ect Dic! . This way. begin with a few records of a business ob. do not try to fit in your old system into it.ect. $%e &ontrol% edition in SAP :ata entered in "A# should de chee!ed using some controls reports. :elete obsolete data and ma!e the rest of it coherent. It is easier to start from a sound legacy system than trying to fi inconsistencies during the conversion. Then. and you do not have to begin the process all over again.ects. :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. 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. thin! about archiving data. S(all i% *ea'tif'l "tart small. It will save you a lot of time. according to the "A# process needs. it implies that all functional and technical issues where dealt with before starting the full size transfer from the 9egacy "ystem. That is where you will ma!e or miss your conversion. finalize all customizations before the last test run. see what can be salvage from your legacy system. Then. The first time you transfer data. After transferring some records successfully. Also. you learn how the program wor!s. because data tend to be less accurate when they where created a long time ago. you can return to this level. The hard wor! is in the mapping and establishment of conversion rules from the old to the new system. The bac!up allows you to secure a specific level you have reached during the data conversion process. 5ustomizing changes after the final transfer may result in additional re)uired fields. and only then. To reach this goal. Thin! "A#. 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. These two steps are called data purging and data cleansing. try transferring a larger amount of data. 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. If you have any problems. 4a!e sure that you transfer each different type of data before you transfer on a larger scale.

3 SUGGESTED ADDITIONAL READINGS • • • "A# “:ata Transfer 4ade . 5an be found on web site http011service.asy guideboo!”.Data Migration Methodology for SAP PAGE 1# 1.pdf8 fount on "ap9abs website “Suic! $eference Auide 9"42 7Fow to H8” and “#resentation of 9"42”.sap.com1lsmw It re)uire a user name a password . It can be found on the “"A# "implification Aroup” web site "ystem 9andscape 79andscapeGII.

ORGANIZE THE DATA CONVERSION . SECTION 2 .Data Migration Methodology for SAP PAGE 1.

Data Migration Methodology for SAP PAGE 16 :ata 5onversion #lan 2-" 5alendar planning .

4ost master data can be driven by the legacy applications. customers. and so on. closed sales orders. summary general ledger information.Data Migration Methodology for SAP PAGE 1: 2. material masters. info records. open sales orders. purchase re)uisitions or organizational units. and so on.ects are re)uired in your "A# implementation. open purchase orders. Data &on/er%ion 2lan %a(2le . . assets. amples include accounting documents. vendor master. • Ma%ter Data) Application master data tends to be more static once defined. orders.ect is a general category for data that defines something li!e material master. This part of the process is to be done by the pro. . bills of materials. Data ty2e There are three types of data involved in a "A# system0 master data. 2. • 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.1 OVERVIEW This section describes the organization of the conversion. transactional data. and so on. amples include vendors.2 DATA CONVERSION PLAN '%ine%% O*1e&t% A -usiness ob. This is the first building bloc! of your conversion process and must be completed right at the beginning of the pro.ect.ect manager and the data conversion coordinator. . • Hi%tori&al Data) Fistorical data needs to be brought over from the legacy system to the "A# $1% "ystem for reference purposes. bac! orders. The first step is identifying which business ob. and historical data. amples include closed purchase orders. charts of accounts. stoc!s.

you will )uic!ly see that getting a clear answer to these )uestions is no easy tas!.b. Fowever. *ou need to !now both what data is in your legacy system and which "A# applications correspond to the business ob.here 2hich business ob.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 acceptance 8 This part seems easy enough. manual data corrections.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. • • • 4anually filled spreadsheet 5ombination of an automatic 9egacy "ystem e traction R 4anual . 4AD. conversion 0 $ules.ect. Ho3 There are two aspects to be considered 0 • The way data is e tracted from the 9egacy "ystem • Automatically e tracted from the 9egacy system without manual intervention. "=$.ects that will be transferred. It will avoid a lot of turning in circle and save you lot of time throughout the pro. 2here are the data.ect 0 • • • • • • Dey user 73unctional responsible of -.hat . I forgot one thing. which 9egacy "ystemJs are involved for the e traction.ntry into a spreadsheet The way data is in. you may need temporary employees for the manual data entry and programmers for writing your own e traction programs. . 3or e ample. • . but the people who !now this information should wor! closely together.ne person does not have to !now all of this.ects will be converted from the legacy system into "A#.stimate the number of records to be ultimately loaded into "A#.  Fa yes.Data Migration Methodology for SAP PAGE 18 Infor(ation to &o(2lete in the &on/er%ion 2lan • • • • . that all whose name is on the document are aware of it. test. understand what it mean and approve it.ho 2ho is involve on each -usiness . validations 8 5onsultant $esponsible of data cleaning and purging in the 9egacy "ystem $esponsible of the e traction $esponsible of loading data in "A# -usiness . Ho3 ('&h . .b. Ta!e the time and energy it needs to answer these )uestions meticulously.

rders 5ontracts .pen A1$ .rders . G 5haracteristics G 5lasses 4aterial 4aster 2or! 5enters -an!s :oc 4ast 5ustomer 4aster -.pen A1# .rders .pen #roduction .4 6endor 4aster 5ondition record G :iscount G #ricing "ales info records #urchase info records $outing Te t "ource lists $outing 1 Tas! list "torage -ins .pen #urchase .ptional Internal orders 2-" elements if #" module.pening -alances "toc!s 7648 "toc!s 7I48 .Data Migration Methodology for SAP Main '%ine%% O*1e&t% %e?'en&e of &on/er%ion PAGE 1= #reG$e)uired G A9 account 4aster 7Include primary cost L revenue elements8 G #rofit centers hierarchy G #rofit centers G 5ost centers hierarchy G 5ost 5enters G Activity types .pen "ales .

Fow to brea! it and at which level is more an art L e perience mi than it is a science.hy a . The followGup will also be much more difficult and it will be difficult to get the whole team to use it 7too comple 8. *et. S Sa(2le Ho3 to The idea is to brea! the pro. They represent the real wor!load re)uired for the different tas!s of the pro. . simple enough.ustified from a logical process. I got to this one by trials L errors on different pro.stimates for a pro. the better you will get at it.3 WBS ( work br !k"ow# $%r&'%&r ( . It will be much easier to get accurate and ob. it will be less accurate. An error on one element will also have a greater impact. Ignoring the date factor help in getting as ob. since any detected slippage will involve higher number because the element is itself too big. The wor!load is calculated in #erson1:ays. The 2-" is a great tool to figure out these numbers. The more 2-" you do.ective as possible. S . 2hether there is one or five persons assigned to a tas!. the wor!load is always the same. It will permit to estimate the wor!load of each tas! without any duration or calendar consideration.ectives numbers on small specific tas!s than on a large chun!. you will get lost in a forest of details and numbers. In this methodology.Data Migration Methodology for SAP PAGE 1> 2. If your 2-" is not granular enough. for the whole team to easily contribute in evaluating the numbers.ects.ect in chun!s and then brea! each of these in tas!s. .ect.ect planning must be deducted and . If the 2-" is too granular. your estimate is more difficult to get and will be less accurate. As for progress followGup. The usage of #erson1:ays will help in getting a more precise calendar planning and will ma!e evaluation of the conversion progress easier. the 2-" I suggest is a middle ground between these two limits. I thin! it is granular enough to be precise and usable for efficient followGup. *ou then proceed to evaluate the wor!load re)uired for each of these elements.

for one person. 2hen you actually get the numbers. "tarting a 2-" while ta!ing into consideration a goal to meet. A value of &'' #erson1:ays on a +' people team is not a lot of time.4 6alidation of converted data and Dey =ser R -usiness . tract and 9oad #rograms from rules :ata and $ules Adaptation 7ad. follow these guidelines 0 • . -e careful. totally forgetting the smaller values.ect. as stated earlier this is an important part of the pro. the notion of estimating wor!load in #erson1:ays e ists in theory only. 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.ust a little hour more than e pected 7sounds familiarQ8 and the e)uivalent of a whole day of wor!. consultants and :5 team members for each business ob. S "ometimes. will only lead to complaisance planning which will be false and get you in trouble./ "*"T. 2ell <. are you sure E< This is probably the first thing you will hear when showing your 2-".ust for meetings. we will see how we can meet deadline by acting on the organization of the pro. .ust converting data< is an understatement. Re?'e%t to re"e/al'ate yo'r .:=5TI.ects. It adds up very )uic!ly. "*"T. comes the <please reGevaluate with the !ey users L consultants<.4 and final "ignoff • Total • • Total G at best 7total in #erson1:ays of each business ob. li!e a specific date or target total of #erson1:ays. S'gge%ted .valuate each and every element of the 2-" while ma!ing abstraction of the other tas!s. In many pro.#TA/5.ect. This )uic!ly adds up to a nonGnegligible amount.:=5TI.b. no tangible deliverable is produce yet.ective evaluation of each tas! independently of each other.Data Migration Methodology for SAP PAGE 1@ In order to get a successful evaluation. After that.ust for converting data.usting rules and programs following testing8 9oad =nit Testing 7unitary testing G small volume of manual data8 . 3orget when this should be finish or how long should it last.ects . ./ "*"T.ect to convert. #$.ustified re)uest H but. Tust have a + hours meeting once a wee! with seven people and it will consume two #erson1:ays each wee! throughout the pro. and that is . it seams a lot of time and a lot of money . Tust try to figure out the real wor!load needed to complete each element of the :5 process. tract and 9oad 3ull size testing 7data test and validation G large volume with real e tracted data8 • A&&e2tan&e load and /alidation • • • • 3ull data loading into A55.ust went by. refer to section % E • • • • • • • :ata #urging and 5leansing 4apping and conversion rules .ect rather than <fi ing up< the estimate. after the <are you sureE<.4 3ull data loading into #$. This is a very .wner "ignoff 3ull conversion into #$.ect8 Total G most probable 7total at best R +' to +B( buffer8 Are yo' %'re <That much. this usually results in trying to reduce the largest numbers by hammering them down with various theories. • It is important at this point to ma!e complete abstraction of calendar planning or any target date. "tretch the meeting . Add to this the little informal meetings between !ey users. This gets you an ob.

. Ta!e into account the number of fields you need for each -usiness . They have to evaluate all elements independently from each other. It adds up very )uic!ly. some smaller one are probably underestimated as well. you average each element.4 and $outings.n top of being a difficult one. if you start concentrating on some numbers while forgetting others. the reGevaluation turned out with a slightly higher global number. you must count time for you. if they are merged in a single structure in your 9" 7i. small but still time consuming. the consultants. which !ey users though they had already cornered. 4aterial 4aster is huge. Interestingly in all cases. Therefore. it will ta!e twice the time 7see ne t title J-allpar! figures” for more info8. plain clearly what a #erson1:ay is0 <letJs say you have only this to one tas! to do and you have to do alone. you under estimate some and over estimate others. multilevel8. ## and ":. &'' for 6endors.Data Migration Methodology for SAP PAGE #A 2hen getting the numbers for the original 2-".e. It re)uires time and energy. both the large and small values. 5.b. which need to be put together in a single 4aterial • • • • . . when reGevaluating a 2-". Avoid tal!ing about deadline or total wor!load. 9ater on. If you have no clue. avoid thin!ing about deadline or total wor!load. It is very difficult to find someone who !nows all. I' for -. 3or -. &'' for 5ustomers. some reflection time. 4ainly because they realize there is more.4 and the operations se)uences are in routings. . These figures are for an implementation with modules 3I. *ou need that first draft as a starting point of discussion before you start trying to get help from the rest of the team. "A# is "ingle 9evel 7unless it changed in newer versions8 which mean that materials hierarchy is in the -. how many days will it ta!eE<. count that -. those present at the meetings. perts. lots of it. and this learning will put in )uestion the process. you can ad. the 9" . those doing tests. 44. • • • It involves many of people from different domains. 5ount everyoneJs time. but the average law will ma!e it a globally reasonable measure. .ust figuring how long it would ta!e to write some lines of rules. 2hile some high wor!load tas!s may be overestimated. it is the first one you will have to do. :o not hesitate to as! around. This is why you must consider. :ifferent people come up with their own set of rules.verall. 3or e ample. you are clueless. but there is always someone who can help you on a specific topic. In the above e ample.4 will ta!e double the time you originally estimated and $outing will most probably have to be done manually from scratch. There is much to learn while doing 4aterial 4aster. ma!ing the conversion rules mean U tal!ing about it with the consultants and 9egacy "ystem e pertsU 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. This is where splitting a pro. I' for $outings.ust to values that are more e act. Tust honestly evaluate each element independently from each other. . as you see. plain the wor! to evaluate. it is lot more than .ect in small elements will help. • • If there are two legacy systems. 3or some elements. Fowever. tas!s than originally thought so.4. So(e 2ointer% to fig're o't n'(*er% These are pointers to help you come up with the first draft. • • • I personally went through that process a few times. plain the average law I mentioned above and ma!e sure they do reGestimate all the elements with the same scrutiny. the average law is out the window. Fere are some suggestions I give to those concerned when reGevaluating a 2-" 0 • • .ect. etc. As mentioned earlier. ta!e +'' for 4aterial 4aster.

rightQ8 • • • #art of the data e isting aside in .. Fere are some factors on that will ma!e the process much longer0 • Fistorical data that was never purge • Inconstant data 7well.ther than the -ig 3ive. I established it by loo!ing bac! on previous pro. programming loading tool. I realized it was good enough to give me a first estimate in all cases. cel<. As I went on different pro. 44. I as!ed how many #erson1:ays it too! in average to do each of the -ig 3ive. than two 9" will ta!e &''' #erson1:ays. try having as little as possible of these.ects involving the modules 3I. . no one have these in their systems. in doubt.ect where you will discover. it will ta!e longer. It also needs modifications when the rules change 7and change they will8. this seems li!e the easiest way to go.or unplanned efforts. we came up with a formula to calculate a first estimate. you tend to thin! the second one will go faster than the first. I came up with it when I started doing data conversion. In all cases.ects. I say per legacy system and this is something important to consider.ust will not fit into "A# without ma.4 and $outings. At first glance. • • • all2arB fig're% Fere are some figures to give you a ballpar! of the pro. etc.ect in the 9egacy "ystem 7then it is probably messy8 • -e conservative. Fowever ta!e into account that programming means possible bugs. • . &' ''' inventory records and all other basic :5 stuff. /ever mind how much you investigate or !now the 9". add e tra time 7B' to &''( more8. writing rules. In pro. Then. it proved to be true. li!e <yes we can e tract most of it.ect to another. 2ell. handle this with care. which will need meetings. which again may bring bugs If you have part automatic and part manual. 2hen you e tract data automatically from the 9". If you have different legacy systems. it . This was the total time including meetings. This really needs to be used as a tool that will help on a first draft.ect. it gave me something between I'' to C'' #erson1:ays per legacy system. 4apping is different.or disagreement point among the team when you will show your numbers.ust happens every time. you can see why two 9" will be twice the energy. it should be faster. cel. Fowever. This will create collisions and conflicts. The time is however more predictable as manual data is rarely bugged. at the last minute. conversion rules are different and issues with 9" data will not be the same. over estimate rather than under estimate. Although almost impossible to avoid them.ects I wor!ed on. with the precious help of people who had first hand e periences doing :5. as they vary from one pro. The !ey is then the )uality of the 9egacy "ystem data. It is not bad luc!. *ou need to challenge these numbers and use . A for('la to hel2 F) Handle 3ith &are Fere is a formula for the -ig 3ive. This will probably be a ma. If one ta!e B'' #erson1:ays. wor!load estimates are rarely lin!ed to the number of fields. these will be real headaches. -ad luc! is when you did not consider it in your planning. There is absolutely no gain. "ince these three items represent the bul! of the :5 process. prefer ma imum usage of conversion rules. There is always one business ob. ## and ":.ach system must be evaluated as if it was a different pro. Deep in mind that for all the pro. updating data manually. If the data is not e tracted from the 9" but generated manually. These are not absolute figures. • 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. about + ''' vendors1customers.ustments in . but need to do some ad. Access or other non formal system Information spread into different systems /o clear owner or manager of a business ob. itPs notQ Trust me. discussions and testing before the issues are solved. 5. that it .ects I wor!ed on. having from +' ''' to I' ''' material master items with all related -.Data Migration Methodology for SAP PAGE #1 4aster.ects.

4 and $outing. but getting &''( of the data in "A# will prove to be a challenge. 9ive H and after. This formula is most pertinent for 4aterial.4 will ta!e double the time you originally estimated and $outing will most probably have to be done manually from scratch. it will be even more challenging.. I use a percentage in the 2-" so that I can recalculate all the wor!load easily as I learn more about the 9".ect. multilevel8. try finding someone who went through it before. which is also special. nothing ta!es less than &' days.'''I&C8. If the data are in bad shape in the 9". -adly managed it will !eep you up +Ihrs1day for a few days before A. you can use the formula and then add between B'( to &''(. If you really count all the time spent on one business ob. If you have a doubt. It is the comple ity of the process. -ase this on the number of fields you will populate in "A#.ust mentioned.udgment and apply between &' to %' #erson1:ays per business ob.& day per field8 :ata and $ules Adaptation 0 5ount &+ seconds 7V'.. you need to establish how many fields need :ata and $ules Adaptation. later on. In this situation. 3or -. if you plan to shoot less than &''(. =se you . There is more.udgment to ad. .ach time someone tells you <this is a one day thing<. it will be a challenge. it will be a great challenge.4 and $outing are merged in a single structure in your 9" 7i. once you system has been stable for a while in production. depending on the legacy data comple ity. go bac! to page & of this document. which needs to be ta!en into consideration. If you do not have 24 in your 9" and want to use 24 in "A#. 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. consider converting without 24 and implementing it later. If you use 24 in your 9" and it is not wor!ing perfectly. . As stated earlier. I usually count that about ?'( of the fields are solved by conversion rules and +'( will need data and rules adaptation.'+ day per field8 and add & day to the total for set up and e planations 5onversion rules 0 5ount &' rules per day 7'. the time is less dependent on the number of fields than on the comple ity of the data to e tract.ect according to e pected comple ity. count %' days for I4 R up to &'' days for 24 according to the three possible scenarios I . e plaining what is O:ata and rules adaptationP. Another business ob. • • • If you have a good wor!ing 24 in your 9". none will ta!e less than &' #erson1:ays. 3or those two.e. if -. :one right the inventory load ta!es lots of wor! but the process will go well. . the number of fields has little to do. 3or Inventory. count that -.ect. 5ustomer and 6endor masters.'''I&C day8 per record and by field 7number of fields records '. If you use 24 in "A#.ust the values. number of As you see. go toward >'(G%'(.Data Migration Methodology for SAP your . you can calculate as follow 0 • • • 3or mapping 0 5ount &' min per field 7'. PAGE ## -ase on the volume data from your 2-". is inventory. At first it loo! simple enough.ther than the -ig 3ive. than you are in for a hec! of a ride.

. and this will be on top of their normal conversion wor!. :o not under estimate this fact in your planning. overlapping of dependant tas!s. *our !ey users will be strongly solicited right from the beginning of the pro. the more they will be solicited to troubleshoot problems.ect is going on. this is the calendar planning.ect. To do the calendar planning. . using 4"G#ro. The result is that their availability will only get lower as the pro.ects. and delay due to non wor!ing time and bottlenec!s.nce you will be done with the :5 calendar planning. but it will also permit a )uic! identification of resource overGallocation.n most conversion. This tas! is most difficult. time consuming and very frustrating 7especially if you do not master 4"G#ro. the overload on !ey user is always a ma. This will not only give you a calendar date planning based on an ob.) CALENDAR PLANNING O/er/ie3 At this point.ect planning and do a resources load analyses. 2. 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. you must integrate it in the overall pro.ect or other planning tool.Data Migration Methodology for SAP PAGE #. Deep in mind that the more you go on with your pro. !alendar 2lanning %a(2le .ect8.ective wor!load estimate. *ou must now transform this information in duration for each tas!.or problem. you have assigned resources in the :ata 5onversion #lan and estimated the charge for each of the 2-" elements in #erson1:ays.

< Fere is the part where this statement ta!es most of its sense. It will be a much less frustrating e perience.ect. If you get into this. 3or e ample. -elieve me. generate great theories and totally ignore the overall picture and possible side effects on the overall planning caused by any change on some tas!s. 4any peoples will challenge your calendar planning. The resources allocation is to all !ey users at +'( 7ta!e into account only lead !ey users for each domain. faster. And remember.ect before you get into it. all tas!s are entered with the 2-" value “at best”. are you sure E< Fere we go again. This will be a !ey element of you planning. "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. is to never put tas! in parallel within a business ob. count only +'( of their time available. 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. This gives you an average of the time they will be able to give you throughout the entire pro. perience has proved that the best way to get an accurate calendar planning for the :5 process. • • • • • 4y calendar planning end on April %'th I had +'' days buffer in my 2-" I have B !ey users At the very end of the calendar planning. *ouJll see that getting this much attention from !ey users will be )uite a challenge when you get towards that bottlenec!. easier and all in parallel. if you ta!e +'( of the !ey userPs time for :5. which gives you the re)uired wor!load “at best”. we should be able to do them in parallel.ect. To get the most probable end. the same phenomena as in the 2-" will occur. <+'(.ect must ta!e into account that the key users are available at only 80( for them. whoever is planning other wor! on the pro. As in 2-". . Are yo' %'re <That long.ect. Se?'en&ing the ta%B% 2hen I se)uence the tas! within one business ob. 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. they will focus only on some big tas!s.Data Migration Methodology for SAP MS"Pro1e&t or not) PAGE #6 4ost probably. Fowever to do this realistically you would need to consider the effort on each tas! to be nonGlinear. I never overlap two tas!s. In the calendar planning. it also has great talent in Jauto messingGupJ your schedules 7ma!e bac!up copies H and ma!e them often8. but overall it will be +'(. which stated <It ta!es the time that is needed. I will add a +'' days tas! with B resources. not support consultants8. *es. your planning will ta!e forever H if ever you finish it. *es. remember that bottlenec! we mentioned before. $emember the part in the first section of this document. while !eeping it simple enough. /ow I have the most probable end date. the only planning tool youJll have available will be 4"G#ro. "ometime it will be less. End Hat *e%tH 7S H(o%t 2ro*a*leH In the 2-" you estimated all the tas!s as honestly as possible. 4y first advice is that you should learn the basics of 4"G#ro. .ect. it is very difficult to do better than the most probable date. This will translate as a +' days duration buffer for the lead !ey users. They would whish all could be done )uic!er. The end date will then be the <at best<. sometime it will be more. which gives you the “most probable” effort. since the process between test and rules and loading is iterative. that is only one day a wee!Q<. Although it is a nice tool. Then you added +' to +B( buffer.

ect duration. G If you need to finish a tas! faster. This is a very difficult and frustrating step. At this point youJll only have to identify slippage as the pro. -A5D=# copies before ma!ing changes in the calendar planning.ective values you can get.ect go and ta!e corrective action before it has an impact on the pro. .nce the planning is done and resources wor!load is realistic. you are ready to go. now you have to identify the resources overload and play with the tas! se)uencing until all resources are in normal wor!load.Data Migration Methodology for SAP PAGE #: G :o not parallel the tas! hoping to save time. never change an end date or the wor!load. In addition. G :o not forget the +'G+B( margin G :o not change the #erson1:ays established in the 2-". 5hanges the resources allocations to obtain the timeframe you want H then reGvalidate the resources wor!load.ect will regularly mess things for you. since 4"G#ro. 4AD. . There are only +Ihrs in a day and people need sleep. it is the most ob. .orBload analy%i% Fere you are.

CONVERTING A BUSINESS OB*ECT .Data Migration Methodology for SAP PAGE #8 SECTION 3 .

Data Migration Methodology for SAP PAGE #= :ata #urging L 5leansing #ro. tract and 9oad #rograms 9oad =nit Testing :ata and $ules adaptation .ect !ic!Goff 4apping L 5onversion $ules . tract L 9oad M 3ull "ize Testing and :ata 6alidation Acceptance "ystem full load #re #roduction "ystem full load #re #roduction "ystem "ignoff #roduction 9oad L "ignoff .

b. Do&'(entation of yo'r 3orB D&on/er%ion %2e&) and (a22ing %heetE Deep in mind that "A# is a highly integrated system.ach person who is responsible of a -usiness . This will permit a better circulation of information between domains and awareness of other modules decisions. 5reate ob. I !now. also delete unused materials.2 DATA PURGING AND CLEANSING The purging and cleansing of the 9egacy "ystem will save you lot of time and effort in the following steps of the conversion. 3or e ample. • 3ields "pecific rules . which will ma!e it so efficient. which is not always obvious. read the on line documentation. .or steps involve for each -usiness . all rules and mapping must be documented in clear format to permit cross reading and validation among the whole functional team.ect.ect will contain the :ata conversion rules 7or specification8. understand the re)uirements.ect.ect. 4aster :ata has direct and indirect impacts on all process. 3rom which 9egacy system7s8 are we e tracting the data and how. *ou will )uic!ly find that "A# will not let you load any address fields unless you get them clean. Aet familiar with your "A# -usiness . efore yo' *egin) 2hen wor!ing on the conversion. 3or e ample. you may delete all oneGtime customers or those for which there where no transaction in the last two years. but it really does wor!. • Data P'rging -efore transferring data from your legacy system.Data Migration Methodology for SAP PAGE #> 3. which include 0 • 9egacy sources and e traction procedures. Although a structured documentation process might ta!e a bit longer at first. there are often lots of inconsistencies in 5ustomer and 6endor address fields. it will permit to have a synergy that will eventually ma!e the whole bigger than the sum of the parts. The second main ingredient of the methodology. go through your complete process. computing or other. Then you can see what can be recuperated from your 9egacy "ystem. In the previous section we saw one of the methodology main ingredients. do not try to fit your 9egacy "ystem into "A#.3 +APPING AND CONVERSION RULES The documentation of each business ob. It involved mainly planning and is actually a basic management concept. • • #urging and cleansing rules 2hat are the cleaning steps to be ta!en and e traction filters to be used. 3.b.ect should read this. 3or this reason. :ocument here specific steps that need to be ta!en.b. it sound li!e a theory from a big boo!.ects. 3. 5onverting into "A# while having in mind your 9egacy "ystem process will for sure lead you into the wrong path. Aeneral 5onversion rules Auidelines to apply or rules that is used by many fields 7thus avoiding to retype it and ma!ing updating easier as it is only in one place8. Thin! "A# and understand it. • Data !lean%ing This process corrects data inconsistencies and ensures the integrity of the e isting data during the migration process. This can be done without specific !nowledge of "A#. which is applicable to any !ind of pro. This will ma!e the conversion easier.1 OVERVIEW This section gives you information on the ma. is the way we deal with the conversion process itself. delete all the old and obsolete data. "tart this as soon as possible and do as much as possible.

some fields e ist in different views in "A# master data.rganization 7you find this by loo!ing at the tables !eys8. Aetting rules. ample0 In 4aterial 4aster. permit the following 0 • • • • • Dey user must understand "A# fields usage Dey user are as! to )uestion their 9egacy "ystem values and integrity $ules permit a clear statement of what a !ey user thin!. so it is the same field.G3I. • "hort and clear $ules should be short. 5ommunication between functional and technical people is facilitated by using a common ground language.1. using I31.$ will most probably be wrongly interpreted. As well they may start using the same name for different fields.9".9: name is the same. . In the payment view. Therefore.9: of each view you get 0 4$#+ 0 4A$5G4T63# "ales Aen 0 4A$5G4T63# In both cases the TA-9.G3I.9: information. .G3I.n top of this.ect go. . In 5ustomer 4aster.$4 0 D/-&G NT.9:. 5hun! of te t is difficult to read. the field is lin!ed to the 5ompany 5ode while for the -illing view it is lin!ed to the "ales . different people will start using different names for the same field. A long sentence embedding many A/: L . ma!ing it easy to read./: structure as much as possible. the field < Terms of #aymentJ e ist in <#ayment Transactions< and <-illing< views. . rather than getting raw data in . 3ield rules are those that give a value for a specific field. it is necessary to give some e ample and to e plain some basic !ey element in rules writing. *ou will )uic!ly realize that as the pro.$ and 7 8 is clear. If you loo! at the TA-9. PAGE #@ A*o't the r'le% Aetting the conversion rules to be written is a !ey element of this methodology.$4 It is not the same field. R 3I. The best way to !now which case apply is to have the TA-9. the field WAvailability chec!X e ists in the <4$#+< and the <"ales Aen< views. -asic properties of a rule 0 • Aeneral rules 6" 3ield $ules Aeneral rules are the one that does not yield directly to a field value. "o both of these fields can have different values. :o not hesitate to spread the rule on many lines.Data Migration Methodology for SAP 2hich "A# fields to use and how do we get the final value for each "A# field. A92A*" refer to a field in the form TA-9. 2hen discussing or writing notes.G3I. cel.9: of each view you get 0 #ayment Transactions -illing 6iews 0 D/66G NT. Thus permitting to identify conflict and misunderstanding between domains. ma!ing change management easier as the pro. 3or e ample the way in which we differentiate the material types in the 9egacy "ystem is such a rule. *ouJll have to !eep in mind that these will be made by !ey users who may not be familiar with writing computing rules. "ometime it is the same field that is shown at two places while other times it is really two different fields. 4a!e certain that the use of A/:. $ules document can be versioned. If you loo! at the TA-9.ect is progressing. • 3ields names This is a crucial one.

it is impossible to group items or to get values by rules. 6alues must be entered manually.A This is not clear enough. Fow do we !now which product are <sold semiGfinished<./ #urchasing Aroup is -lan! . 9ocate -=*. ample of a rule referring to an au iliary table0 I3 -=*. 4aterial 4aster is a !ey to all domains and a lot of fields need to be discovered and understood.Data Migration Methodology for SAP • 4ust be clear and without ambiguities 3or e ample 0 If product is a sold semiGfinished H.$G5. in #urchasing group table to find #urchasing group .9". This must be clearly stated in the rule or be part of a general rule. on legacy is blan! TF. at the same time.:. This is the most comple -usiness .:.$G5./: A %2e&ial &a%e for Material Ma%ter 4aterial 4aster involves all the domains and may re)uire anywhere form +' fields to a few hundreds depending on the comple ity of your implementation. • =sage of discrete values in au iliary file In some case.nd PAGE . In this situation you must enter these values in a separate file 7usually . . cel8 using a search !ey 7li!e the item number8 and specify in the rule to use the au iliary file. "ome fields will be used by different domains while others will be used by only one domain but its value will have an impact on functionality used by another domain.ect to document and. it is the one you must start with in you conversion process.b. all tables must be specified li!e the following 0 . To get that understanding from !ey users we proceed as follow 0 . In the rules document.

4A##I/A :. and wor! on understanding what material master is. Fere are some 7theoretical8 e amples of mapping from 44. proceed as follow0 "ee with all implicated domains who is the lead for the field and decide in which view the field should be included. T="T A. . To solve this. they must enter their domain type in the list. the same field canPt be in different views. 3or e ample. ## and ": EIa(2le of field% %ele&tion *y ea&h do(ain . 2hen doing the rules and the load program. the field “Aoods receipt processing time in days 74A$5G2. Suality management. 4$#+. The goal here is to see all the fields that are important and as! )uestions to understand them./.hat to do 3hen the %a(e field i% fo'nd in different /ie3% In 4aterial 4aster. At this point we are not interested about where the values will come from and how will we get them.1 Aet each domain with their consultants to go through the mapping file and loo! at the fields for each material type. This is done separately by each domain and documented in different mapping files. .T TF.Data Migration Methodology for SAP &st step 0 "election of the fields by each domain PAGE .ach time a domain select a field for a specific material type. some fields can be entered 1 modified in different views.-AN8” e ists in views #urchasing.

it can be decided among the domains to put it in the #urchasing view 7and nowhere else8. . 4$#&. wor!scheduling.rganization 7you find this by loo!ing at the tables !eys8.$4 It is not the same field. +nd step 0 $egroup selection of all domains . put the name of all the domains who selected the field. but do not stop other domains to use it of have specific rules for it. than you 7the :5 manager 8 have to put together all the results.S In can however happen that no specific domain can be identified as the lead or main user of a field. It is however #urchasing role to ma!e sure this field is used correctly.-AN8”. )uality management. -e careful. then we put it in a dummy view called “"#.# Ta!ing the e ample of the field “Aoods receipt processing time in days 74A$5G2. In the payment view.nce this is done for each domain. "pecify for each field.9: of each view you get 0 #ayment Transactions -illing 6iews 0 D/66G NT. the field < Terms of #aymentJ e ist in <#ayment Transactions< and <-illing< views. This is used to put all the fields that e ist in different views and for which we canPt assign a lead functional. This would yield something that loo!s li!e this 0 EIa(2le of field% %ele&tion gro'2ed for all do(ain% %rd step 0 -uild the data conversion rules template with all the selected fields. “44 1 ## status 74A$5G44"TA8” which is in views 0 purchasing. ma!e sure it is really the same field. SPE!IAL M$LTI 7IE. 9etPs ta!e for e ample. "o both of these fields can have different values.$4 0 D/-&G NT. the field is lin!ed to the 5ompany 5ode while for the -illing view it is lin!ed to the "ales . If you loo! at the TA-9. costing &. which domain selected it.Data Migration Methodology for SAP PAGE .5IA9 multi views”. This means that #urchasing is the lead on this. If more than one domain selected the same one. 3or e ample0 In 5ustomer 4aster.G3I. If no one can be clearly identified as the lead for that field.

. 3ailure to understand this is will get you into trouble. Bth step 0 4erge the rules from all domains. I usually endGup with an average of + )uestions per field. It is a simple 2ord document where I put all the )uestions. This happens when more than one domain use the same field and they come up with contradictory or incompatible rules./" 9I"T becomes the data conversion T.ust the :ata 4igration part of it. 4ost of these will be )uic!ly dealt with. This is purposely done independently for each domain so that misunderstanding or conflicting rules between domains may be put in evidence in the ne t step. that is C'' )uestions. I usually create what I call the S=. #repare yourself for a very long list at first. not . the name of who is responsible for the solution. Anything that is promised. 4a!e a single document that contains all the functional domainJs rules and note. target date 7with history if the target is changed8. for each one. As the pro.:. if you have %'' fields. Therefore./" 9I"T. due. Cth step 0 Analyses of the results and creation of the Issue list. they are unclear rules or obvious problems that get solved within the first wee!.ne interesting thing that usually happens here is rules conflict. scheduled or to be given must be noted there. you will have C'' )uestions per 9egacy "ystem. H That is &?'' )uestions.ust identified important issues between domains before you developed anything."TI. . 3inding this at the beginning of the process will be a great time saver. . which domain wrote it."TI. independently As! each domain to specify the conversion rules for all the fields they are concerned with. 9I"T.ect goes.Data Migration Methodology for SAP PAGE . the S=. . Data &on/er%ion r'le% te(2late %a(2le Ith step 0 Aet the rules from each domain. and this is true for all the "A# implementation process. And if you happen to merge % 9egacy "ystems into one "A#.ne of the main challenges of implementing "A# is integration of the different functional domains into a single product. as you . creation date. At this point.

.Data Migration Methodology for SAP PAGE . Material Ma%ter &on/er%ion r'le% %a(2le All other *'%ine%% o*1e&t% 3or the other -. Fere are some samples of -.6 *ou now have 4aterial 4aster conversion rules documented and a T. because they are simpler than 4aterial 4aster and involve fewer people. in a second step. 9I"T to follow up on the issues to be solved before you can load the data. start wor!ing on the rules. It is in this document that we will both. decide which fields we need and.:. we will start directly with the 5onversion rules document.. conversion rules.

Data Migration Methodology for SAP PAGE .: OM &on/er%ion r'le% %a(2le O2en A&&o'nt Re&ei/a*le &on/er%ion r'le% %a(2le .

Data Migration Methodology for SAP PAGE . #artial #4THHH.$$.$$.” /on A1$ cash0 “/on A$” Ad.#9 G 5hart of account 0 5A'' -=D$" M 5ompany code0 ''>' A"-.” Any other type is an error.59 "D#.” 5redit 4emo0 “5r 4.” :ebit 4emo0 “:r 4. if not .$ :ebit 4emoHHH. if not . .” Invoice 0 “Inv.33".$.ustments0 “Ad.#$I"..$ Any other type is an . field in #$4" 0 #artial #4T0 “#ay.must be positive in #$4". if not .T M Account 7+8 0 $.$$ M "!ip err 0 K A''+ A''% .$$.$ 5redit 4emoHHHmust be negative in #$4". must be negative in #$4".$ G -usiness Area 0 ''I' -=:AT M #osting :ate 0 “'BG%&G'+” or last day of last closed period.$$. if not . 9"4 9oad parameters DT.8 7endor Ma%ter &on/er%ion r'le% %a(2le EIa(2le of general r'le% ID A''' A''& R$LE /ote that "A# term “"ecurity deposit” e)ual “$etention” in #$4" Type of transaction T*#.$$.$ InvoiceHHHHH.must be positive in #$4". 6alidation to apply both at e traction and load.

To store the different files on your local server. freeze the version.doc \ \ \ ^ Deep here only the latest version of each document _ \ \ \ \ \ Z[[[[[ .ne way to stay on top of things while having e tra )uic! reaction time is good document management. Fere is an e ample.ld \ \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ \ \ ][[[[[ 2or!ing 3iles \ \ ^ #ut here various wor!ing files _ \ \ \ Z[[[ G-. 50Y. Z[ :ata 5onversion \ \ \ Z[[[ '' G .D 7functional and technical staff8. so no one changes it afterwards • 4a!e a copy of 6'& as 6'+ • In 6'+. \ \ \ \ \ ][[[[[ . activate 4"G2ord change trac!ing • #ut 6'& in the <. G :ata 5onversion "pec.b.doc 3reezing version 6'& • . you will end up with lots of documents and versions. This is a certitude.= Dire&tory organiCation As you go. there is a real danger to loose control here.:=9. Fere how it goes 0 • • 5reation of the first version rules 6'&.rganization \ \ \ :5 #9A/ \ \ \ :5 2-" \ \ \ :5 "5F. 9ive. name \ \ \ -.ect to store all the files relevant to the data conversion. 5onsidering the stress on the whole pro.Data Migration Methodology for SAP PAGE . As you get closer to Ao 9ive.ect team and the overall load on all members near A. which will permit a good change management. changes will get more fre)uent. Although it may sometime feel frustrating to go through versioning for !ey users.ect goes.ld \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ Z[[[ '& G 4aterial 4aster \ \ \ 4aterial 4aster G 3ield "election "heet. they will occur faster and will re)uire a )uic!er reaction time.doc \ \ \ ^ Deep here only the latest version of each document _ \ \ \ \ \ Z[[[[[ .ld< directory • =nprotect 6'+ 7This is where we start the new version8 . • #assword protect 6'&. ls \ \ \ 4aterial 4aster G :ata 5onversion "pec. .ld \ \ \ ^ "tore here previous versions of above mentioned documents _ \ \ \ \ \ ][[[[[ 2or!ing 3iles \ \ ^ #ut here various wor!ing files _ 7er%ion (anage(ent of &on/er%ion r'le% As the pro.nce everyone agree that 6'& is . use a specific directory structure. I suggest having a structure with a directory for each -usiness . rules will change. it will ultimately be the best way to go fast without brea!ing something else that already wor!s 7regression8.

/.nce the e traction is clear. so no one changes it afterwards • 4a!e a copy of the document as 6'% • In 6'%. if there is ambiguity or incomplete information in the specs.$ The rules documents for each -. "o save often and ma!e bac!ups of all your :ata 5onversion documents. This is mostly true with large documents. .ffice bad behavior as well as networ! failure H and human error. • Any change re)uired by functional team must be done in 6'%. • Any change re)uired by functional team must be done in 6'+. This all happens because of a certain 4urphyJs and there is no way around it. 2e are at the start of the process and any error or omission at this point will affect us for the rest of the pro. using change trac!ing. accept all changes so that there is no visible change. :. at least a few of them will go totally corrupted during the pro. 6'+ • .T 5FA/A.nce this is all documented. activate 4"G2ord change trac!ing 7should already be on8 • #ut 6'+ in the <. load it and as! functional team to validate. These are nice tools but they regularly go wild and scrap your document. what to e tract and how to proceed.ect. *. load it and as! functional team to validate. cel.ffice documents.$. • All correction has to be entered in 6'+./. It also always happens that someone messGup a document.nce 6'& is programmed. we must loo! at the load programs and process.nce 6'+ is programmed.) E. It is essential that this be clearly documented and validated by the !ey user responsible for the -.D 7functional and technical staff8." between 6'& and 6'+ are visible through 4"G2ord change trac!ing.ect. M'r2hyH% 2rote&tion 0 Sa/e it often F and get good *a&B'2%) *ou will be wor!ing with 4"G2ord. ta!e your time to solve the issues you can see on paper before you do any programming. have sections for “9egacy sources and e traction procedures” and “#urging and cleansing rules”. This should e plain what to clean1purge. . and . you can start wor! on the e traction programs and process. 3. • #assword protect 6'+.Data Migration Methodology for SAP • :evelopment and testing of 6'& • As! the technical team to wor! on 6'& and only on 6'&. This implicates all the aspects of loading the re)uired fields into each -.%r!'% !#" Lo!" Pro-r!. freeze the version. At this point..> • • • If you are not familiar with 4"G2ord change trac!ing I strongly suggest that you get ac)uainted with this functionality.T 5FA/A. as for e traction.:. validated and understood. :.5. A/* #$.ld< directory • =nprotect 6'% :evelopment and testing of 6'+ • As! the technical team to wor! on 6'+ and only on 6'+ • A99 5FA/A. . 6'& • .3. :. /. Again. :. If it does not.T #$.. /.= :. -e certain of two things 0 • • If you have many large 4"G. IT 4="T -. It always happens. usually the most critical one. -. • In 6'%. • All correction has to be entered in 6'%.nce everyone agree that 6'+ is . And so on H PAGE . 3reezing of 6'+ • . ..A$A44I/A. I usually !eep a > days rolling bac!up of all my files somewhere on a local #5 to protect me from 4"G.

3or all the "ystems 4igrations I did. when you do not begin any programming until all e tract and load rules are &''( clear 7and I mean &''(8. it must be documented and validated in the specs so that it is clear and unambiguous to all. PAGE . I. it does not e ist. If you found issues at this point.3. 3irst.$. there is a tendency to thin! that you . 3ollowing the modifications.$. you need to redo the unit testing of the load. Fave the discipline to manage change by versioning the documents and ma!ing sure they are crossGvalidated by all implicated sta!eholder. you correct any program. Trying to save time a team starts wor!ing on new solutions without ta!ing time to document. you correct any program. /ot so. for their maintenance and for the end result.D. you need to redo the unit testing of the load and redo a full size test cycle.@ 4ost of the time. . *ou must address them and document in the specs whatever corrective actions are needed.3./ D!%! !#" R&0 $ !"!1%!%2o# This is. you do the e tract and load programs "ome )uestions or issues will arise. it is the one at which you get out of it. The -usiness . It is better to ta!e your time to do it correctly rather than rushing it. The specs must always be updated to reflect the new situation -. you correct any programs. 3ollowing the modifications. where "ystem 4igration 4anagers can loose control of the conversion process. which usually means you may have to slow down at some points. %. The tech team is there to develop programs according to what the rule says.ect Dey user is the one accountable for the rules 7all of them8 relating to his1her -. Ta!e the time to do it right now and you will eventually pic!Gup an impressive speed in the ne t steps. This is time consuming and can be very frustrating if not properly managed. these iterations accounted for a ma. *ou must address them and document in the specs whatever corrective actions are needed. I got it”. This is also the most difficult. get it documented. here are the guidelines most useful at this point 0 &.ust will be more difficult and time consuming to do it after the programming is done than now.$. C.3. Deep in mind that a change from one domain can affect others and they will find this only later in the process. cross read and validate the specs. In a nutshell. “. The specs must always be updated to reflect the new re)uirements -. They sure are getting output )uic!ly this wayH but are they going in the right direction E +. The migration process is an iterative one.$. B.Data Migration Methodology for SAP This will prove to be an enormous time saver later on. After you have the specs. by far.. "o if you do not see what you need. when something needs a change. It . :o unit testing of the load "ome )uestions or issues will arise. *ou must be thin!ing. it means that there will be errors in the process and you will have to address these issues anyway. once everyone forgot about what was e actly changed. If it is not in the rules. This is not the technician part of the wor!.ects that failed. the most time consuming part of the conversion process. As problems can accumulate in a snowball effect. so does success 7and this is a good news8.ust ma!e everyone loose time.3. The specs must always be updated to reflect the new re)uirements -. $emember this throughout the whole process0 As in car racing. I do so because this is the most common error I saw on pro. you correct any program. 3ull size test cycle "ome )uestions or issues will arise. but you will eventually progress faster and faster. stop repeating the same thing again and again. 3. The specs must always be updated to reflect the new re)uirements -. it is not the speed at which you enter a turn that is most important.b.or part of the :5 process duration. $esults will initially be slower to come. *ou must address them and document in the specs whatever corrective actions are needed.

ect must validate the data. 3ollowing the issues youPll find here.Data Migration Methodology for SAP >. "A# did not behave as you e pected 7it sometimes behave very differently with a load tool than it does with manual data entry8 As mentioned earlier. This is time consuming and must be done as soon as possible. it can ta!e up to a year to correct this. 3ailure to do so 7i. 7&00 Lo!" -efore going into preGproduction. the conversion process is iterative. you must redo a full e tractGloadGvalidation cycle for the -. if you change something. it is difficult to correct them in pre prod 7and suicidal8. following the issues you will find here. the functional that is responsible for the business ob. $emember the bottlenec! with !ey user I mentioned earlier in the planning section. +. The !ind of issues you usually encounters at this point loo!s li!e the following 0 • "ome mandatory fields are missing • "ome dependency between + fields in one view where not considered and you canPt load as e pected • Invalid values where given to you in the rules • . find solutions and document them in the specs 7this is the responsibility of the !ey user8. This is done it two steps0 &. I . of course.ect.%r!'% 5 Lo!" 6 7&00 S28 T $%2#.9 A'' 1%!#' S:$% . 9oad data that comes from the full e traction process 7starting with small size and progressing with larger data set. 2hile you can correct bugs in dev. 3. PAGE 6A If you start running in all directions and canPt !eep you head out the water. 2e are more concerned about going through the load cycle without "A# stopping us. load &''( of the data. we want to !now if we can load the data with the processes we developed 7e traction and load8.e. 3. rather than validating the correctness of the values. 3inally. you will have to go bac! to the functional !ey user. you will have to go bac! to the functional !ey user. tract and 9oad cycle. as well as validating the results of the conversion in "A#. If at the end you load in production and create data inconsistencies. 3rom this point on. affected. and go bac! to step &.. The goal is to see if we can load all the fields for all the data types without error. At the end of this step. The goal is to achieve &''( of loaded data After each load. Again. the more you seems to brea! everything around it. 3. 3or this we use a very small volume of data. up to B'( of the complete data to be converted8 9oad a full size data set 7at least B'( of the complete data to be converted and progressing towards &''(8 using the full . usually creating data manually from scratch rather than using real e tracted data. find solutions and document them in the specs 7this is the responsibility of the !ey user8.#. and have full data validation from the -. the less availability youPll get from the !ey user responsible of the -. you must be able to start from an empty "A# client. "T.3 Lo!" U#2% T $%2#Fere we want to test the load programs at a unitary level. we will have a fully functioning and validated conversion cycle. to achieve this you will need lots of discipline.!#" D!%! V!02"!%2o# At this point.wners. -ecause the production system is living its own life and canPt be controlled as in dev. correcting 4aster :ata errors is li!e shooting a moving target H the more you try to fi it.Ps !ey users and the -.Ps . the farther you are in the pro. e tract. ma!ing last minute changes and not validating them full size8 will @@( of the time creates bugs in the load process at production time.rrors in the load programs • =sing a load program.4 E.

at one point we need three clients organized li!e this 0 &. "ince -. wor!ing on costing %. This way you do not induce regression into the e tract1load process. you managed to load &''( accurate 4aster :ata and no rewor! is needed 7yes. the following will happen0 • ## will be ma!ing corrections to -. one situation !ept showing up about the clients re)uirements.b. adapt the programs and load the data to validate the results. and you cannot do this without affecting another team that is proceeding at a different pace in their 6alidationG5orrection process. This is where it gets tric!y. A 5lient for ## wor!ing on -.4 after a year. at some points. will be doing costing runs and are directly affected by -. they will the need to reload data at different intervals from each other.. you cannot load data in the -.wners Then you get written signoff from the -. Inventory. A 5lient for all the other -. this happened to me for real8 Fere are the guidelines to follow here.4 for ## without affecting the 3IG5.Data Migration Methodology for SAP PAGE 61 have seen teams cheating on this step and still have corrupted -. you do the final production load and get final signoff 3inally you have nothing else to do.Ps .1< S&-. 3.Ps been wor!ed on "ince it ta!es time and resources to setGup these clients.wners that all is AG. Again simple but re)uiring a lot of discipline 0 • • • • :o not change any e tract1load programs to correct errors found in reGprod.4 and $outing +.ect. you must again do a full preG prod load test1validation of everything. 3.D 7insist to have it written. as by following this methodology.4 affect #urchasing. .ust a formality.$%2o#$ o# %= D!%! Co#> r$2o# L!#"$'!1 As I did different 9egacy "ystem migrations into "A#. 3or e ample. better to !now it is coming and plan for it right at the beginning of the pro. 2hen it is time to load in prod. . It is better to ma!e manual corrections or create programs the correct the data after loading them. team in their costing validation. not verbal8 After. and then apply the manual changes or run the data correcting programs e actly as you did in pre prod. etc. do e actly as you did in pre prod.4 and $outing • 3IG5. Pr Pro"&'%2o# !#" Pro"&'%2o# Lo!" "ince you went through all the steps and followed all the methodology guidelines. this is . 4anufacturing. If you must change the anything in the load1e tract process or programs.nce you will be done with the first loads of 4aterial 4aster R -. you can imagine in which condition their "A# got after a while. A 5lient for 3IG5. we came up to the same conclusion.4 R $outing. starting from a copy of prod and doing everything e actly as you will do in prod *ou get the whole thing validated by the -.4 and $outing • The rest of the team will be ma!ing corrections to the other -usiness . 5osting. • • • • • *ou do a full load in preGprod.Ps !ey users and the -.ects $egularly.Ps . they will all need to change the e tract1load rules. In all cases.

. in different countries and with starting pro. This is how I managed to !eep my head above the water and continuously see where we are going. #ressure to show rapid results 7any results8. These are the most difficult challenges you will have to overcome in order to complete each step at &''( Although it may sometimes loo!s to others that you are ta!ing the long route to get there. . remember that the ob. The goal it is to complete the whole process in the best time possible and to deliver a complete set of 4aster :ata that will not need rewor! once in production. I successfully used this methodology in different industries. This will have a snowball effect. /ot following this rule will also have a snowball effect.ects as well as with pro.ach step is the foundation needed for the ne t step. The methodology itself is mainly a mi of good old common sense and management &'&. tendencies to push forward issues so we can !eep progressing. and resistance to slow down when the process starting to get out of hands.ective is not to finish a specific step A"A#. permitting you to gain more speed from step to step.ects already running which needed to be turned around. 5omplete each step at &''( and the ne t one will be easier. reaching a point where the conversion process becomes totally out of control. but in the other direction.Data Migration Methodology for SAP PAGE 6# CONCLUSION /ow you !now how I did different 4aster :ata migrations faster and better than others did. The difficulty is not in understanding the methodology. even when everyone else seems to be in crises.

Data Migration Methodology for SAP PAGE 6. APPENDI? 6 VARIOUS TE+PLATES .

doc PAGE 66 " . the structure of “4aterials 5lasses and 5haracteristics” Materials Classes and Characteristics str!ct!re.doc Ro!tin# conversion spec sample. . S te(2late WBS Template.Data Migration Methodology for SAP A " !on/er%ion 2lan te(2late Data Conversion Plan.doc E " Data &on/er%ion %2e&ifi&ation < OM 4 Ro'ting Te(2late Sa(2le% B"M conversion spec sample.doc F " Material% !la%%e% and !hara&teri%ti&% %tr'&t're I included this as it may be useful to understand.xls ! < Material Ma%ter " Field% %ele&tion %heet MAT MASTER Fields Selection Sheet SAP 4.xls D " Data &on/er%ion %2e&ifi&ation " Generi& te(2late Data Conversion r!les template.ppt . and e plain.