Bob Panic: +61 424 102 603 E: bobpanic@outlook.

com

SAP Data Migration – Planning and Operational Guide – Quick Reference Guide (extract) By Bob
Panic, Principle Data Lead, Solution Architect

Covers: Material Master, Customer Master, Vendor Master, Bill Of Materials (BOM) and Routings.

Common Terms:

Business Objects : To help in the analysis and transfer process, the data is not treated as tables
or field contents but rather as objects in term of business operational. These are called Business
Objects.

Business Object DC responsible : Responsible of the conversion process (Legacy data source
and integrity, mapping, conversion rules, etc.) and for the respect of the planned schedule for
his Business Object.

Business Object Owner : The one that owns the information in the every day business. This is the
person that will make the strategic choices on functional requirements for the business object
and that will do the final validation of the converted data. Can be identified by finding “The
highest hierarchical person who will be directly and mostly affected if the business object does
not work”

Data Conversion & Data Migration : The data conversion process. “Data conversion DC” and
“Data Migration - DM” terms are used interchangeably in the document.

Flat File : A file format used to import data into SAP. The flat file is a plain text file with a tab
separator between fields. It can be easily generated from Excel or Access.

Intermediate file : An Excel, Access or other type of file, which is manually manipulated in a
process between the LS extraction and the flat file generation.

LS : Abbreviation for Legacy System

LSM or LSMW : Legacy System Migration Workbench. It is a SAP tool for conversion that permits
data loading using flat files extracted from the Legacy System.

Transcodification Table, Cross reference 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.

WBS : Work Breakdown Structure.

Data Conversion

Known Chalenges with Data Migration Projects

 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 converted data.
 Data previously loaded with success is suddenly rejected by SAP.
 There is a lot of misunderstanding, friction and frustration between the functional and
technical team.

 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 just will not get in at all, they will have to be entered after GO Live.

 After Go Live (post go Live Review)

 Some Data need to be corrected & entered after Go Live. Because the production
system is now living, data are moving targets. This makes the process difficult and time
consuming …. This translates into a costly operation.

 Planning and resources load estimates where way out (when they existed).

 Most of the problems encountered are actually functional issues.

 Information does not travel well between functional and technical team. As we get
near the Go Live, this becomes much worst.

This methodology was made to solve these issues.

Philosophy VS techniques

 do things right from the start and solve issues as they occur.
 Take the time that it requires to do thing properly and thoroughly.
 No expediting, no bypassing of steps, no piling of unsolved issue to keep going.
 Get things right on the fist time

A few facts

 Issues and problems you will encounter in the conversion process will be functional.
 Expect challenges with the extract / load process
 In general part between the extract and the load that is the most difficult.
 Getting the right data at the right place with the values required for business processes is
always a functional problem.
 SAP master data is an integral part of this process - 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 behavior of the process. If you change customizing,
your master data may become incomplete or incorrect.
 Data conversion is complex and should be done as early as possible in the project cycle

Conversion rules and business object ownership

 make the Data Conversion 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
 Data owners (key business stakeholders) must be identified and the business has the
responsibility and ownership of the Mapping and conversion rules. It is ‘their’ master data and
they will do mapping & rules documents.
 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, their brain 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.
 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 - written decision which
required thinking about it and assuming responsibility for it.

Again, take the time that it gets to have clear and unambiguous DC rules. When the spec has no
ambiguity and has been cross read and validated by all domains and the technical team, and only
then, can you start the development of the extract and load programs. That will be the point where
will start picking up speed, lots of it.

Main steps of the conversion methodology

The main steps of the data conversion are:

 Organization of the data conversion (Project manager & data conversion coordinator)
 Data conversion plan
 The WBS with workload estimates
 The calendar planning with resources loading

 Going on with the Business Objects data conversion (The resource responsible of the Business
Object Data Conversion)
 Data Purging and Cleansing
 Mapping and conversion rules
 Extract and Load Programs from rules
 Data and Rules Adaptation (adjusting rules and programs following testing)
 Load Unit Testing (unitary testing - small volume of manual data)
 Extract and Load Full size testing (data test and validation - large volume with real extracted
data)
 Full data loading into ACCEPTANCE SYSTEM
 Full data loading into PRE PRODUCTION SYSTEM
 Validation of converted data and Key User + Business Objects Owner Signoff
 Full conversion into PRODUCTION SYSTEM and final Signoff
Main Concerns:

 Bandwith: 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 user, master data issues are solved by key users …. In addition, when you start validating
master data, it is usually that time where key users are out giving training.
 The intersection of Master Data validation, integration testing and training will be a bottleneck.
 develop realistic workload estimate and resources workload planning to avoid key users being
schedule 48 hours of work per day.
 this kind of project takes time and the best way to minimize it is to plan for it correctly. You will
have no other choice than spreading the load throughout the entire project.
 You will need discipline, lots of it. Do no pile up delay or issue.
 Better to slow down, cut your loss and figure out how to resolve problems than trying to keep
going the wrong way.
 Expediting, bypassing or neglecting a task will have a negative effect further down the road,
which will eventually create important delays.

Note: If the final data set is not accurate and well structured, your computer will bring you back to
reality the hard way.

DATA CONVERSION GUIDELINES

Think SAP
 get familiar with the SAP business process you will be implementing. Then, according to the SAP
process needs, establish what the Master Data requirements are. Then, and only then, see
what can be salvage from your legacy system.

Prepare the Legacy Database

 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 make the rest of it
coherent. 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. It will save you a lot of time.

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, this requires
preparing and transferring more data.
 It can also invalidate the loaded data, which leaves you with an incoherent data set that will
be very costly to correct after Go Live.

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 data set due to non-archiving of your LS will add a lot of strain on your SAP
implementation and will make the data conversion more difficult because of the volume. Also,
because data tend to be less accurate when they where created a long time ago, it will be
much more difficult to adapt them to SAP.
Use controls edition in SAP
 Data entered in SAP should de cheked using some control reports. This is especially useful for
manual data entry and transactional data.

Start Small
 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.

Be wise
 The full data integration in your production system is the end of the process and should mostly
be a technical operation where we push some buttons to get some results. To reach this goal,
it implies that all functional and technical issues where dealt with before starting the full size
transfer from the Legacy System.
 The hard work is in the mapping and establishment of conversion rules from the old to the new
system. That is where you will make or miss your conversion. Don't even think about loading
large volumes into production if you are not completely ready.

Play it safe
 perform 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, and you do not have to begin
the process all over again.

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

 “Quick Reference Guide LSMW (How to …)” and “Presentation of LSMW”. Can be found on web
site http://service.sap.com/lsmw It require a user name a password

PLANNING FOR DATA CONVERSION

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 or organizational units. The first step is identifying which
business objects are required in your SAP implementation.

Data type
There are three types of data involved in a SAP system: master data, transactional data, and historical
data.
 Master Data. Application master data tends to be more static once defined. Most master data
can be driven by the legacy applications. Examples include vendors, customers, charts of
accounts, assets, bills of materials, material masters, info records, and so on.
 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 include accounting documents, open purchase orders, open sales orders,
back orders, and so on.
 Historical Data. Historical data needs to be brought over from the legacy system to the SAP R/3
System for reference purposes. Examples include closed purchase orders, closed sales orders,
summary general ledger information, and so on.

Data conversion plan sample

Information to complete in 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 your own extraction programs. You need to know both what
data is in your legacy system and which SAP applications correspond to the business
objects that will be transferred. One person does not have to know all of this, but the
people who know this information should work closely together.

 Who Who is involve on each Business Object :

 Key user (Functional responsible of BO conversion : Rules, manual data corrections, test,
validations)
 Consultant
 Responsible of data cleaning and purging in the Legacy System
 Responsible of the extraction
 Responsible of loading data in SAP
 Business Object Manager (Hierarchic owner who is responsible of day to day use and
integrity of information and the one which will be signing off for data acceptance )
Main Business Objects sequence of conversion

Pre-Required
- GL account Master
(Include primary cost & revenue elements)
- Profit centers hierarchy
- Profit centers
- Cost centers hierarchy
- Cost Centers
- Characteristics
- Activity types - Classes
Optional
Internal orders
WBS elements if PS module.

Material Master

Work
Centers
Banks

Doc Mast

Customer Master Vendor Master

BOM

Purchase
Condition record Sales
info records
- Discount info records
- Pricing

Routing Text Source lists

Routing / Task list

Storage Bins
Open A/P Stocks (VM) Contracts
Open A/R Stocks (IM) Open Production Orders
Open Purchase Orders
Opening Balances Open Sales Orders