data migration methodology for sap

5/22/2018 Data Migration Methodology for SAP

1/

Data Migration Methodology for SAP PAGE 1

DATAMIGRATION

METHODOLOGY

FORSAPY!HRISTIANERGERON" [email protected]

If one can manage small decisions now, thelarge ones will gradually disappear or mightnever appear in the first place.

Anonymous


2/

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 legacysystem.

It describes a methodology for data migration I used successfully in different implementations. It is base upon my previouseperiences. There is no warranty on its content or on the results. This guide gives you suggestions. It is up to you to ta!ethe 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 fordifferent "A# versions. It is a base to help you build your own template. *ou can start from them, but do not ta!e forgranted 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 proect manager and the data conversion manager% "ection % is for the data conversion manager and the members of your team responsible of converting -usiness

bects, both technical and functional.


3/

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/e0 2hen referring to the -ig 3ive, it means 4aterial 4aster, 5ustomer 4aster, 6endor 4aster, -ill f4aterials 7-48 and $outings.

'%ine%% O*e&t%0 To help in the analysis and transfer process, the data are not treated as tables or field contentsbut rather as obects in term of business operational. These are called -usiness bects.

'%ine%% O*e&t D! re%2on%i*le0 $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 bect.

'%ine%% O*e&t O3ner0 The one that owns the information in the every day business. This is the person that willma!e the strategic choices on functional re)uirements for the business obect and that will do the final validationof the converted data. 5an be identified by finding The highest hierarchical person who will be directly andmostly affected if the business obect does not wor!

Data !on/er%ion 4 Data Migration 0 The data conversion process. :ata conversion and :ata 4igrationterms are used interchangeably in the document.

D! 0 Abbreviation for the data conversion process.

Do(ain0 3unctional domain within the proect, 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 betweenfields. It can be easily generated from ;cel or Access.

Inter(ediate file0 An ;cel, Access or other type of file, which is manually manipulated in a process betweenthe 9" etraction and the flat file generation.

LS0 Abbreviation for 9egacy "ystem

LSM or LSM,0 9egacy "ystem 4igration 2or!bench. It is a "A# tool for conversion that permits data loadingusing 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 fieldswhen one value is related to a parent field. 3or eample, the


4/


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 obect 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/ =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..............................................................................................................................................&&

&.% "=;"T;: A::ITI/A9 $;A:I/".................................................................................................&+

SE!TION # " ORGANI9E THE DATA !ON7ERSION)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))1.

+.& 6;$6I;2..................................................................................................................................................&B

+.+ :ATA 5/6;$"I/ #9A/.......................................................................................................................&B

-usiness bects....................................................................................................................................&B :ata type................................................................................................................................................&B Information to complete in the conversion plan....................................................................................&C 4ain -usiness bects 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.................................................................................................+&

+. 5A9;/:A$ #9A//I/............................................................................................................................+%

verview............................................................................................................................................... .+% 4"G#roect or not...................................................................................................................................+ "e)uencing the tas!s..............................................................................................................................+ Dey users and consultant availability to wor! on 4aster :ata..............................................................+ ;nd Jat bestJ 6" Jmost probableJ.............................................................................................................+


5/

Data Migration Methodology for SAP PAGE :

Are you sure E........................................................................................................................................+ 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 #=$I/ A/: 59;A/"I/.........................................................................................................+?

%.% 4A##I/ A/: 5/6;$"I/ $=9;"....................................................................................................+?

About the rules.......................................................................................................................................+ A special case for 4aterial 4aster.........................................................................................................%' All other business obects......................................................................................................................% :irectory organization...........................................................................................................................%> 6ersion management of conversion rules..............................................................................................%> 4urphyJs protection 0 "ave it often H and get good bac!ups............................................................... %?

%. ;KT$A5TA/:9A:#$$A4".................................................................................................................. .%?

%.B :ATAA/:$=9;"A:A#TATI/..................................................................................................................... .%

%.C 9A:=/ITT;"TI/..................................................................................................................................... .'

%.> ;KT$A5TL 9A:M 3=99"IN;T;"TI/A/::ATA6A9I:ATI/...............................................................'

%.? A55;#TA/5;"*"T;43=999A:................................................................................................................'

%. #$;#$:=5TI/A/:#$:=5TI/9A:.................................................................................................. .&

%.&' "=;"TI/"/TF;:ATA5/6;$"I/9A/:"5A#;................................................................................&

!ON!L$SION))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))) 6#

APPENDI5 < 7ARIO$S TEMPLATES))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))6.

A G 5onversion plan template................................................................................................................. - G 2-" template.................................................................................................................................. 5 M 4aterial 4aster G 3ields selection sheet.......................................................................................... : G :ata conversion specification G eneric template........................................................................... ; G :ata conversion specification M -4 L $outing Template "amples............................................. 3 G 4aterials 5lasses and 5haracteristics structure...............................................................................


6/


SECTION 1 - INTRODUCTION TO DATA CONVERSION


7/

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. Alot 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 goodmethodology. ne that will provide you with a realistic planning, a solid organization, a way to manage the process andcontrol 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 datamigration can amount up to about '( of the entire proect. #oor data conversion will ma!e your o 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 successfulimplantation.

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 Ifound the following recurring problems 0

2hile the proect 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 reected by "A#.

There is a lot of misunderstanding, friction and frustration between the functional and technical team.

At o 9ive

4aster data deadlines where constantly busted and production load is done in JJrush modeJ at the lastminute.

"ome !ey parts of the data cannot be loaded in production. #atches are applied to the master data in orderto forceGload.

"ome data ust will not get in at all, they will have to be entered after 9ive.

After o 9ive

"ome :ata need to be corrected L entered after o 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 acostly operation.

After discussing with people who lived these situation 7manager, functional and technical8, we identified the followingpoints 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 o 9ive, thisbecomes much worst.


8/4

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 forresults to show up. This is actually true of any concept. 4ost of concept failures are due to application of the techni)uewhile 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 timethat it re)uires to do thing properly and thoroughly. /o epediting, no bypassing of step, no piling of unsolved issue to !eepgoing.

$esults will initially be slower to come. Fowever, because you will get things right on the fist time, you will eventuallypic!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 theone 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, ofthe issues and problems you will encounter in the conversion process will be functional. Although the etract 1 load processitself will not be effortless, it is the part between the etract and the load that is the most difficult. etting 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 Theanswer is that everything is tied together. 4aster data is dependent of the customizing, the customizing is made accordinglyto the way you do your process, and master data is needed to run your process. If you change master data, it will mostprobably change the behavior of the process. If you change customizing, your master data may become incomplete orincorrect.

2hichever phases you are in the proect, data conversion always seem to be the one step that can be pushed a little bitforward in time when you run behind in the overall schedule. :oing this will put the conversion process too close to the endof the proect. In that situation, you will end up shoveling a ton of data into "A# at full speed with little control, if any, ondata )uality and coherence. $emember the old saying


9/4

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 noteist. "o any discussion, decision or answer must be documented in the rules. *ou will be surprised to see how thingschange between verbal decision, sometime made in the hallway between meetings, and written decision which re)uiredthin!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 beencross read and validated by all domains and the technical team, and only then, can you start the development of the etractand 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. etting a good planning and organization structureta!e about two wee!s for the first draft, which will leave you with some )uestions on proect organization. etting acomplete and final planning will ta!e at least one more wee!. Any unsolved issues on these will haunt you throughout theproect, 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 mostprobably be involved in other part of the proect. 3or this reason, the ris! of conflicting tas! is high and can )uic!ly lead toa bottlenec! where !ey peoples are overloaded. 3or this reason, you should consider the data conversion as a proect withinthe proect. This translates into the preparation of a complete conversion plan that will help you go through the process andwill permit to foresee and solve the conflicting resources usage before the bottlenec! ever occurs.

The methodology is based on a top down process. oing through this will permit to plan, organize, eecute and followGupyour conversion. As the proect is going, you will control the evolution of the data conversion process. ;ach step has itsown use. *ou may sometime feel li!e you are not going to the end by the shortest route. $emember, the goal is not to getfirst results faster, it is to finish the OwholeP process faster. This method is based on many proects eperience and will helpyou to avoid the pitfall usually associated with data conversion.

The main steps of the data conversion are0

rganization of the data conversion 7#roect manager L data conversion coordinator8 :ata conversion plan The 2-" with wor!load estimates The calendar planning with resources loading

oing on with the -usiness bects data conversion 7The resource responsible of the -usiness bect :58 :ata #urging and 5leansing 4apping and conversion rules ;tract and 9oad #rograms from rules :ata and $ules Adaptation 7adusting 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 bects 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 !eyusers, functional issues are solved by !ey users, training is prepared by !ey users, data conversion rules are done by !eyusers, data validation is done by !ey user, master data issues are solved by !ey users H. In addition, when you startvalidating 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 resourceswor!load planning to avoid !ey users being schedule ? hours of wor! per day.


10


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 proect ta!es timeand the best way to minimize it is to plan for it correctly. *ou will have no other choice than spreading the load throughoutthe entire proect.

5omplaisance planning will ust ma!e a long proect 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 anyinvestment 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 toresolve 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 createimportant 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


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 beimplementing. Then, according to the "A# process needs, establish what the 4aster :ata re)uirements are. Then, and onlythen, 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 inconsistenciesduring the conversion. :elete obsolete data and ma!e the rest of it coherent. These two steps are called data purging anddata cleansing.

This can be done without specific !nowledge of "A# and can begin way before the proect Dic! ff. It will save you a lotof 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 obects,finalize all customizations before the last test run. 5ustomizing changes after the final transfer may result in additionalre)uired fields, this re)uires preparing and transferring more data. It can also invalidate the loaded data, which leaves youwith an incoherent data set that will be very costly to correct after o 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 !eeplive 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 dataconversion more difficult because of the volume. Also, because data tend to be less accurate when they where created along 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 andtransactional data.

S(all i% *ea'tif'l

"tart small. The first time you transfer data, begin with a few records of a business obect. This way, you learn how theprogram wor!s. After transferring some records successfully, try transferring a larger amount of data. 4a!e sure that youtransfer 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 operationwhere 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 establishmentof 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. Thebac!up allows you to secure a specific level you have reached during the data conversion process. If you have anyproblems, you can return to this level, and you do not have to begin the process all over again.


12

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 roup web site

"ystem 9andscape 79andscapeGII.pdf8 fount on "ap9abs website

Suic! $eference uide 9"42 7Fow to H8 and #resentation of 9"42. 5an be found on web sitehttp011service.sap.com1lsmw It re)uire a user name a password


13

Data Migration Methodology for SAP PAGE 1.

SECTION 2 - ORGANIZE THE DATA CONVERSION


14


:ata 5onversion #lan

2-"

5alendar planning


15

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 andmust be completed right at the beginning of the proect. This part of the process is to be done by the proect manager andthe data conversion coordinator.

2.2 DATA CONVERSION PLAN

'%ine%% O*e&t%

A -usiness obect 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 obects 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 accountingdocuments, 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 referencepurposes. ;amples include closed purchase orders, closed sales orders, summary general ledger information, and soon.

Data &on/er%ion 2lan %a(2le


16


Infor(ation to &o(2lete in the &on/er%ion 2lan

,hat 2hich business obects 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 inected 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, youmay 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 obects that will be transferred. ne person does not have to !nowall of this, but the people who !now this information should wor! closely together.

,ho 2ho is involve on each -usiness bect 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 bect 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 )uestionsis no easy tas!. Ta!e the time and energy it needs to answer these )uestions meticulously. It will avoid alot of turning in circle and save you lot of time throughout the proect.

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.


17

Data Migration Methodology for SAP PAGE 1=

Main '%ine%% O*e&t% %e?'en&e of &on/er%ion

G 9 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 records5ondition 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


18/

Data Migration Methodology for SAP PAGE 1>

2.3 WBS ( work br!k"ow# $%r&'%&r

,hy a ,S -

;stimates for a proect planning must be deducted and ustified from a logical process. They represent the real wor!loadre)uired for the different tas!s of the proect. The 2-" is a great tool to figure out these numbers. It will permit to estimatethe wor!load of each tas! without any duration or calendar consideration. Ignoring the date factor help in getting asobective 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 willma!e evaluation of the conversion progress easier.

,S Sa(2le

Ho3 to

The idea is to brea! the proect in chun!s and then brea! each of these in tas!s. *ou then proceed to evaluate the wor!loadre)uired for each of these elements. It will be much easier to get accurate and obectives 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 more2-" 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 oneelement will also have a greater impact. As for progress followGup, it will be less accurate, since any detected slippage willinvolve 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 moredifficult 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 ondifferent proects. I thin! it is granular enough to be precise and usable for efficient followGup. *et, simple enough, for thewhole team to easily contribute in evaluating the numbers.


19/

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 obective

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 thisshould be finish or how long should it last. ust try to figure out the real wor!load needed to complete each element ofthe :5 process. After that, we will see how we can meet deadline by acting on the organization of the proect ratherthan


20

Data Migration Methodology for SAP PAGE #

2hen getting the numbers for the original 2-", you average each element. verall, you under estimate some and overestimate others, but the average law will ma!e it a globally reasonable measure. Fowever, if you start concentrating onsome numbers while forgetting others, the average law is out the window. This is why you must consider, both the large andsmall 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


21

Data Migration Methodology for SAP PAGE #1

4aster. This will create collisions and conflicts, which will need meetings, discussions and testing before theissues are solved.

The conversion rules are different for each 4aterial Type and it is not always the same !ey users who have theinfo 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 the9egacy "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 obect 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 the9". There is always one business obect where you will discover, at the last minute, that it ust will not fit into "A#without maor unplanned efforts. It is not bad luc!, it ust happens every time. -ad luc! is when you did not consider itin 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 bringbugs

If you have part automatic and part manual, li!e


22

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'.'''&C day8 per record and by field 7number of fields number of

records '.'''&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 Ican 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 rulesadaptation. 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 lessdependent on the number of fields than on the compleity of the data to etract. 3or those two, you can use the formula andthen add between B'( to &''(, depending on the legacy data compleity. As stated earlier, if -4 and $outing aremerged in a single structure in your 9" 7i.e. multilevel8, count that -4 will ta!e double the time you originally estimatedand $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!eninto consideration. If you really count all the time spent on one business obect, none will ta!e less than &' #erson1:ays.=se you udgment and apply between &' to %' #erson1:ays per business obect according to epected compleity. ;achtime someone tells you


23

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#roect or other planning tool, you will enter the tas!s and complete it with thefollowing 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 obective 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 andbottlenec!s.

n most conversion, the overload on !ey user is always a maor problem. *our !ey users will be strongly solicited rightfrom the beginning of the proect. Deep in mind that the more you go on with your proects, the more they will be solicitedto troubleshoot problems, and this will be on top of their normal conversion wor!. The result is that their availability willonly get lower as the proect 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 proect planning and do aresources load analyses. This tas! is most difficult, time consuming and very frustrating 7especially if you do not master4"G#roect8.

!alendar 2lanning %a(2le


24


MS"Proe&t or not)

4ost probably, the only planning tool youJll have available will be 4"G#roect. Although it is a nice tool, it also has greattalent 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#roect before you get into it. It will be a much less frustratingeperience. "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 obect, I never overlap two tas!s. *es, since the process between test andrules and loading is iterative, we should be able to do them in parallel. Fowever to do this realistically you would need toconsider 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 simpleenough, is to never put tas! in parallel within a business obect.

ey '%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 givesyou an average of the time they will be able to give you throughout the entire proect. "ometime it will be less, sometime itwill be more, but overall it will be +'(.


25

Data Migration Methodology for SAP PAGE #:

G :o not parallel the tas! hoping to save time. There are only +hrs in a day and people need sleep.G :o not forget the +'G+B( marginG :o not change the #erson1:ays established in the 2-", it is the most obective values you can get.G If you need to finish a tas! faster, never change an end date or the wor!load. 5hanges the resources allocations to obtainthe timeframe you want H then reGvalidate the resources wor!load.

,orBload analy%i%Fere you are, now you have to identify the resources overload and play with the tas! se)uencing until all resources are innormal wor!load.

This is a very difficult and frustrating step. In addition, since 4"G#roect will regularly mess things for you, 4AD;-A5D=# copies before ma!ing changes in the calendar planning.

nce the planning is done and resources wor!load is realistic, you are ready to go. At this point youJll only have to identifyslippage as the proect go and ta!e corrective action before it has an impact on the proect duration.


26


SECTION 3 - CONVERTING A BUSINESS OB*ECT


27

Data Migration Methodology for SAP PAGE #=

Acceptance "ystem full load#re #roduction "ystem full load#re #roduction "ystem "ignoff

#roduction 9oad L "ignoff

4apping L 5onversion $ules

;tract and 9oad #rograms

:ata and $ules adaptation

:ata

#urgingL5leansing

;tract L 9oad M 3ull "ize Testingand :ata 6alidation

9oad =nitTesting

#roect !ic!Goff


28/

Data Migration Methodology for SAP PAGE #>

3.1 OVERVIEW

This section gives you information on the maor steps involve for each -usiness bects. ;ach person who is responsible ofa -usiness bect should read this.

In the previous section we saw one of the methodology main ingredients. It involved mainly planning and is actually abasic management concept, which is applicable to any !ind of proect, computing or other. The second main ingredient ofthe methodology, which will ma!e it so efficient, is the way we deal with the conversion process itself.

efore yo' *egin)

2hen wor!ing on the conversion, do not try to fit your 9egacy "ystem into "A#. Thin! "A# and understand it. Then youcan see what can be recuperated from your 9egacy "ystem. 5onverting into "A# while having in mind your 9egacy "ystemprocess will for sure lead you into the wrong path. et familiar with your "A# -usiness bect. 5reate obect, read the online documentation, understand the re)uirements, go through your complete process. This will ma!e the conversion easier.

Do&'(entation of yo'r 3orB &on/er%ion %2e&) and (a22ing %heet

Deep in mind that "A# is a highly integrated system. 4aster :ata has direct and indirect impacts on all process, which isnot always obvious. 3or this reason, all rules and mapping must be documented in clear format to permit cross reading andvalidation among the whole functional team. This will permit a better circulation of information between domains andawareness of other modules decisions.

Although a structured documentation process might ta!e a bit longer at first, it will permit to have a synergy that willeventually ma!e the whole bigger than the sum of the parts. I !now, it sound li!e a theory from a big boo!, but it reallydoes wor!.

3.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 theconversion. "tart this as soon as possible and do as much as possible. This can be done without specific !nowledge of "A#.

Data P'rging

-efore transferring data from your legacy system, delete all the old and obsolete data. 3or eample, you may delete alloneGtime customers or those for which there where no transaction in the last two years, also delete unused materials.

Data !lean%ing

This process corrects data inconsistencies and ensures the integrity of the eisting data during the migration process.3or eample, there are often lots of inconsistencies in 5ustomer and 6endor address fields. *ou will )uic!ly find that"A# will not let you load any address fields unless you get them clean.

3.3 +APPING AND CONVERSION RULES

The documentation of each business obect will contain the :ata conversion rules 7or specification8, which include 0

9egacy sources and etraction procedures.3rom which 9egacy system7s8 are we etracting the data and how. :ocument here specific steps that needto be ta!en.

#urging and cleansing rules2hat are the cleaning steps to be ta!en and etraction filters to be used.

eneral 5onversion rules

uidelines to apply or rules that is used by many fields 7thus avoiding to retype it and ma!ing updatingeasier as it is only in one place8.

3ields "pecific rules2hich "A# fields to use and how do we get the final value for each "A# field.


29/

Data Migration Methodology for SAP PAGE #@

A*o't the r'le%

etting the conversion rules to be written is a !ey element of this methodology. etting rules, rather than getting raw datain ;cel, 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!. Thus permitting to identify conflict andmisunderstanding between domains.

$ules document can be versioned, ma!ing change management easier as the proect is progressing.

5ommunication between functional and technical people is facilitated by using a common ground language.

*ouJll have to !eep in mind that these will be made by !ey users who may not be familiar with writing computing rules.Therefore, it is necessary to give some eample and to eplain some basic !ey element in rules writing.

-asic properties of a rule 0

eneral rules 6" 3ield $ules

eneral rules are the one that does not yield directly to a field value. 3or eample the way in which wedifferentiate the material types in the 9egacy "ystem is such a rule. 3ield rules are those that give a value fora specific field.

3ields names

This is a crucial one. 2hen discussing or writing notes, A92A*" refer to a field in the form TA-9;G3I;9:.*ou will )uic!ly realize that as the proect go, different people will start using different names for the samefield. As well they may start using the same name for different fields.

n top of this, some fields eist in different views in "A# master data. "ometime it is the same field that isshown at two places while other times it is really two different fields. The best way to !now which case applyis to have the TA-9; R 3I;9: information.

;ample0

In 4aterial 4aster, the field WAvailability chec!X eists in the


30

Data Migration Methodology for SAP PAGE .

4ust be clear and without ambiguities

3or eample 0

If product is a sold semiGfinishedH.

;nd

This is not clear enough, Fow do we !now which product are


31

Data Migration Methodology for SAP PAGE .1

&ststep 0 "election of the fields by each domain

et each domain with their consultants to go through the mapping file and loo! at the fields for each material type.

The goal here is to see all the fields that are important and as! )uestions to understand them. This is doneseparately by each domain and documented in different mapping files.

At this point we are not interested about where the values will come from and how will we get them. ="T ;TTF; 4A##I/ :/; and wor! on understanding what material master is.

;ach time a domain select a field for a specific material type, they must enter their domain type in the list. Fere aresome 7theoretical8 eamples of mapping from 44, ## and ":

Ea(2le of field% %ele&tion *y ea&h do(ain

,hat to do 3hen the %a(e field i% fo'nd in different /ie3%

In 4aterial 4aster, some fields can be entered 1 modified in different views. 3or eample, the fieldoods receipt processing time in days 74A$5G2;-AN8 eists in views #urchasing, 4$#+, Sualitymanagement.

2hen doing the rules and the load program, the same field canPt be in different views. To solve this,proceed as follow0

"ee with all implicated domains who is the lead for the field and decide in which view the fieldshould be included.


32

Data Migration Methodology for SAP PAGE .#

Ta!ing the eample of the field oods receipt processing time in days 74A$5G2;-AN8, it can bedecided among the domains to put it in the #urchasing view 7and nowhere else8.

This means that #urchasing is the lead on this, but do not stop other domains to use it of have specificrules for it. It is however #urchasing role to ma!e sure this field is used correctly.

-e careful, ma!e sure it is really the same field. 3or eample0

In 5ustomer 4aster, the field < Terms of #aymentJ eist in


33

Data Migration Methodology for SAP PAGE ..

Data &on/er%ion r'le% te(2late %a(2le

thstep 0 et the rules from each domain, independently

As! each domain to specify the conversion rules for all the fields they are concerned with. This is purposely doneindependently for each domain so that misunderstanding or conflicting rules between domains may be put inevidence in the net step.

Bthstep 0 4erge the rules from all domains.

4a!e a single document that contains all the functional domainJs rules and note, for each one, which domain wroteit.

Cthstep 0 Analyses of the results and creation of the Issue list.

At this point, I usually create what I call the S=;"TI/" 9I"T. It is a simple 2ord document where I put all the)uestions, the name of who is responsible for the solution, creation date, target date 7with history if the target ischanged8.

#repare yourself for a very long list at first. I usually endGup with an average of + )uestions per field. Therefore, ifyou have %'' fields, that is C'' )uestions. And if you happen to merge % 9egacy "ystems into one "A#, you willhave C'' )uestions per 9egacy "ystem. H That is &?'' )uestions. 4ost of these will be )uic!ly dealt with, theyare unclear rules or obvious problems that get solved within the first wee!.

ne interesting thing that usually happens here is rules conflict. This happens when more than one domain use thesame field and they come up with contradictory or incompatible rules. 3inding this at the beginning of the processwill be a great time saver, as you ust identified important issues between domains before you developed anything.ne of the main challenges of implementing "A# is integration of the different functional domains into a singleproduct. 3ailure to understand this is will get you into trouble, and this is true for all the "A# implementationprocess, not ust the :ata 4igration part of it.

As the proect goes, the S=;"TI/" 9I"T becomes the data conversion T: 9I"T. Anything that is promised,due, scheduled or to be given must be noted there.


34


*ou now have 4aterial 4aster conversion rules documented and a T: 9I"T to follow up on the issues to be solvedbefore you can load the data.

Material Ma%ter &on/er%ion r'le% %a(2le

All other *'%ine%% o*e&t%

3or the other -, because they are simpler than 4aterial 4aster and involve fewer people, we will start directly with the5onversion rules document. It is in this document that we will both, decide which fields we need and, in a second step, startwor!ing on the rules.

Fere are some samples of - conversion rules.


35

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


36


7endor Ma%ter &on/er%ion r'le% %a(2le

Ea(2le of general r'le%

ID R$LE''' /ote that "A# term "ecurity deposit e)ual $etention in #$4"''& Type of transaction

T*#; field in #$4" 0#artial #4T0 #ay.5redit 4emo0 5r 4.:ebit 4emo0 :r 4.Invoice 0 Inv.

/on A1$ cash0 /on A$

Adustments0 AdAny other type is an error.

''+ 6alidation to apply both at etraction and load.#artial #4THHH. must be negative in #$4", if not ;$$$5redit 4emoHHHmust be negative in #$4", if not ;$$$:ebit 4emoHHH.must be positive in #$4", if not ;$$$InvoiceHHHHH..must be positive in #$4", if not ;$$$Any other type is an ;$$$.

''% 9"4 9oad parametersDT#9 G 5hart of account 0 5A''-=D$" M 5ompany code0 ''>'"-;$ G -usiness Area 0 '''-=:AT M #osting :ate 0 'BG%&G'+ or last day of last closed period.33";T M Account 7+8 0 $;#$I";59"D#;$$ M "!ip err 0 K


37

Data Migration Methodology for SAP PAGE .=

Dire&tory organiCation

As you go, you will end up with lots of documents and versions. To store the different files on your local server, use aspecific directory structure. I suggest having a structure with a directory for each -usiness bect to store all the filesrelevant to the data conversion. Fere is an eample.

50Y.

Z[ :ata 5onversion\ \\ Z[[[ '' G rganization\ \ \ :5 #9A/\ \ \ :5 2-"\ \ \ :5 "5F;:=9;\ \ \\ \ ][[[[[ ld\ \ ^ "tore here previous versions of above mentioned documents _\ \\ Z[[[ '& G 4aterial 4aster\ \ \ 4aterial 4aster G 3ield "election "heet.ls\ \ \ 4aterial 4aster G :ata 5onversion "pec.doc\ \ \ ^ Deep here only the latest version of each document _\ \ \\ \ Z[[[[[ ld\ \ \ ^ "tore here previous versions of above mentioned documents _\ \ \\ \ ][[[[[ 2or!ing 3iles\ \ ^ #ut here various wor!ing files _\ \\ Z[[[ G- name\ \ \ - G :ata 5onversion "pec.doc\ \ \ ^ Deep here only the latest version of each document _\ \ \\ \ Z[[[[[ 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 proect goes, rules will change. This is a certitude. As you get closer to o 9ive, changes will get more fre)uent,they will occur faster and will re)uire a )uic!er reaction time.

5onsidering the stress on the whole proect team and the overall load on all members near 9ive, there is a real danger toloose control here. ne way to stay on top of things while having etra )uic! reaction time is good document management,which will permit a good change management. Although it may sometime feel frustrating to go through versioning for !eyusers, it will ultimately be the best way to go fast without brea!ing something else that already wor!s 7regression8.

Fere how it goes 0

5reation of the first version rules 6'&.doc

3reezing version 6'& nce everyone agree that 6'& is D 7functional and technical staff8, freeze the version.

#assword protect 6'&, 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


38/

Data Migration Methodology for SAP PAGE .>

:evelopment and testing of 6'& As! the technical team to wor! on 6'& and only on 6'&. Any change re)uired by functional team must be done in 6'+. : /T 5FA/; 6'& nce 6'& is programmed, load it and as! functional team to validate. All correction has to be entered in 6'+.

3reezing of 6'+

nce everyone agree that 6'+ is D 7functional and technical staff8, freeze the version. #assword protect 6'+, so no one changes it afterwards 4a!e a copy of the document as 6'% In 6'%, accept all changes so that there is no visible change. In 6'%, activate 4"G2ord change trac!ing 7should already be on8 #ut 6'+ in the


39/

Data Migration Methodology for SAP PAGE .@

This will prove to be an enormous time saver later on.

4ost of the time, when you do not begin any programming until all etract and load rules are &''( clear 7and I mean&''(8, there is a tendency to thin! that you ust ma!e everyone loose time. /ot so. If you found issues at this point, itmeans that there will be errors in the process and you will have to address these issues anyway. It ust will be more difficultand time consuming to do it after the programming is done than now.

3./ D!%! !#" R&0$ !"!%!%o#

This is, by far, the most time consuming part of the conversion process. This is also the most difficult, where "ystem4igration 4anagers can loose control of the conversion process. $emember this throughout the whole process0 As in carracing, 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.

The migration process is an iterative one.

After you have the specs, you do the etract and load programs

"ome )uestions or issues will arise. *ou must address them and document in the specs whatevercorrective actions are needed. The specs must always be updated to reflect the new re)uirements-;3$; you correct any program.

:o unit testing of the load


3ollowing the modifications, you need to redo the unit testing of the load.

3ull size test cycle


3ollowing the modifications, you need to redo the unit testing of the load and redo a full size test cycle.3or all the "ystems 4igrations I did, these iterations accounted for a maor part of the :5 process duration. This is timeconsuming and can be very frustrating if not properly managed.

In a nutshell, here are the guidelines most useful at this point 0

&. 3irst, when something needs a change, it must be documented and validated in the specs so that it is clear andunambiguous to all. Deep in mind that a change from one domain can affect others and they will find this onlylater in the process, once everyone forgot about what was eactly changed.

+. The -usiness bect Dey user is the one accountable for the rules 7all of them8 relating to his1her -, for theirmaintenance and for the end result. This is not the technician part of the wor!. The tech team is there to developprograms according to what the rule says.

%. If it is not in the rules, it does not eist. "o if you do not see what you need, get it documented.

. Fave the discipline to manage change by versioning the documents and ma!ing sure they are crossGvalidated byall implicated sta!eholder.

B. It is better to ta!e your time to do it correctly rather than rushing it, which usually means you may have to slowdown at some points. $esults will initially be slower to come, but you will eventually progress faster and faster. Asproblems can accumulate in a snowball effect, so does success 7and this is a good news8. Ta!e the time to do itright now and you will eventually pic!Gup an impressive speed in the net steps.

C. The specs must always be updated to reflect the new situation -;3$; you correct any programs. *ou must bethin!ing, D, stop repeating the same thing again and again, I got it. I do so because this is the most commonerror I saw on proects that failed. Trying to save time a team starts wor!ing on new solutions without ta!ing timeto document, cross read and validate the specs. They sure are getting output )uic!ly this wayH but are they goingin the right direction E


40


>. If you start running in all directions and canPt !eep you head out the water, "T#, and go bac! to step &.

3. Lo!" U#% T$%#

Fere we want to test the load programs at a unitary level. The goal is to see if we can load all the fields for all the data typeswithout error. 2e are more concerned about going through the load cycle without "A# stopping us, rather than validating

the correctness of the values. 3or this we use a very small volume of data, usually creating data manually from scratchrather than using real etracted data.

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 epected Invalid values where given to you in the rules ;rrors in the load programs =sing a load program, "A# did not behave as you epected 7it sometimes behave very differently with a load tool

than it does with manual data entry8

As mentioned earlier, the conversion process is iterative. 3ollowing the issues youPll find here, you will have to go bac! tothe functional !ey user, find solutions and document them in the specs 7this is the responsibility of the !ey user8.

3.4 E,%r!'% 5 Lo!" 6 7&00 S8 T$%# !#" D!%! V!0"!%o#

At this point, we want to !now if we can load the data with the processes we developed 7etraction and load8, as well asvalidating the results of the conversion in "A#.

At the end of this step, we will have a fully functioning and validated conversion cycle.

This is done it two steps0

&. 9oad data that comes from the full etraction process 7starting with small size and progressing with larger data set,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 usingthe full ;tract and 9oad cycle. The goal is to achieve &''( of loaded data

After each load, the functional that is responsible for the business obect must validate the data. This is time consuming andmust be done as soon as possible. $emember the bottlenec! with !ey user I mentioned earlier in the planning section, thefarther you are in the proect, the less availability youPll get from the !ey user responsible of the -.

3inally, of course, following the issues you will find here, you will have to go bac! to the functional !ey user, find solutionsand document them in the specs 7this is the responsibility of the !ey user8.

3.9 A''%!#' S:$% 7&00 Lo!"

-efore going into preGproduction, you must be able to start from an empty "A# client, etract, load &''( of the data, andhave full data validation from the -Ps !ey users and the -Ps wners.

3rom this point on, if you change something, you must redo a full etractGloadGvalidation cycle for the - affected. 3ailureto do so 7i.e. ma!ing last minute changes and not validating them full size8 will ( of the time creates bugs in the loadprocess at production time.

Again, to achieve this you will need lots of discipline. 2hile you can correct bugs in dev, it is difficult to correct them inpre prod 7and suicidal8. If at the end you load in production and create data inconsistencies, it can ta!e up to a year tocorrect this. -ecause the production system is living its own life and canPt be controlled as in dev, correcting 4aster :ataerrors is li!e shooting a moving target H the more you try to fi it, the more you seems to brea! everything around it. I


41


have seen teams cheating on this step and still have corrupted -4 after a year. "ince -4 affect #urchasing, 5osting,4anufacturing, Inventory, etc. you can imagine in which condition their "A# got after a while.

3.; Pr Pro"&'%o# !#" Pro"&'%o# Lo!"

"ince you went through all the steps and followed all the methodology guidelines, this is ust a formality.

*ou do a full load in preGprod, starting from a copy of prod and doing everything eactly as you will do in prod

*ou get the whole thing validated by the -Ps !ey users and the -Ps wners

Then you get written signoff from the -Ps wners that all is AGD 7insist to have it written, not verbal8

After, you do the final production load and get final signoff

3inally you have nothing else to do, as by following this methodology, you managed to load &''( accurate 4aster:ata and no rewor! is needed 7yes, this happened to me for real8

Fere are the guidelines to follow here. Again simple but re)uiring a lot of discipline 0

:o not change any etract1load programs to correct errors found in reGprod. It is better to ma!e manual corrections or create programs the correct the data after loading them. This

way you do not induce regression into the etract1load process.

2hen it is time to load in prod, do eactly as you did in pre prod, and then apply the manual changes orrun the data correcting programs eactly as you did in pre prod.

If you must change the anything in the load1etract process or programs, you must again do a full preGprod load test1validation of everything.

3.1< S&$%o#$ o# %= D!%! Co#>r$o# L!#"$'!

As I did different 9egacy "ystem migrations into "A#, one situation !ept showing up about the clients re)uirements.

nce you will be done with the first loads of 4aterial 4aster R -4 R $outing, the following will happen0 ## will be ma!ing corrections to -4 and $outing 3IG5 will be doing costing runs and are directly affected by -4 and $outing The rest of the team will be ma!ing corrections to the other -usiness bects

$egularly, at some points, they will all need to change the etract1load rules, adapt the programs and load the data tovalidate the results. This is where it gets tric!y, they will the need to reload data at different intervals from each other, andyou cannot do this without affecting another team that is proceeding at a different pace in their 6alidationG5orrectionprocess. 3or eample, you cannot load data in the -4 for ## without affecting the 3IG5 team in their costing validation.

In all cases, we came up to the same conclusion, at one point we need three clients organized li!e this 0&. A 5lient for ## wor!ing on -4 and $outing+. A 5lient for 3IG5 wor!ing on costing%. A 5lient for all the other -Ps been wor!ed on

"ince it ta!es time and resources to setGup these clients, better to !now it is coming and plan for it right at the beginning ofthe proect.


42

Data Migration Methodology for SAP PAGE 6#

CONCLUSION

/ow you !now how I did different 4aster :ata migrations faster and better than others did. I successfully used thismethodology in different industries, in different countries and with starting proects as well as with proects already runningwhich needed to be turned around.

The methodology itself is mainly a mi of good old common sense and management &'&. ;ach step is the foundationneeded for the net step. 5omplete each step at &''( and the net one will be easier. This will have a snowball effect,permitting you to gain more speed from step to step. /ot following this rule will also have a snowball effect, but in theother direction, reaching a point where the conversion process becomes totally out of control.

The difficulty is not in understanding the methodology. #ressure to show rapid results 7any results8, tendencies to pushforward issues so we can !eep progressing, and resistance to slow down when the process starting to get out of hands.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 obective is notto finish a specific step A"A#. The goal it is to complete the whole process in the best time possible and to deliver acomplete set of 4aster :ata that will not need rewor! once in production.

This is how I managed to !eep my head above the water and continuously see where we are going, even when everyoneelse seems to be in crises.


43

Data Migration Methodology for SAP PAGE 6.

APPENDI? 6 VARIOUS TE+PLATES


44


A " !on/er%ion 2lan te(2late

Data ConversionPlan.doc

" ,S te(2late

WBS Template.xls

! < Material Ma%ter " Field% %ele&tion %heet

MAT MASTER FieldsSelection Sheet SAP

D " Data &on/er%ion %2e&ifi&ation " Generi& te(2late

Data Conversionr!les template.doc

E " Data &on/er%ion %2e&ifi&ation < OM 4 Ro'ting Te(2late Sa(2le%

B"M conversion specsample.doc

Ro!tin# conversionspec sample.doc

F " Material% !la%%e% and !hara&teri%ti&% %tr'&t're

I included this as it may be useful to understand, and eplain, the structure of 4aterials 5lasses and 5haracteristics

Materials Classesand Characteristics st

data migration methodology for sap

Documents