Data migration methodology for sap v2

DATA MIGRATION
METHODOLOGY
FOR SAP
VERSION 2.0
Data Migration Methodology for SAP version 2.0
By Christian Bergeron (cvcby@yahoo.com)
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License

Data Migration Methodology for SAP PAGE 2
NO TIME TO READ! … THE METHODOLOGY ONE-PAGER
The origin of the methodology
I started by analysing previous migrations, looking at what worked and what did not. After, I followed an ongoing migration,
working in real time with the team and, as issues occurred, we used the “5 Whys” approach to find the root cause of each
issue and see how to avoid it next time.
The result was a set of ground rules, permitting to avoid issues by working on their causes.
The ground rules
These are the ground rules around which the methodology was built:
1. Start by understanding SAP
… Than see what is to be taken from the legacy system
2. The migration must be integrated with the functional analysis
… As most migration issues are linked to functional choices
3. Key Users may not be familiar, or comfortable, at writing conversion rules or specifications
… The format used to write rules is kept simple, clear and easy
4. Each Business Object must be owned by a Key User (supported by a business analyst)
… Who is responsible for writing the conversion rules and accountable for their accuracy
5. Define which fields you need in SAP before going into any conversion rules
... As Key Users must first understand the fields purpose and impacts on the SAP process
6. Conversion rules must be written
… So everyone involved in the project can read them and agree on it
7. Do not start any programming for a Business Object before you have a complete set of clear rules for all fields
… A clear understanding between the functional and the technical teams will avoid many time consuming issues.
The rules in action
In order to clearly document the conversion rules, the functional team must question and understand the purpose of each SAP
field, thus requiring them to better understand the SAP process itself.
Since most of the conversion issues are linked to customizing and functional choices (or omissions), some questions raised
while digging to document the conversion rules will reveal these pitfalls, which might otherwise come up only toward the
end of the project.
This synergy of conversion rules and functional analysis, permitting to identify and resolve potential issues before they occur,
will yield a much faster and stable conversion AND functional/customizing process for the following steps. The “AND” is
key here, conversion will boost functional/customizing and vice-versa, this is where we get added value.
How to make it work?
The whole process of this methodology is designed as building blocks, were each step if the foundation on which the next
one is built. I also used the “Lean” approach, so everything that is not necessary is removed, everything that is left is necessary.
What makes it work is the systematic application, of each step of the methodology, for all Business Objects.
No silver bullet
There are no technological gadget or revolutionary methodology to make it effortless, but some paths are easier than others.
This methodology has proven to be the shortest path, to achieve a 100% accuracy, in data migration of many ERP
implementations.

ABOUT THIS DOCUMENT
Goal of this document
This document describes a methodology for data migration I used successfully, in different implementations of SAP in a
manufacturing environment. It is base upon my previous experiences.
All the templates are derived from models I used in specific implementations in the manufacturing industry and may come
from older version of SAP R3. It most probably will not be 100% adequate for your use. It is a base to help you build your
own template. You can start from them, but do not take for granted everything is there.
Although this methodology was done for specific SAP implementations, the same approach can be used in other ERP
implementations, as the challenges and issues of data migration will be similar.
Version 2
Version 1 was published in 2003. Version 2 consists of texts corrections and revisions. The methodology itself is the same.
The templates found in “APPENDIX A” are the same as in version 1.
Whom is this guide for?
1 Section 1 is for every one involves in the data migration process.
2 Section 2 is for the project manager and the data migration manager
3 Section 3 is for the data migration manager and the members of your team responsible of converting Business
Objects, both technical and functional.

TERMINOLOGY AND ABBREVIATIONS
Note: The terms SAP and R/3 are both use interchangeably to refer to SAP R/3 system.
Big Five: When referring to the Big Five, it means Material Master, Customer Master, Vendor Master, Bill Of
Materials (BOM) and Routings.
Business Objects: To help in the analysis and transfer process, the data are not treated as tables or field contents but
rather as objects in term of business operational. These are called Business Objects (Ex: Material Master, Customer
Vendor …)
Business Object Owner: A Key User responsible of the conversion process for a specific Business Object (Legacy
data source and integrity, mapping, conversion rules, etc.).
Business Object Stakeholder: The one owning the information in the every day business. This person will make
the strategic choices on functional requirements for the Business Object and the final validation of the converted
data. The Business Object Stakeholder can be identify by finding “the highest hierarchical person who will be
directly and mostly affected if the Business Object does not work”
Conversion table, Cross reference table, Transcodification table, or X-Ref table: A table that shows the relation
between fields when one value is related to a parent field. For example, the "Sales Organization" will be set
accordingly to the material type.
Data Conversion & Data Migration: The data conversion process. “Data conversion” and “Data Migration” terms
are used interchangeably in the document.
DC: Abbreviation for the Data Conversion process.
Domain: Functional domain within the project, like Finance, Sales, Production, etc.
Flat File: A common file format used to import data into SAP.
Functional team: A Key User owning the Business Object and one (or more) business analyst.
LS: Abbreviation for Legacy System
LSM or LSMW: Legacy System Migration Workbench. It is a SAP tool to convert and load the data extracted from
the Legacy System.
WBS: Work Breakdown Structure.

TABLE OF CONTENTS
NO TIME TO READ! … THE METHODOLOGY ONE-PAGER................................................................................... 2
ABOUT THIS DOCUMENT................................................................................................................................................. 3
TERMINOLOGY AND ABBREVIATIONS....................................................................................................................... 4
SECTION 1 - INTRODUCTION TO DATA CONVERSION........................................................................................... 7
1.1 INTRODUCTION..........................................................................................................................................8
 Overview ..................................................................................................................................................8
 Bases from which this methodology was made........................................................................................8
 Concept VS techniques.............................................................................................................................9
 A few facts................................................................................................................................................9
 Conversion rules and Business Object ownership....................................................................................9
 Main steps of the conversion methodology............................................................................................10
 Where you will, for sure, have a timing problem ...................................................................................10
 There is no such thing as a free lunch.....................................................................................................11
1.2 DATA CONVERSION GUIDELINES ........................................................................................................12
 Think SAP ..............................................................................................................................................12
 Prepare the Legacy data..........................................................................................................................12
 Before the last test run, take into account the customizations of your new system ................................12
 Reduce the amount of historical data to be transferred...........................................................................12
 Prefer the use of control reports..............................................................................................................12
 Small is beautiful....................................................................................................................................12
 Play it safe ..............................................................................................................................................12
1.3 SUGGESTED ADDITIONAL READINGS.................................................................................................13
SECTION 2 - ORGANIZE THE DATA CONVERSION ................................................................................................ 14
2.1 OVERVIEW.................................................................................................................................................15
2.2 DATA CONVERSION PLAN .....................................................................................................................16
 Business Objects.....................................................................................................................................16
 Data type.................................................................................................................................................16
 Required information to complete the conversion plan..........................................................................17
 Main Business Objects sequence of conversion .....................................................................................18
2.3 WBS ( WORK BREAKDOWN STRUCTURE).......................................................................................................19
 Why a WBS?..........................................................................................................................................19
 How to ....................................................................................................................................................19
 Suggested WBS content for data conversion..........................................................................................20
 Are you sure?..........................................................................................................................................20
 Request to re-evaluate your WBS...........................................................................................................21
 Facts to consider in you work estimate...................................................................................................21
 Ballpark figures ......................................................................................................................................22
 A formula to help …. Handle with care..................................................................................................22
2.4 CALENDAR PLANNING ...........................................................................................................................24
 Overview ................................................................................................................................................24
 MS-Project or not. ..................................................................................................................................25
 Sequencing the tasks...............................................................................................................................25

 Key Users and consultant availability to work on Master Data..............................................................25
 End 'at best' VS 'most probable'..............................................................................................................25
 Are you sure?..........................................................................................................................................26
 Workload analysis ..................................................................................................................................26
SECTION 3 - CONVERTING A BUSINESS OBJECT ................................................................................................... 27
3.1 OVERVIEW.................................................................................................................................................28
 Before you begin. ...................................................................................................................................29
 Documentation of your work (mapping sheet and conversion rules) .....................................................29
3.2 DATA PURGING AND CLEANSING........................................................................................................29
3.3 MAPPING AND CONVERSION RULES...................................................................................................29
 About the rules .......................................................................................................................................30
 The Material Master challenge ...............................................................................................................31
 All other Business Objects .....................................................................................................................35
 Business Objects conversion rules examples..........................................................................................36
 Directory organization............................................................................................................................38
 Change management: working in batch mode........................................................................................38
 Version management of conversion rules...............................................................................................39
 Murphy's protection: Save it often and do rolling backups. ...................................................................39
3.4 EXTRACT AND LOAD PROGRAMS .......................................................................................................40
3.5 TRANSFORMATION BETWEEN THE EXTRACTION AND LOAD.....................................................40
3.6 DATA AND RULES ADAPTATION .........................................................................................................40
3.7 LOAD UNIT TESTING...............................................................................................................................41
3.8 EXTRACT & LOAD – FULL SIZE TESTING AND DATA VALIDATION............................................41
3.9 ACCEPTANCE SYSTEM FULL LOAD ....................................................................................................41
3.10 PRE-PRODUCTION AND PRODUCTION LOAD & SIGNOFF ..............................................................41
3.11 SUGGESTIONS ON THE DATA CONVERSION LANDSCAPE.............................................................42
CONCLUSION..................................................................................................................................................................... 43
APPENDIX A – VARIOUS TEMPLATES........................................................................................................................ 44
 1 - Conversion plan template.doc ...........................................................................................................44
 2 - WBS template.xls..............................................................................................................................44
 3 - Material Master - Fields selection sheet template.xls........................................................................44
 4 - Data conversion specification - Generic template.doc ......................................................................44
 5 - Data conversion specification – BOM template.doc .........................................................................44
 6 - Data conversion specification – ROUTING template.doc ................................................................44
 7 - Materials Classes and Characteristics structure.ppt ..........................................................................44
APPENDIX B –LICENSE ................................................................................................................................................... 45
 Creative Commons Attribution-ShareAlike 4.0 International Public License........................................45

SECTION 1 - INTRODUCTION TO DATA CONVERSION

1.1 INTRODUCTION
Overview
Implementing SAP is an important challenge, both in terms of resources as on business process impacts. A lot is at stake and
failure is costly. To put all odds on your side, you need a good methodology, providing realistic planning, solid organization
and a way to control the migration process so you can detect and correct slippage before it becomes a problem.
An important part of this challenge will be the data conversion. Previous implementations of SAP have shown that data
migration can amount up to about 40% of the entire project. Poor data conversion will make your “Go Live” very difficult,
if not impossible.
This guide is aimed at helping you organize the data conversion process, which in turn, will lead to a successful
implementation.
Bases from which this methodology was made
When I was originally asked to come up with a data migration methodology, I started by analyzing passed experiences, where
I found the following recurring problems:
 While the project is going on:
 There are many things being worked on at the same time. Yet, most of them are not progressing.
 There are documents all over the place and, somehow, they always seem to be outdated.
 Data loaded is regularly incomplete and inconsistent.
 Functional changes are not impacted on the conversion rules.
 Data previously loaded with success are suddenly rejected by SAP.
 There is a lot of misunderstanding, friction and frustration between the functional and technical teams.
 At Go Live
 Master Data deadlines where constantly busted and production load is done in ''rush mode' at the last minute.
 Some key parts of the data cannot be loaded in production. Patches are applied to the Master Data in order
to force-load.
 Some data will not get in at all, they will have to be entered after Go Live.
 After Go Live
 Some Data need to be corrected and entered after Go Live. Because the production system is living, data are
constantly changing, making the “catching up” on data integrity a moving target. This makes the process
difficult and time consuming, which translates into costly operations and possible business errors.
After discussing with people who lived these situation (manager, functional and technical), we identified the following causes:
 Planning and resources load estimates where way out.
 Most problems encountered are functional issues, which where overlooked or classified as conversion stuff “to look
at later on”.
 Information does not travel well between functional and technical teams. As we get near the Go Live, this becomes
even worst.
This methodology was made to solve these issues.

Concept VS techniques
The approach I take to the data conversion is as much a concept as a technique. Both aspects must be applied for results to
show up. This is actually true of any concept, where failures are often due to application of the technique while neglecting
the conceptual aspect of it.
The mindset required in our case is that we must do things right from the start and solve issues as they occur. Take the time
it requires to do thing properly and thoroughly. No expediting, no bypassing of step, no piling of unsolved issue to keep
going.
Results will initially be slower to come. However, because you will get things right the fist time, there will be no need to go
back. Changes always create regressions, costing you precious time and money. By eliminating the need to do rework, thus
eliminating the regressions, you will eventually pick-up an impressive speed. As in car racing, it is not the speed at which
you enter a turn which is most important, it is the one at which you get out of it.
A few facts
The data conversion is not some technical stuff to give to the programmers and wait until it comes back. Most, if not all, of
the issues and problems you will encounter in the conversion process will be functional. Although the extract / load process
itself will not be effortless, it is the part between the extract and the load, which is the most difficult. Getting rules, permitting
to have the right data at the right place, is always a functional problem.
SAP is a process-oriented system and Master Data is an integral part of this process. Nice, but what does it means? The
answer is that everything is tied together. Master Data is dependent of the customizing, the customizing is made accordingly
to the way you do your process, and Master Data is needed to run your process. If you change Master Data, it will most
probably change the behaviour of the process. If you change customizing, your Master Data and conversion rules may become
incomplete or incorrect.
Whichever phase you are in the project, data conversion always seems to be the step that can be pushed a little bit forward in
time. Doing this will put the conversion process too close to the end of the project. In this situation, you will end up shovelling
a ton of data into SAP at full speed with little control, if any, on data quality and coherence. Remember the old saying
"garbage in, garbage out".
Conversion rules and Business Object ownership
Ok, we now know DC is a functional thing, data must not be shovelled-in, it is hard work and it takes time. How do we
manage his?
The solution is to make the DC process part of the functional process, both in term of timing and deliverable. Key Users must
do a thorough analysis of the Master Data and link their usage to the process as they are customizing. They must understand
which data does what, which are needed, how it relates to the customizing & process flow and figure out where it will come
from. This knowledge will get things to fit progressively one into the other like a set of blocks.
For Key Users to get this knowledge, I give them the responsibility and ownership of the mapping and conversion rules. It is
‘their’ Master Data and they will do mapping & rules documents. At first, this process will not simplify the technological
aspect of the conversion, nor will it make it shorter or easier … say what! As I already mentioned speed will come, eventually.
The goal of the mapping and rules writing is to get Key Users to sweat it out and understand SAP way of doing things. This
will also help the knowledge transfer between consultants and Key Users. When they are done with this, they will play that
“Master Data - business process - customizing -” game without even thinking about it.
The mapping document and conversion rules will become the common ground for discussions between the different domains.
Cross reading of DC rules is essential as, for example, some action taken by PP may affect SD and FI. Do not underestimate
this, a small change in PP can block all expeditions. I saw this kind of issues in all the projects I worked on.
The DC rules will also serve as the common language between the functional team and the technical team. The mapping
document and conversion rules will become the technical staff road map. If it is not in the rules, it does not exist. So any
discussion, decision or answer must be documented in the rules. You will be surprised to see how things change between
verbal decision and written decision, which requires thinking about it and assuming responsibility for it.
Again, take the time needed to have clear and unambiguous sets of DC rules. For a specific Business Object, when the rules
have no ambiguity and where cross read and validated by all affected domains and the technical team, and only then, can you
start the development of the extract and load programs. This is the point where you start picking up speed, lots of it.

Main steps of the conversion methodology
Before you even start to work on specs, you must first get organized. Getting a good planning and organizational structure
take about two weeks for the first draft, which will leave you with some questions on project organization. Getting a complete
and final planning will take at least one more week. Any unsolved issues on the conversion organization will haunt you
throughout the project, so finish this completely before starting any other step.
The data conversion requires Key Users, business analysts and technical resources from most departments. These same
resources will most probably be involved in other parts of the project. For this reason, the risk of conflicting task is high and
can quickly lead to a bottleneck, where key peoples are overloaded. For this reason, you should consider the data conversion
as a project within the project. 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 bottleneck ever occurs.
The methodology is based on a top down process, which permits to plan, organize, execute and follow-up your conversion.
As the project is going, you will control the evolution of the data conversion process. Each step has its own use. You may
sometimes feel like you are not going to the end by the shortest route, but remember, the goal is not to get first results faster,
it is to finish the ‘whole’ process faster. This methodology, based on the experience of many projects, will help you avoid the
data conversion pitfalls.
The main steps of the data conversion are:
 Organization of the data conversion
 Data conversion plan
 The WBS with workload estimates
 The calendar planning with resources loading
 Going on with the Business Objects data conversion
 Data purging and cleansing
 Mapping and conversion rules
 Extract and load programs from rules
 Data and rules adaptation
 Load unit testing
 Extract and load full size testing
 Full data loading and validation into ACCEPTANCE SYSTEM
 Full data loading and validation into PRE-PRODUCTION SYSTEM
 Full conversion and signoff into PRODUCTION SYSTEM
Where you will, for sure, have a timing problem
The business process analysis is done by the Key Users, business issues are dealt with by Key Users, tests are done by Key
Users, functional issues are solved by Key Users, training is prepared by Key Users, data conversion rules are done by Key
Users, data validation is done by Key Users, Master Data issues are solved by Key Users …. In addition, when you start
validating Master Data, it is usually at the same time as Key Users are out giving training.
If you try to identify where there will most probably be a bottleneck, do not look any further. The intersection of Master Data
validation, integration testing and training will be 'it'. You will need a very realistic workload estimate and resources workload
planning to avoid Key Users being schedule 24 hours of work per day.
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 back to the basic rule, this kind of project takes time,
and the best way to minimize it, is to plan for it correctly from the start. You will have no other choice than spreading the
data migration workload throughout the entire project.
Complaisance planning will just make a long project longer, sometimes much longer and always a lot more expensive. Trying
to go too fast, with insufficient resources and unrealistic planning, is the basic recipe of most horror story you hear about
SAP implementations.

There is no such thing as a free lunch
This is a simple methodology, but simple does not mean easy. Doing things right the first time is an investment, and like any
investment, it has a cost (money, people, time) to be paid before you get profits. No free lunch here.
You will need discipline, lots of it. Do no pile up or delay solving of conversion issues. Better to slow down, cut your loss
and figure out how to resolve problems, than trying to keep going the wrong way.
To reach the point where the result is be bigger than the sum of the parts, you must finish each step at 100% before starting
the next one. Expediting, bypassing or neglecting a task will have a negative effect further down the road, which will
eventually create important delays.
Data migration takes time and no technological gadget or guru will make this otherwise. There is no 'easy does it' way to do
the data migration… but some paths are easier path than others.

1.2 DATA CONVERSION GUIDELINES
Think SAP
Forget your actual system and understand SAP. First, get familiar with the SAP business process you will be implementing.
Then, according to the SAP process needs, establish the Master Data requirements. Finally, see what can be salvage from
your legacy system.
Think SAP, do not try to fit in your old system into it.
Prepare the Legacy data
Clean the data on your legacy system. It is easier to start from a sound legacy system than trying to fix inconsistencies during
the conversion. Delete obsolete data and fix data discrepancy. These two steps are called data purging and data cleansing.
This can be done without specific knowledge of SAP and can begin way before the project Kick Off.
Before the last test run, take into account the customizations of your new system
Because both the organizational structure and the actual customizing influence the data you transfer for Business Objects,
finalize all customizations before the last test run. Customizing changes after the final transfer may result in additional
required fields. It can also invalidate the loaded data, which leaves you with an incoherent data set that will be difficult to
correct after Go Live.
If there is a last minute change in SAP customizing, no matter how small it is, you must retest the loading of all business
objects… been there done that, and without a re-testing following a last minute customizing change (2 days before go live),
we would have failed to proceed with the data migration on go live day.
Reduce the amount of historical data to be transferred
If your system has lot of historic data, think about archiving data. There is no need to spend large amount of money to keep
live data that are otherwise used sporadically and could very well be stored in an archive database.
Large set of historical data will add a strain on your SAP implementation and will make the data conversion more difficult.
Also, because data tend to be less accurate when they where created a long time ago, it increases the risk of having inconsistent
data when extracting from the LS.
Prefer the use of control reports
Data entered in SAP should be checked using control reports instead of looking directly in the database. This will make it
easier for the Key Users and stakeholders.
Small is beautiful
Start small. The first time you transfer data, begin with a few records of a Business Object. This way, you learn how the
program works. After transferring some records successfully, try transferring a larger amount of data. Make sure that you
transfer each different type of data before you transfer on a larger scale.
Play it safe
Do a system backup (or client copy) after transferring a significant amount of data. The backup allows you to secure a specific
level you have reached during the data conversion process. If you have any problems, you can return to this level, avoiding
to start from the beginning of the process.

1.3 SUGGESTED ADDITIONAL READINGS
 SAP “Data Transfer Made Easy guidebook”. It can be found on the “SAP Simplification Group” web site
 System Landscape (Landscape-II.pdf) fount on SapLabs website
 SAP Legacy System Migration Workbench (LSMW) on https://help.sap.com

SECTION 2 - ORGANIZE THE DATA CONVERSION

Data Conversion Plan
WBS
Calendar planning

2.1 OVERVIEW
This section describes the organization of the conversion. This is the first building block of your conversion process and must
be completed right at the beginning of the project. This part of the process is to be done by the project manager and the data
conversion coordinator.
2.2 DATA CONVERSION PLAN
Business Objects
A Business Object is a general category for data that defines something like material master, vendor master, stocks, orders,
purchase requisitions, organizational units, etc. The first step is identifying which Business Objects are required for your SAP
implementation.
Data type
There are three types of data involved in the migration: Master Data, transactional data, and historical data.
 Master Data. Application Master Data tends to be static. Most Master Data can be driven by the legacy applications.
Examples: vendors, customers, charts of accounts, assets, bills of materials, material masters, info records.
 Transactional Data. Transactional data is current and outstanding transaction data that needs to be captured from the
legacy system and defined to the SAP R/3 applications for business process completion. Examples: accounting
documents, open purchase orders, open sales orders, back orders.
 Historical Data. Historical data needs to be brought over from the legacy system to the SAP R/3 System for reference
purposes. Examples: closed purchase orders, closed sales orders, summary general ledger information, etc.
Data conversion plan sample

Required information to complete the conversion plan
 What Which Business Objects will be converted from the legacy system into SAP.
 Where Where are the data, which Legacy System's are involved for the extraction.
 How much Estimate the number of records to be ultimately loaded into SAP.
 How There are two aspects to be considered:
 The way data is extracted from the Legacy System
 Automatically extracted from the Legacy system without manual intervention.
 Manually filled spreadsheet
 Combination of an automatic Legacy System extraction + manual entry into a spreadsheet
 The way data is injected into SAP:
 Automatic data transfer from a flat file into SAP
 Manually entering data with online transactions into SAP
 Combination of both
The data transfer method you choose will determine the types of resources you need. For example, you may
need temporary employees for the manual data entry and programmers for writing the extraction programs.
 Who Who is involve on each Business Object:
 Key User (Functional responsible of BO conversion: Rules, manual data corrections, test, validations)
 Legacy system technical staff
 Functional consultants
 Resources for of data cleansing and purging in the Legacy System
 Programmer for the extraction
 Programmer for loading data in SAP
 Business Object Stakeholder
Knowing where the data is in the Legacy System, and which is accurate, requires the implication of different
resources from your organisation. They will need work closely together and you have to plan and secure
their availability.
This part seems easy enough. However, you will quickly see that getting a clear answer to all these questions, for all Business
Objects, is no easy task. Take the time and energy it needs to answer these questions meticulously. It will avoid a lot of
turning in circle and save you lot of time throughout the project.
Ha yes, I forgot one thing, make sure that all whose name is on the document are aware of it, understand what it mean and
approve it.

Main Business Objects sequence of conversion
- GL account Master
(Include primary cost & revenue elements)
- Profit centers hierarchy
Storage Bins
- Profit centers
- Cost centers hierarchy
- Cost Centers
Pre-Required
B O M
Purchase
info records
Condition record
- Discount
- Pricing
Routing Text
Stocks (VM)
Stocks (IM)
Open Sales Orders
Contracts
Open Purchase Orders
Open A/P
Open A/R
Opening Balances
Open Production Orders
Customer Master
Work
Centers
Vendor Master
Material Master
- Characteristics
- Classes
Optional
Internal orders
WBS elements if PS module.
- Activity types
Banks
Source lists
Sales
info records
Doc Mast
Routing / Task list

2.3 WBS ( work breakdown structure)
Why a WBS?
Estimates for a project planning must be deducted and justified from a logical process. They represent the real workload
required for the different tasks of the project. The WBS is a great tool to figure out these numbers. The goal is to get a
workload estimate for each task, without any duration or calendar consideration. Ignoring the date factor help in getting as
objective as possible. The workload is calculated in Person/Days. Whether there is one or five persons assigned to a task, the
total workload is the same. Using Person/Days will help for the next step, where you will build a calendar planning.
WBS Sample
How to
The idea is to break the project in Business Objects and then break each of these in tasks. You then proceed to evaluate the
workload required for each of these tasks. It will be much easier to get accurate and objectives numbers on small specific
tasks than on a large chunk.
If your WBS is not granular enough, your estimate is more difficult to get and will be less accurate. An error on one element
will also have a greater impact. As for progress follow-up, it will be less accurate, since any detected slippage will involve
higher number because the element is itself too big.
If the WBS is too granular, you will get lost in a forest of details and numbers. The follow-up will also be much more difficult
and it will be difficult to get the whole team to use it (too complex).
In this methodology, the WBS I suggest is middle ground between these two limits. I got the resulting WBS by trials & errors
on different projects. I think it is granular enough to be precise for efficient follow-up. Yet, simple enough for the whole team
to easily contribute in evaluating the numbers.

These guidelines will help you:
 Evaluate each task of the WBS independently, making abstraction of the other tasks. It will results in a more objective
evaluation of each task.
 It is important at this point to make complete abstraction of calendar planning or any target date. Forget when this should
be finish or how long it is expected to last. Just try to figure out the real workload needed to complete each element of
the DC process. After that, we will see how we can meet deadlines, by acting on the organization of the project rather
than "fixing up" the estimate. Starting a WBS while taking into consideration a goal to meet, as a specific date or target
total of Person/Days, will only lead to complaisance planning and get you in trouble.
Suggested WBS content for data conversion
 Business Objects (BO)
 BO name
 Functional domain responsible for the BO (conversion rules, manual data corrections, test, validations)
 Extract : Method use for data extraction from legacy
 Load: Method use to load data in SAP
 Legacy System : Identified where the data is coming from
 Volumes
 Qty of Records
 Qty of fields
 % of Data & Rules Adaptations
 Business Objects Mapping & Conversion ( For detailed information on these items, refer to section 3 )
 Purging & Cleansing
 Mapping & conversion rules
 LS Data Extraction Programs
 LSM & Load programs
 Data & Rules adaptations
 Load Unit Testing
 Extract & Load Full size
 Acceptance loads and validations
 ACCEPTANCE system Full Load & validation
 PRE PROD Full loading
 PRE PROD validation by Stakeholders
 PROD Full loading
 PROD Validation & Signoff by Stakeholders
 Total
 Total - at best (total in Person/Days of each Business Object)
 Total - most probable (total at best + 20 to 25% contingency buffer)
Are you sure?
"That much, are you sure?" This is probably the first thing you will hear when showing your WBS. In many projects, when
you get the numbers, at first glance it seams a lot of time and money just for converting data.
Well, "just converting data" is an understatement, as stated earlier this is an important part of the project. When considering
all tasks, it adds up very quickly. Just have a 2 hours meeting once a week with seven people and it will consume two
Person/Days each week throughout the project. Stretch the meeting just a little hour more than expected (sounds familiar!)

and the equivalent of a whole day of work just went by. Add to this the little informal meetings between Key Users,
consultants and DC team members, for each Business Object to convert, and it quickly adds up to a non-negligible amount.
And this is just for meetings, no tangible deliverable is produce yet.
Request to re-evaluate your WBS
Sometimes, after the "are you sure?", comes the "please re-evaluate with the Key Users & consultants". This is a very justified
request … But be careful, a WBS revision often results in trying to reduce the largest numbers by hammering them down
with various theories, while totally ignoring the smaller values.
When getting the numbers for the original WBS, you average each element. Overall, you under estimate some and over
estimate others, but the average law will make it a globally reasonable measure. However, if you start concentrating on some
numbers while forgetting others, the average law is out the window. This is why, when re-evaluating a WBS, you must
consider both the large and small values.
Here are some suggestions I give to those concerned when re-evaluating a WBS:
 Explain clearly what a Person/Day is: "let's say you have only this one task to do and you have to it do alone, how many
days will it take?".
 Explain the work to evaluate. For example, making the conversion rules means: talking about it with the consultants and
Legacy System experts, writing the first version, having meetings to answer gray areas, doing some tests for uncertain
fields, cross reading the documents and finally, some reflection time. Therefore, as you see, it is lot more than just
figuring how long it would take to write some lines of rules.
 Count everyone's time. In the above example, you must count time for you, the consultants, the LS Experts, those present
at the meetings, those doing tests, etc.
 Explain the average law I mentioned above and make sure they do re-estimate all the elements with the same scrutiny.
While some high workload tasks may be overestimated, many smaller one are probably underestimated as well.
 Avoid consideration for deadline or total workload
 Estimate each task independently from each other.
I personally went through that process. In all cases, the re-evaluation turned out with a slightly higher total effort. Mainly
because they realized there is more, small but still time-consuming tasks, which they originally forgot to take into account.
Facts to consider in you work estimate
These are pointers to help you come up with the first draft.
 If Information is spread into different Legacy Systems, it will take more time than if it all came from one system. Also
expect to have referential integrity issues between legacy systems, which must be solved before migrating to SAP.
 It is very difficult to find someone who knows all, but there is always someone who can help you on a specific task. This
is where the WBS will help, as the splitting of Business Objects in tasks, permits each one to be evaluated by someone
knowledgeable without the need of understanding the whole project.
 Take into account the number of fields you need for each Business Object. If you have no clue, take 200 for Material
Master, 100 for Customers, 100 for Vendors, 40 for BOM, 40 for Routings. These figures are what I got in average for
implementations with the modules FI, CO, MM, PP and SD.
 For BOM and Routings, if they are merged in a single structure in your LS (i.e. multilevel), count that BOM will take
double the time you originally estimated and Routing will most probably have to be done manually from scratch. SAP
is Single Level (unless it changed in newer versions), which mean that materials hierarchy is in the BOM and the
operations sequence is in the Routings.
 Material Master is huge. It requires time and energy, lots of it. On top of being a difficult one, it is the first one you will
have to do.
 It involves many of people from different domains.
 There is much to learn while doing Material Master, and this learning will bring Key Users to question the
process, which they though where well understood.

 Different domains come up with their own set of rules, which need to be put together in a single Material Master.
This will create collisions and conflicts, requiring meetings, discussions and testing before the issues are solved.
 The conversion rules are different for each Material Type and it is not always the same Key Users who have the
info for each type.
 Other than the Big Five, workload estimates are rarely linked to the number of fields.
 The following situations in the Legacy System will increase the efforts:
 Historical data that was never purge
 Inconstant data (well, no one have these in their systems, right!)
 Part of the data existing aside in Excel, Access or other non formal system
 No clear owner or manager of a Business Object in the Legacy System (then it is probably messy)
 Be conservative, in doubt, over estimate rather than under estimate. Never mind how much you investigate or know the
LS. There is always one Business Object where you will discover, at the last minute, that it just will not fit into SAP
without major, and unplanned, efforts. It is not bad luck, it just happens every time. It is bad luck only if you did not
consider it in your planning.
 If the data is not extracted from the LS, but generated manually, it will take longer. The time required is however more
predictable as manual data entry do not need programs testing and debugging.
 When you extract data automatically from the LS, it should be faster. However take into account that programming
means possible bugs.
 If you have part automatic and part manual, like "yes we can extract most of it, but need to do some adjustments in
Excel", add extra time (50 to 100% more). At first glance, this seems like the easiest way to go. It’s not, trust me, these
will be real headaches. Although it is almost impossible to avoid them, try having as little as possible of these. In all
cases, prefer maximum usage of conversion rules.
Ballpark figures
Here are some figures to give you a ballpark of the projects I worked on. These are not absolute figures, as they vary from
one project to another.
In projects involving the modules FI, CO, MM, PP and SD, where we have from 20 000 to 40 000 material master items,
with related BOM and Routings, about 2 000 vendors/customers, 10 000 inventory records and all other basic DC stuff, it
gave me something between 500 to 800 Person/Days (if there is only one LS to get data from).
A formula to help …. Handle with care
Here is a formula for the Big Five. I came up with it when I started doing data conversion. I established it by looking back
on previous projects. I asked how many Person/Days it took in average to do each of the Big Five. This was the total time
including meetings, writing rules, programming extract/load tools, testing and updating rules, etc. Then, with the precious
help of people who had first hand experiences doing DC, we came up with a formula to calculate a first estimate.
As I went on different projects, I realized it was good enough to give me a first estimate in all cases. However, handle this
with care. This really needs to be used as a tool that will help on a first draft. You need to challenge these numbers with your
data conversion team for functional and technical tasks.
To use the formula, you will need to establish how many fields can be solved only by rules and how many need “data and
rules adaptation”. For the first draft, consider that about 80% of the fields are solved by conversion rules and 20% will need
data and rules adaptation. If the data are in bad shape in the LS, go toward 70%-30%. As you learn more about the LS further
on, these percentages get adjusted.
You can calculate as follow in the WBS:
 Mapping
Count 10 min per field (0.02 day per field) and add 1 day to the total for set up and explanations
 Conversion Rules
Count 10 rules per day (0.1 day per field)

 Data and Rules Adaptation
Count 12 seconds (~0.000416 day) per record and by field. We estimate around 20% of fields will need Data and
Rules Adaptation. The resulting formula is (number of fields x number of records x 0.000416 x 20%). You will fin
more explanations about ‘Data and rules adaptation’ in Section 3.
This formula is most pertinent for Material, Customer and Vendor masters. For BOM and Routing, the time is less
dependent on the number of fields than on the complexity of the data to extract. For those two, you can use the
formula and then add between 50% to 100%, depending on the legacy data complexity. As stated earlier, if BOM
and Routing are merged in a single structure in your LS (i.e. multilevel), count that BOM will take double the time
you originally estimated and Routing will most probably have to be done manually from scratch.
 Load Unit Testing and Extract & Load – Full Size Testing
Here we count only the time of the technical team to test and debug the extract & load tools. This also includes
investigating the error messages sources, which will be communicated to the Key Users so they can analyse and
correct the rules or customizing accordingly. The functional team efforts to solve issues is included in “Data and
Rules Adaptation”
 Load Unit Testing
Count 14 days for Material Master and between 2 to 7 days for other Master Data.
For transactional data, count 2 to 5 days.
 Extract & Load – Full Size Testing
Count 30 days for Material Master and between 5 to 15 days for other Master Data.
For transactional data, count 2 to 10 days.
For the other WBS items, it depends on the complexity of each project:
Cleansing and Purging can be best estimated by the Key Users who knows in which condition are the data (if they don’t
know, conclude they are in bad shape).
Making the extract and load programs are estimated by the technical team according to the expected complexity.
For extracting and loading data at the different steps, the technical team is the most informed to get estimates based on
the expected complexity of the programs, the data volumes and the systems performances.
For the validations and signoff, the Key Users are the one who, according to the volume of data to validate, can best
estimates the efforts required.
For Business Objects other than the Big Five, the number of fields has little to do. It is the complexity of the process, which
needs to be taken into consideration. For those, none will take less than 10 Person/Days. Use your judgment and apply
between 10 to 30 Person/Days per Business Object according to the expected complexity.
Another Business Object, which is also more challenging, is inventory. At first, it looks simple enough, but getting 100% of
the data in SAP will prove to be a challenge... if you plan to shoot less than 100%, go back to page 1 of this document. For
Inventory, count 30 Person/Days for Inventory Management (MM-IM) + up to 100 Person/Days for Warehouse Management
(WM) according the complexity of your WM system and the quality of the LS data.
If you do not have WM in your LS and want to use WM in SAP, than you are in for a ride. In this situation, consider converting
without WM and implement it later, once your system has been stable for a while in production. If you use WM in your LS
and it is not working perfectly, you cannot expect to load it correctly in SAP. You must correct it before going into SAP.

2.4 CALENDAR PLANNING
Overview
At this point, you have assigned resources in the Data Conversion Plan and estimated the charge for each of the WBS elements
in Person/Days. You must now transform this information in duration for each task, this is the calendar planning.
To do the calendar planning, using MS-Project or other planning tool, you will enter the tasks and complete it with the
following information:
 Tasks efforts in Person/Days
 Tasks dependency
 Names of the resources assigned to each task and the percentage of their availability on it
 Non working days and Holiday.
This will give you a calendar planning based on an objective workload estimate and will also permit a quick identification of
resource over-allocation, delay due to non-working time or tasks conflicts and bottlenecks.
On most conversions, the overload on Key User is always a major problem. Your Key Users will be strongly solicited right
from the beginning of the project. Keep in mind that the more you go on with your projects, the more they will be solicited
to troubleshoot problems. Their availability for data conversion will only get more difficult to secure as the project is going
on. Do not under estimate this fact in your planning.
Once you will be done with the DC calendar planning, you must integrate it in the overall project planning and do a resources
load analysis. This task is most difficult, time consuming and very frustrating (especially if you do not master MS-Project).
Calendar planning sample

MS-Project or not.
Most probably, the only planning tool you will have available will be MS-Project. Although it is a nice tool, it also has great
talent in 'auto messing-up' your schedules (make backup copies … and make them often).
My first advice is to learn the basics of MS-Project before you get into it. It will be a much less frustrating experience. Some
quick learning books can be found and are useful
Whichever tool you use must be able to give you a resources load analysis. This will be a key element of you planning.
Sequencing the tasks
Since the process between test, writing rules and extracting/loading is iterative, we should be able to do them in parallel.
However to do this realistically you would need to consider the percentage of effort on each task to be non-linear. If you get
into this, your planning will be complex and difficult to build. The solution is to avoid parallel tasks, within a Business Object,
when they share resources. Just put them one after the other so that each resource is working on only one thing at the time
for the data conversion. The exception is for Materiel Master, where each material type can be considered as a Business
object.
Experience proved that the best way to get an accurate calendar planning for the DC process, while keeping it simple enough,
is to avoid putting tasks in parallel within a Business Object.
Key Users and consultant availability to work on Master Data
When assigning Key Users and functional consultants to the Data Conversion tasks, count only 20% of their time available.
This gives you an average of the time they will be able to give you throughout the entire project. Sometime it will be less,
sometime it will be more, but overall it will be 20%.
"20%, that is only one day a week!". Yes, remember that bottleneck mentioned before. You'll see that getting this much
attention from Key Users will be quite a challenge when you get towards testing. Since you take 20% of the Key User’s time
for DC, make sure whoever is planning other work on the project, takes into account that the Key Users are available at only
80% for them.
End 'at best' VS 'most probable'
In the WBS, you estimated all the tasks as objectively as possible, which gives you the required workload “at best”. To this,
you must add 20 to 25% buffer, which gives you the “most probable” total effort and duration.
In the calendar planning, all tasks are entered with the WBS value “at best”. The end date will than be the "at best". To get
the most probable end, you need to add a single task at the very end of that planning which is equal to the WBS buffer.
For buffer, and only there, the resources allocation is 100%. Assign all Key Users to the buffer task. Do not assign support
consultants or technical team.
In reality, they will all work on the buffer, but not at 100% and there is no way to know ahead of time who will do
what. Therefore, the easiest ways to get a realistic “most probable” end date is to consider only Key Users at 100%.
For example,
 My calendar planning end on April 30th
 I had 200 days buffer in my WBS
 I have 10 Key Users
 At the very end of the calendar planning, I will add a 200 days task with 10 resources at 100%. This will translate
as a 20 days duration buffer for the Key Users.
 Now I have the most probable end date.
Throughout the project, the “official” planning will only show the “at best” end date. The buffer is for unforeseen events
when you are doing everything to meet the “at best” end date. However, believe me, it is difficult to do better than the most
probable date. This is why the possibility of ending on “most probable date” should be communicated to higher management
right from the start.

Are you sure?
"That long, are you sure?" Here we go again, the same phenomena as in the WBS will occur. Many peoples will challenge
your calendar planning. As in WBS, they will focus only on some long tasks, and ignore the big picture and possible side
effects on the overall planning caused by any change on some tasks.
Then will come the silver bullet: Fast Track planning. In short, fast tracking consist of doing in parallel tasks which where
originally schedule at different time. In IT projects, this usually translates in doing design and development in parallel.
Therefore, your programmers start the programming before the functional team figure out what is needed. Each time I saw
Fast-Track on an IT project, the result was a project taking longer than original planning, costing much more and delivering
a faulty product. I am not saying it is impossible to gain by fast tracking on an IT project, but I am still waiting to see it work
in real life.
Remember the part in the first section of this document, which stated "It takes the time that is needed." Here is the part where
this statement takes most of its sense.
Good practice
- Do not parallel the task hoping to save time. There are only 24hrs in a day and people need sleep.
- Do not forget the 20-25% margin
- Do not change the Person/Days established in the WBS, it is the most objective values you can get.
- If you need to finish a task faster, never change an end date or the workload. Changes the resources allocations to
obtain the timeframe you want … then re-validate the resources workload.
Workload analysis
Here you are, now you have to identify the resources overload and play with tasks assignation and sequencing until all
resources reach normal workload.
Once the planning is done and resources workload is realistic, you are ready to go. At this point, you will only have to identify
slippage as the project go and take corrective action before it has an impact on the project duration.

SECTION 3 - CONVERTING A BUSINESS OBJECT

Acceptance System Full Load
Pre-Production Load & Validation
Production Load & Signoff
Mapping & Conversion Rules
Extract and Load Programs
Data and Rules adaptation
Data
Purging
&
Cleansing
Extract & Load – Full Size Testing
and Data Validation
Load
Unit
Testing
Project kick-off

3.1 OVERVIEW
This section gives you information on the steps required for a Business Object conversion. Each person who is responsible
of a Business Object should read this.
Before you begin.
When working on the conversion, do not try to fit your Legacy System into SAP. Think SAP and understand it. Then you
can see what can be taken from your Legacy System. Converting to SAP, while having in mind your Legacy System process,
will lead you in the wrong path. Get familiar with your SAP Business Object. Create objects, read the on line documentation,
understand the requirements, go through your complete process. This will make the conversion easier.
Documentation of your work (mapping sheet and conversion rules)
SAP is an integrated system where Master Data has direct and indirect impacts on all process. Those impacts are not always
obvious. For this reason, all fields mapping and rules must be clearly documented, permitting cross reading and validation
among the whole functional team. Better circulation of information across all domains increase awareness of each other
reality, reducing the risk of conflicting rules and side effects between domains.
The mapping and conversion rules also provide a common language between the functional and technical teams.
Although a structured documentation process might take a bit longer at first, it will create a synergy which will eventually
make the whole bigger than the sum of the parts.
3.2 DATA PURGING AND CLEANSING
The purging and cleansing of the Legacy System will save you time and efforts. Start as soon as possible and do as much as
possible. This can be done without specific knowledge of SAP.
 Data Purging
Before transferring data from your legacy system, delete old and obsolete data. For example, you may delete all one-
time customers or those for which there where no transaction in the last two years. You can also delete unused materials.
 Data Cleansing
This process correct data inconsistencies and ensures the integrity of the existing data in the Legacy System. For example,
there are often lots of inconsistencies in Customer and Vendor address fields. You will quickly find that SAP will not let
you load address fields unless you cleaned them.
3.3 MAPPING AND CONVERSION RULES
The documentation of each Business Object will contain the data conversion rules, which include:
 Legacy sources
From which Legacy system(s) are we extracting the data.
 Extraction procedures
Document the specific steps required to extract data from the LS.
 Purging and cleansing rules
What are the cleansing steps to be taken and extraction filters to be used.
 General Conversion rules
Guidelines and generic rules.
 Fields Specific rules
Conversion rules for each SAP fields.

About the rules
Getting the conversion rules to be written by Key Users is essential to this methodology.
 Key Users must understand SAP fields usage.
 Key Users must question their Legacy System values and integrity.
 Documented rules permit a clear statement of what a Key User think. Thus permitting to identify conflicts and
misunderstandings between domains.
 Rules documents must be versioned, making change management easier.
 The rules will provide a common language between functional and technical teams.
Key Users may not be familiar with writing conversion rules. Therefore, it is necessary to give some examples and explain
the basic key elements of rules writing.
Basic properties of a rule:
 General rules vs field rules
General rules are guidelines not related to the final values of a specific field. For example, the way in which we
differentiate the material types in the Legacy System is such a rule. Field rules are specific and will be used to
get the field final values. General rules can be used as part of a field rule algorithm.
 Fields names
When discussing or writing rules, always refer to a field in the form TABLE-FIELD, which is the only way to
identify a specific field.
 There are fields, which exists in different views. Sometime it is exactly the same field, which is shown
at two places. Other times, it is really two different fields, which happens to have the same name. The
only way to differentiate them is to know from which table they come from. If they do not come from
the same table, it is not the same field.
 The field name shown in a SAP views is often different from the field name in the database, which can
lead to misunderstanding between the functional and technical teams.
 Different people will use different names for the same field. As well, they may start using the same
name for different fields.
Using the form TABLE-FIELD in all documentation will avoid these issues.
Example:
In Material Master, the field «Availability check» exist in the "MRP2" and the "Sales Gen" views. If you
look at the TABLE-FIELD of each view, you get:
MRP2 : MARC-MTVFP
Sales Gen : MARC-MTVFP
In both cases, the TABLE-FIELD name is the same, so it is the same field.
In Customer Master, the field " Terms of Payment' exist in "Payment Transactions" and "Billing" views. If
you look at the TABLE-FIELD of each view, you get:
Payment Transactions : KNVV- ZTERM
Billing Views : KNB1- ZTERM
It is not the same field as they come from different tables. In the Payment view, the field is link to
the Company Code, while for the Billing view it is link to the Sales Organization (you find this by
looking at the table’s keys). So both of these fields can have different values.
 Short and clear
Rules should be short, using IF/ELSE/END structure as much as possible.
Make certain that the use of AND, OR and ( ) is clear. A long sentence embedding many AND & OR, if not
clearly written, will lead to confusion. Do not hesitate to spread the rule on many lines, making it easy to read.
A long of text is more difficult to read and understand than a series of short lines.

 Must be clear and without ambiguities
For example:
If product is a sold semi-finished
….
End
This is not clear enough, How do we know which product are "sold semi-finished". This must be clearly
stated in the rule or be part of a general rule.
 Conversion tables
In some case, it is impossible or too complex to get some values by rules. In this situation, we use conversion
tables (usually Excel) and specify in the rule how to use the conversion tables.
In the conversion rules document, a section identifies the conversion tables and explains how to use them:
Conversion tables
Here is an example of a field rule referring to a conversion table:
IF BUYER-CODE on legacy is blank
THEN
Purchasing Group is Blank
ELSE
Locate BUYER-CODE in “Purchasing group” table to find Purchasing group
END
The Material Master challenge
Material Master involves all the domains and may require anywhere from 20 fields to a few hundreds, depending on the
complexity of your implementation. Some 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.
This is the most complex Business Object to document and, at the same time, it is the one you must start with in your
conversion process.
Material Master is key to all domains and many fields must be discovered and understood. To get that understanding from
Key Users we proceed as follow:

1st
step: Selection of the fields by each domain
Get each domain with their consultants to go through the mapping file and look at the fields for each material type.
The goal here is to find which fields will be needed, requiring from the Key Users to ask questions and understand
their purpose. This is done separately 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 to convert them.
Each time a domain select a field for a specific material type, they must enter their domain under the type in the list.
Here are some examples of mapping from MM, PP and SD
Example of fields selection by each domain
What to do when the same field is found in different views
In Material Master, some fields can be entered and modified in different views. For example, the field
“Goods receipt processing time in days (MARC-WEBAZ)” exists in views Purchasing, MRP2 and Quality
management.
When doing the rules and the load program, the same field can’t be in different views. To solve this, proceed
as follow:
See with all implicated domains and decide who will be the owner of the field.

Taking the example of the field “Goods receipt processing time in days (MARC-WEBAZ)”, it can
be decided among the domains to put it in the Purchasing view (and nowhere else). This means the
Purchasing Key User is the field owner. Other domains still can use it and have their own specific
rules for it. However, it is the Purchasing Key User role to make sure this field is used correctly
and validate if there are conflicts among the different domains rules.
Be careful, make sure it is really the same field.
In Customer Master, the field " Terms of Payment' exist in "Payment Transactions" and "Billing"
views. If you look at the TABLE-FIELD of each view, you get:
Payment Transactions : KNVV- ZTERM
Billing Views : KNB1- ZTERM
They come from different tables, it is not the same field. In the payment view, the field is linked
to the Company Code while in the Billing view, it is linked to the Sales Organization (you find
this by looking at the tables keys). So both of these fields can have different values and different
owners.
SPECIAL MULTI VIEWS
In can however happen that no specific domain can be identified as the lead or main user of a field.
Let’s take for example, “MM/PP status (MARC-MMSTA)” which is in views: Purchasing, MRP1, Work
scheduling, Costing 1, Quality Management.
If no one can be clearly identify as the lead for that field, then we put it in a dummy view called “SPECIAL
multi views”. This is used to put all the fields which exists in different views and for which we can’t assign
a specific owner.
2nd
step: Regroup selection of all domains in a single document
Once this is done for each domain, the DC manager put all domains mappings in a single document.
It will show all the fields/domain dependencies and identify fields which will have conversion rules from different
domains (put the field owner first).
Example of fields selection grouped for all domains

3rd
step: Build the data conversion rules template with all the selected fields.
In the previous step, we established which fields of the Material Master will be use in SAP. Now we build the data
conversion rules template, which we will use to write the conversion rules.
There is one line for each field/type combination. Specify, for each field/type, which domain selected it. If more
than one domain selected the same field/type, put the name of all concerned domains (put the owner first).
Data conversion rules template sample
4th
step: Get the rules from each domain, independently
Ask each domain to specify the conversion rules for all the fields they are concerned with. This is purposely done
independently for each domain, so that misunderstanding or conflicting rules between domains may be put in
evidence in the next step.
5th
step: Merge the rules from all domains.
Make a single document containing all the functional domain's rules and specify, for each rule, which domain wrote
it.
6th
step: Analyse the results and start building the Issues list.
At this point, I create what I call the QUESTIONS LIST. It is a simple MS-Word document where I put all the
questions I have after reading the rules. I document the question, name of who is responsible for the solution, creation
date and target solution date.
Prepare yourself for a very long list at first. I usually end-up with an average of two questions per field. Therefore,
if you have 300 fields, that is 600 questions. Most of these are unclear rules or obvious problems, which are easily
solved within the first week.
What usually happens at this stage is rules conflict. It happens when more than one domain use the same field and
they come up with contradictory or incompatible rules. Finding this at the beginning of the process will be a great
time saver, as you just identified important issues between domains, before you developed anything. One of the main
challenges of implementing SAP is integration of the different functional domains into a single product. Failure to
understand this is will get you into trouble. This is true for the whole SAP implementation project, not just the Data
Migration.

After one or two weeks, once most questions are solved, the QUESTIONS LIST becomes the data conversion
ISSUES LIST, logging all unanswered questions. From now on, any questions, decisions and actions assignments
are documented in the ISSUES LIST.
You now have the Material Master conversion rules documented, plus an ISSUES LIST, to follow up on the issues to be
solved before you start programming.
Material Master conversion rules sample
All other Business Objects
For the other Business Objects, because they are simpler than Material Master, we do not need a specific field selection
template. The field selection step is still done before writing the rules, but we do it with the conversion rules template.

Business Objects conversion rules examples
BOM conversion rules sample
Open Account Receivable conversion rules sample
(NOTE: In this example, PRMS is the name of the Legacy System)

Vendor Master conversion rules sample
Example of general rules
ID RULE
G000 Note that SAP term “Security deposit” equal “Retention” in PRMS
G001 Type of transaction
TYPE field in PRMS:
Partial PMT: “Pay.”
Credit Memo: “Cr M.”
Debit Memo: “Dr M.”
Invoice: “Inv.”
Non A/R cash: “Non AR”
Adjustments: “Adj”
Any other type is an error.
G002 Validation to apply both at extraction and load.
Partial PMT………. must be negative in PRMS, if not ERROR
Credit Memo………must be negative in PRMS, if not ERROR
Debit Memo……….must be positive in PRMS, if not ERROR
Invoice……………..must be positive in PRMS, if not ERROR
Any other type is an ERROR.
G003 LSM Load parameters
KTOPL - Chart of account: CA00
BUKRS – Company code: 0070
GSBER - Business Area: 0040
BUDAT – Posting Date: “05-31-02” or last day of last closed period.
OFFSET – Account (2): REPRISECL
SKPERR – Skip err: X

Directory organization
As you go, you will end up with lots of documents and versions. To store the different files on your server, use a specific
directory structure. I suggest having a structure with a directory for each Business Object to store all the files relevant to the
data conversion. Here is an example.
C:.
├─ Data Conversion
│ │
│ ├─── 00 - Organization
│ │ │ DC PLAN
│ │ │ DC WBS
│ │ │ DC SCHEDULE
│ │ │ < Here, keep only the latest version of each document >
│ │ │
│ │ └───── Old
│ │ < Store here previous versions of above mentioned documents >
│ │
│ ├─── 01 - Material Master
│ │ │ Material Master - Field Selection Sheet.xls
│ │ │ Material Master - Data Conversion Spec.doc
│ │ │
│ │ ├───── Old
│ │ │ < Store here previous versions of above mentioned documents >
│ │ │
│ │ └───── Working Files
│ │ < Put here various working files >
│ │
│ ├─── xx -BO name
│ │ │ BO - Data Conversion Spec.doc
│ │ │
│ │ ├───── Old
│ │ │ < Store here previous versions of above mentioned documents >
│ │ │
│ │ └───── Working Files
│ │ < Put here various working files >
Change management: working in batch mode
As the project goes, rules will change. This is certitude. As you get closer to Go Live, changes occur faster and will require
a quicker reaction time.
When programming and testing the rules for a BO, we work in batch. This means we will do V01 of the rules, validate them,
close the version, program it and test it. If changes are required at any point after we close the version, they will be documented
in V02 and we finished programming and complete testing of V01 (V01 Batch). If there are bugs on the V01 load, they will
be analysed and correction will be documented and applied to the V02.
Considering the stress on the whole project team and the overall load on all members near Go Live, there is a real danger to
loose control here. One way to stay on top of things, while keeping a quick reaction time, is good change management.
Although it may sometime feel frustrating for Key Users and the technical team to go through versioning & batch mode, it
will ultimately be the best way to go fast without breaking something else, which already works (regression).

Version management of conversion rules
Here how it goes:
 Creation of the first version V01
 Freezing version V01
 Once everyone agree that V01 is OK (functional and technical staff), freeze the version.
 Password protect V01, so no one changes it afterwards
 Make a copy of V01 as V02
 In V02, activate MS-Word change tracking
 Put V01 in the "Old" directory
 Unprotect V02 (This is where we start the new version)
 From now on, any change to the rules must be done in V02, do not change V01
 Development and testing of V01
 Ask the technical team to work on V01 and only on V01.
 Once V01 is programmed, load it and ask the functional team to validate.
 If there is a bug requiring rules changes, all corrections must be entered in V02.
 Freezing of V02
 Once everyone agree that V02 is OK (functional and technical staff), freeze the version.
 Password protect V02, so no one changes it afterwards
 Make a copy of the document as V03
 In V03, accept all changes so that there is no visible change.
 In V03, activate MS-Word change tracking (should already be on)
 Put V02 in the "Old" directory
 Unprotect V03
 From now on, any change to the rules must be done in V03.
 Development and testing of V02
 Ask the technical team to work on V02 and only on V02
 All changes between V01 and V02 are visible through MS-Word change tracking.
 Once V02 is programmed, load it and ask the functional team to validate.
 If there is a bug requiring rules changes, all corrections must be entered in V03.
 And so on …
If you are not familiar with MS-Word change tracking, I suggest you get acquainted with this functionality.
Murphy's protection: Save it often and do rolling backups.
You will be working with Excel and MS-Word (using change tracking). These are nice tools but they can go wild and scrap
your documents. This is mostly true with large documents.
So save often and make backups of all your Data Conversion documents. I usually keep a 7 days rolling backup of all my
files somewhere on a local PC to protect me from MS-Office bad behaviour as well as network failure … and human error.
Be certain of two things:
 If you have many large MS-Office documents, at least one of them will get corrupted during the project. It always
happens.
 It also always happens that someone mess-up a document, usually the most critical one.
If you are in doubt, please refer to Murphy's Law.

3.4 EXTRACT AND LOAD PROGRAMS
The rules document has sections for “Legacy sources and extraction procedures” and “Purging and cleansing rules”. This
should explain what to clean/purge, what to extract and how to proceed. If there is ambiguity or incomplete information in
the specs, solve them before you do any programming. This will prove to be a time saver later on.
3.5 TRANSFORMATION BETWEEN THE EXTRACTION AND LOAD
Most data need transformation between the extraction from the Legacy System and the load in SAP. These can be done at
extraction time, as an intermediary step or at load time. There is no good or wrong here and any combination is valid. What
you must avoid is to spread the transformation in too many places, which makes debugging and finding the sources of issues
more difficult.
My preference is as follow:
 Cleansing and filters are applied at extraction
 Data transformations are made at load time.
 Exceptionally, for very complex transformations, it is done as an intermediary step between the extraction and
the load. However, I do try to avoid this as much as possible.
3.6 DATA AND RULES ADAPTATION
This is the most time consuming part of the conversion process. It is also the most difficult and can be very frustrating for the
whole SAP implementation team. The path you took, in the preceding steps of the methodology, is design to deal with the
issues and difficulties you will face at this point.
At this stage, the team start programming the rules and test them. The first tests will reveal programming bugs and obvious
rules issues. As the process go, the tests will be done with full data sets and many rules issues will come up. The high number
of issues may be a bit discouraging at first. However, a lot of them are inter-related, and solving the root issues will solve
many linked issue. Most will be solved quickly.
The remaining issues will be the most difficult to solve. To find solutions, the functional team will need to review their
process and possibly change customizing. This, in turn, may affect other Business Objects process and customizing,
sometimes on process and conversions which where already tested successfully.
Having many simultaneous changes to customizing and conversion rules, combined with the interrelations between the
Business Objects, create a “pool break effect”, where you have balls going in all directions at the same time. This is where
having clear rules, a solid change management process, a team working in batches and the discipline to stick to the
methodology, will yield the biggest results. Although all the ingredients for chaos are present, you will stay in control. This
is where the whole gets bigger than the sum of the parts.
Here are some useful guidelines:
1. The Business Object Key User is the one writing and updating the rules as well as been accountable for the
conversion result.
2. When something needs a change, it must be clearly documented and validated in the specs.
3. The technical team will develop programs according to the rule. If it is not in the rules, it does not exist. So if you
do not see what you need, get it documented.
4. Have the discipline to manage change by versioning the documents and stick with working in batches.
5. It is better to take your time to do it correctly the first time rather than rushing it. Results will initially be slower to
come, but you will eventually progress faster and faster. Problems accumulate in a snowball effect, so does success.
6. The most common error I saw on projects that failed, is trying to save time by working on new solutions without
taking time to document, cross read and validate the conversion rules. They sure are getting output quickly this
way… but are they going in the right direction?

3.7 LOAD UNIT TESTING
Here 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 types
without error. We are more concerned about going through the load cycle without SAP stopping us, rather than validating
the correctness of the values. We use a small volume of data, usually creating them manually from scratch, rather than using
real extracted data.
The kind of issues you usually encounters at this point are:
 Programming errors in the load programs
 Some mandatory fields are missing
 Some dependency between two fields where not considered and you can’t load as expected
 There are invalid rules
 Using a load program, SAP did not behave as you expected (it sometimes behave differently with a load tool than it
does with manual data entry)
As mentioned earlier, the conversion process is iterative. Following the issues you’ll find here, you will have to go back to
the functional Key User, find solutions and document them in the specs.
3.8 EXTRACT & LOAD – FULL SIZE TESTING AND DATA VALIDATION
Once the unit testing of the load programs is done, we start testing the extract from LS and load in SAP with data volume.
You can start by partial data set, like only one Material Type, and progress toward the full data conversion for each Business
Object.
Here we want to know if we can load the real data for a Business Object, as well as validating the results once loaded in SAP.
The issues found are addressed by the Key Users and solutions are documented. We are still working in batch mode with
rules versioning. It is important to validate results in SAP. The values, validated at an intermediate level of the extract/load
cycle, may become incorrect once loaded in SAP. As for the challenges you will encounter here, they where described earlier
in the “DATA AND RULES ADAPTATION” section.
3.9 ACCEPTANCE SYSTEM FULL LOAD
In the previous step, we successfully loaded all Business Objects and had them validated with the real data extracted from
the Legacy. However, depending on the landscape you used, different BO may have been validated in different clients and
the customizing for the testing environment may not be clean.
We do the acceptance full load once we are done with testing and solving issues for all Business Objects. Here, we want to
start from a clean client (as close to production as possible), apply all transports, do the extract load cycles of all Business
Objects and get a validation signoff from the functional team. At the end of this step, you must have successfully loaded data
in SAP, for all Business Objects, and have them fully validated.
For ACCEPTANCE SYSTEM, Key Users drive the validation of each Business Objects, with the implication of the
Stakeholders. The key Users must sign the acceptation for each Business Objects
3.10 PRE-PRODUCTION AND PRODUCTION LOAD & SIGNOFF
Pre-production load is a dressed rehearsal of the production load and is done with an exact copy of the production
environment. What is done in pre-production must be exactly what will be done in production.
At this point, customizing is finished for the entire project, everything was validated in ACCEPTANCE and we are ready to
go in production. It is essential you did the full load and validation of all Business Objects in the previous step. While you
can easily correct bugs in dev, it is difficult to correct them in pre-prod and almost impossible in production after Go Live.
Because the production system is living its own life and can’t be controlled as in dev, correcting Master Data errors in
production is like shooting a moving target … the more you try to fix it, the more you seems to break everything around it. I
have seen projects with corrupted BOM data in PROD, even after a year of trying to fix it. Since BOM affect Costing,
Manufacturing, Inventory, Purchasing, etc. you can imagine in which condition their SAP got after a while.

Since you went through all the steps and followed all the methodology guidelines, the rest is just formality.
 You do a full load in pre-prod, in an exact copy of prod and do everything exactly as you will do in prod
 You get the whole thing validated by the BO’s Key Users and the BO’s Stakeholders
 Get written signoff from the BO’s Stakeholders (insist to have it written, not verbal)
 Do the final production load and get final signoff (insist to have it written, not verbal)
 Finally you have nothing else to do, as by following this methodology, you managed to accurately load 100% of the
Master Data and no rework is needed (yes, this happens for real)
Here are some useful guidelines:
 Unless there are major errors, do not change any extract/load programs to correct minors errors found in Pre-prod
test cycle. It is better to do the correction immediately after loading in production (manually or by programming).
This way you do not induce regression into the extract/load process, which may corrupt data loaded in the production
system.
 If there are major errors found in Pre-prod test, you must step back to “Extract & Load – Full Size Testing and Data
Validation”.
 When it is time to load in prod, do exactly as you did in pre-prod.
For PRE-PRODUCTION, Stakeholders drive the validation of each Business Objects, with the implication of the Key Users.
The Stakeholders must sign the acceptation for each Business Objects
For PRODUCTION, Stakeholders are making final validation and signoff for each Business Objects.
3.11 SUGGESTIONS ON THE DATA CONVERSION LANDSCAPE
When you start the loading and validating cycles, each Business Objects will be at different levels and they will progress at
different speed. This will create an issue when it is time to refresh an environment to start a new “extract, load and validate”
cycle.
Here are the most common conflicts:
 PP will be making corrections to BOM and Routing, so they need to reload them.
 FI-CO will be doing costing runs and are directly affected by BOM and Routing, so they need to freeze them.
 The rest of the team will be making corrections to the other Business Objects and are not ready for a refresh.
A solution is to use three SAP clients organized like this:
1. A Client for PP working on BOM and Routing
2. A Client for FI-CO working on costing
3. A Client for all the other BO’s been worked on

CONCLUSION
Now you know how I did different Master Data migrations faster and better than others did. I successfully used this
methodology in different industries and countries.
The methodology itself is mainly a mix of good old common sense and management 101. Each step is the foundation of the
next one. Complete each step at 100% and the next one will be easier. The result is a snowball effect, permitting you to gain
more speed from step to step. Not following this rule will also have a snowball effect, but in the opposite direction, reaching
a point where the conversion process becomes out of control.
Although it may sometimes look to others like you are taking the long route to get there, remember that the objective is not
to finish a specific step ASAP. The goal it is to complete the whole process in the best time possible and to deliver a complete
set of Master Data, which will not need rework once in production.
The main challenge you will face it is to overcome:
 Pressure to show rapid results (any results)
 Tendencies to push forward issues so we can keep progressing
 Resistance to follow the versioning process and associated work in batch mode
 Refusal to slow down when the process begin to get out of hands.
This is how I managed to keep my head above the water, even when everyone else seems to be in a crisis.

APPENDIX A – VARIOUS TEMPLATES
The following documents are attached to this PDF file:
1 - Conversion plan template.doc
2 - WBS template.xls
3 - Material Master - Fields selection sheet template.xls
4 - Data conversion specification - Generic template.doc
5 - Data conversion specification – BOM template.doc
6 - Data conversion specification – ROUTING template.doc
7 - Materials Classes and Characteristics structure.ppt
I included this, as it may be useful to understand, and explain, the structure of the Materials Classes and
Characteristics.
The documents are included as comments, click on the paperclip to open the files.
You can also see them as attachment : In the horizontal menu, click on “View”, “Show/Hide”, “Navigation Panes”,
“Attachments”.

APPENDIX B –License
Creative Commons Attribution-ShareAlike 4.0 International Public License
By exercising the Licensed Rights (defined below), You accept and agree to be bound by the terms and conditions of this
Creative Commons Attribution-ShareAlike 4.0 International Public License ("Public License"). To the extent this Public
License may be interpreted as a contract, You are granted the Licensed Rights in consideration of Your acceptance of these
terms and conditions, and the Licensor grants You such rights in consideration of benefits the Licensor receives from
making the Licensed Material available under these terms and conditions.
Section 1 – Definitions.
a. Adapted Material means material subject to Copyright and Similar Rights that is derived from or based upon the
Licensed Material and in which the Licensed Material is translated, altered, arranged, transformed, or otherwise
modified in a manner requiring permission under the Copyright and Similar Rights held by the Licensor. For
purposes of this Public License, where the Licensed Material is a musical work, performance, or sound recording,
Adapted Material is always produced where the Licensed Material is synched in timed relation with a moving
image.
b. Adapter's License means the license You apply to Your Copyright and Similar Rights in Your contributions to
Adapted Material in accordance with the terms and conditions of this Public License.
c. BY-SA Compatible License means a license listed at creativecommons.org/compatiblelicenses, approved by
Creative Commons as essentially the equivalent of this Public License.
d. Copyright and Similar Rights means copyright and/or similar rights closely related to copyright including,
without limitation, performance, broadcast, sound recording, and Sui Generis Database Rights, without regard to
how the rights are labeled or categorized. For purposes of this Public License, the rights specified in
Section 2(b)(1)-(2) are not Copyright and Similar Rights.
e. Effective Technological Measures means those measures that, in the absence of proper authority, may not be
circumvented under laws fulfilling obligations under Article 11 of the WIPO Copyright Treaty adopted on
December 20, 1996, and/or similar international agreements.
f. Exceptions and Limitations means fair use, fair dealing, and/or any other exception or limitation to Copyright
and Similar Rights that applies to Your use of the Licensed Material.
g. License Elements means the license attributes listed in the name of a Creative Commons Public License. The
License Elements of this Public License are Attribution and ShareAlike.
h. Licensed Material means the artistic or literary work, database, or other material to which the Licensor applied
this Public License.
i. Licensed Rights means the rights granted to You subject to the terms and conditions of this Public License, which
are limited to all Copyright and Similar Rights that apply to Your use of the Licensed Material and that the
Licensor has authority to license.
j. Licensor means the individual(s) or entity(ies) granting rights under this Public License.
k. Share means to provide material to the public by any means or process that requires permission under the
Licensed Rights, such as reproduction, public display, public performance, distribution, dissemination,
communication, or importation, and to make material available to the public including in ways that members of
the public may access the material from a place and at a time individually chosen by them.
l. Sui Generis Database Rights means rights other than copyright resulting from Directive 96/9/EC of the European
Parliament and of the Council of 11 March 1996 on the legal protection of databases, as amended and/or
succeeded, as well as other essentially equivalent rights anywhere in the world.
m. You means the individual or entity exercising the Licensed Rights under this Public License. Your has a
corresponding meaning.

Data migration methodology for sap v2

Data migration methodology for sap v2

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Data migration methodology for sap v2

Similaire à Data migration methodology for sap v2 (20)

Dernier

Dernier (20)

Data migration methodology for sap v2