Data Migration From Legacy To SAP R3

Data Migration from various Legacy Systems to SAP R/3
By
Geoffrey Warriss
MSc in Information Systems
1999/2000
The candidate confirms that the work submitted is his/ her own and the appropriate credit
has been given where reference has been made to the work of others
Summary
The MSc project is being undertaken, within a live implementation of the leading ERP software
SAP R/3 at AETC Ltd. The project is defined as 'Data Migration from various Legacy systems to
SAP R/3'.
The aim of the project, is to identify the data migration techniques in SAP R/3 as well as the
accompanying legacy systems at AETC Ltd, and analyse these and the methods used in
implementation. The following list of objectives has been generally defined to facilitate the
achievement of the project;
1. To undertake a comprehensive study of the SAP R/3 system (a review).

2. To study the current Legacy Systems from which AETC Ltd are extracting data.
3. To examine the issues of Data Transfer from manual to automatic.
4. To evaluate the current process of Data Migration within the SAP R/3 system.
5. To draw conclusions on Data Transfer/ Migration from Legacy systems to SAP R/3.
The report is divided into Six Chapters with the addition of various Appendices to support the
material within the sections, as well as providing a comprehensive reference list.
Chapter 2 satisfies the first objective and provides an overview of the SAP R/3 system. It identifies
what SAP is, what it offers, the structure, functionalities, architecture and the methodologies used.
Chapter 3 identifies the legacy systems in use at AETC Ltd, and what if any characteristics they
provide for effective migration to the SAP R/3 system. This chapter fulfils the second objective.
Chapters 4 and 5 outline the process of data transfer and migration within SAP R/3. They identify
the issues involved, with migrating data from legacy systems and the methods adopted. Chapter 4
investigates the various transfer techniques that are available within SAP, looking primarily at the
Legacy System Migration Workbench tool and its associated interfaces. These complete the third
and fourth objectives.
The final Chapter draws together relevant conclusions from the previous chapters, and highlights
the overall issues that need to be identified when data migrating.
i
Acknowledgements
There are a multitude of people that I need to thank for their assistance and advice that they have
afforded me, throughout both this project and the course.
I must in the first instance express my gratitude to everyone on the AETC SAP Implementation
Team, who were extremely helpful and cooperative in providing support, advice and the necessary
information, that has allowed me to complete this report. In particular, I would like to thank Peter
Cawtheray for sharing with me his comprehensive knowledge and for his supervision. A special
thanks also go to Richard Breen, once again for his in depth knowledge and generosity in providing
help and answers to my constant questions and Andrew Norvell for his depth and talents of ABAP
and the use of his increasingly expensive time.
In addition I would like to express my gratitude to Patrick McIlroy for identifying a possible project
at AETC Ltd. Simon Keay (SAP UK), SAP LSM and the Simplification Group who have been
extremely helpful in providing information. Vasco Madeira a man who has incredible focus and
self-management. Chris Dove for his incessant wit and professionalism. Martin Watmough and
Andrew Payne for there helpful direction and broadening knowledge of PP, Neil Webster, Derrick
Mkandla, David Holmes, Roger Thornton, Mike Foster, Mick Prest, Iain McClure, and the rest of
the SAP Team. Being involved with them all has been a very rewarding privilege.
A sincere thanks must also go to Professor Dyer for his experienced guidance and knowledge to the
completion of this report.
I would also like to thank my newfound friends and colleagues from across the globe for being
supportive and such genuine people, Kiran, Evangelo, Salvo, Owen, Ferry, Bola, Raj.
These acknowledgements would not have come to fruition without the support, both financially and
morally throughout my education, from my parents, Brian and Joan Warriss and to my brothers
Simon and Robin, who have provided the much needed motivation, wisdom and knowledge.
Finally I have a debt of gratitude to thank the sport of Cricket, the season starts when you need it
the most. The game has allowed me to release all my stress and frustrations unfortunately not
enough on the opposing teams.
ii
List of Abbreviations
Abbreviation Meaning
ABAP Advanced Business Application Programming

API Application Programming Interface
ASCII American Standard Code for Information Interchange
ASP Application Service Provider
ATM Asynchronous Transfer Mode
BAPI Business Application Programming Interface
BI Batch Input
BMF Blade Machining Facility
BOM Bill of Material
CATT Computer Aided Test Tool
CL Command Language
DI Direct Input
ERP Enterprise Resource Planning
HR Human Resources
IBM International Business Machines
IDOC Intermediate Document
IPCS Integrated PC Server
IPX Inter-network Packet Exchange
LSMW Legacy System Migration Workbench
MAPICS/ DB Manufacturing Accounting and Production Information Control System/ Database
MRP Material Resource Planning
NCR Non Conformance Reporting
NGV Nozzle Guide Vane
PCC Precision Castparts Corporation
PCF Precision Casting Facility
ROF Repair and Overhaul Facility
RPG Report Program Generator
SAP Systems, Applications and Products in Data Processing
SAP GUI SAP Graphical User Interface
SME Small & Medium Sized Enterprises.
SNADS Systems Network Architecture Distribution Services
SQL Structured Query Language
SXDA Standard Data Transfer – Transaction code
VAR Value Adding Reseller
WFMC Workflow Management Coalition
iii
List of Figures & Tables
Fig No. Description (Reference) Page
1 Principal Modules within SAP (Scapens et al, 1998) 4

2 The Family of SAP R/3 Modules (Hernandez, 1997) 5
3 ASAP Roadmap - Fast Track Implementation (Accelerated SAP, 1999) 7
4 The Phases of Data Migration (Hudicka, 1999) 19
5 Flow Chart of Transferring Business Objects (SAP Labs, Inc, 1999) 21
6 Table of Characteristics ISO 9126:1991 (ISO/IEC 9126:1991, 2000). 29
7 The LSM Workbench Process (R/3 Simplification Group, 2000) 30
8 Steps in LSM Migration Process (R/3 Simplification Group, 2000) 31
9 ABAP Workbench Screen – Version 4.5B (SAP AG, 1999) 32
10 ABAP Functions in detail (SAP AG, 1999) 32
iv
Contents Page
Title Page
Summary …………………………………………………….. i
Acknowledgements ………………………………………….. ii
List of Abbreviations ………………………………………... iii
List of Figures & Tables …………………………………….. iv
Contents Page ………………………………………………... v
Project Development ………………………………………... vii
1.0 Introduction …………………………………………………. 1
2.0 A Review of SAP R/3 ………………………………………... 3 – 11
2.1 SAP AG ………………………………………………… 3

2.1.1 Market Position …………………………………. 3
2.2 What is SAP R/3? ………………………………………. 4
2.3 What does SAP R/3 offer? ……………………………... 4

2.3.1 Modules ………………………………………….. 4
2.3.2 Integration ……………………………………….. 5
2.3.3 Configuration & Customisation …………………. 6
2.3.4 Advantages ………………………………………. 6
2.4 Opportunity for Improvement ………………………….. 7

2.4.1 Standard SAP ……………………………………. 7
2.4.2 Methodologies …………………………………… 7
2.4.3 Investment ……………………………………….. 8
2.4.4 mySAP.com ……………………………………… 8
2.4.5 Application Service Providers …………………… 8
2.4.6 SAP Business Partners …………………………... 8
2.4.7 Risks, Opportunities and Weaknesses …………… 9
2.5 Functionalities ………………………………………….. 10
2.6 Summary ……………………………………………….. 10
3.0 Legacy Systems at AETC Ltd ……………………………… 12
3.1 The AS/400 …………………………………………….. 12

3.1.1 Business Information ……………………………. 13
3.1.2 Kronos …………………………………………… 13
3.1.3 UniPay …………………………………………… 14
3.1.4 MAPICS …………………………………………. 14
3.1.5 Other System ……………………………………. 14
v
3.2 Legacy Problems ……………………………………….. 15
3.3 Architecture of the Legacy Systems ……………………. 15
3.3.1 Open Standards ...………………………………... 15
3.3.2 Integration ……………………………………….. 16
3.3.3 The AS/400 and SAP R/3 ……………………….. 16
3.4 Transfer Programs ……………………………………… 17

3.4.1 Transfer Program Interfaces ……………………... 17
3.4.2 Data Structures …………………………………... 18
3.5 Summary ……………………………………………….. 18
4.0 Data Transfer ………………………………………………... 19 – 27
4.1 Methodologies ………………………………………….. 19

4.1.1 Dulcien Inc ..……………………………………... 19
4.1.2 ASAP Methodology ……………………………... 20
4.2 SAP Data Transfer ……………………………………... 20
4.3 Analysing Data …………………………………………. 21

4.3.1 Types of SAP Data ………………………………. 21
4.3.2 Issues with Data Transfer ………………………... 22
4.3.3 Problems with Data ……………………………… 22
4.3.4 Data Cleansing & Purging ………………………. 23
4.3.5 Data Source Structures …………………………... 24
4.4 Electronic Vs Manual …………………………………... 25

4.4.1 Transfer Methods ………………………………... 26
4.5 Legacy System Migration Workbench …………………. 26
4.6 Summary ……………………………………………….. 27
5.0 Data Migration within SAP R/3 ……………………………. 28 – 36
5.1 Evaluation Characteristics .……………………………... 28
5.2 Legacy System Migration Workbench (LSM) ..……….. 29

5.2.1 How the LSM Works ……………………………. 30
5.2.2 Import Interfaces ...………………………………. 31
5.2.1.1 Batch Input (BI) …………………………. 31
5.2.1.2 Direct Input (DI) ………….……………… 32
5.2.1.3 Intermediate Documents (IDOC) ………... 32
5.2.1.4 BAPI …………………………………….. 32
5.3 ABAP Workbench ……………………….……………... 32
5.4 Computer Aided Test Tool (CATT) ……..……………... 33
5.5 Tool Similarities ………………………………………... 34
v
5.6 Evaluation Results ……………………………………… 34
5.7 Summary ……………………………………………….. 36
6.0 Conclusions ...………………………………………………… 37 - 38
References
Appendices
A Project Experience.
B Objectives & Deliverables.
C Marking Scheme & Interim Report Header Sheet.
D ASAP Documentation.
E SAP Data Transfer Matrix.
F Business Object Transfer Programs.
G ISO 9126: 1991 Software Evaluation
H Legacy System Migration Workbench
vii
Project Development.
Project Concept.
It was decided that to obtain an overall understanding of the implementation and the SAP R/3
system, a live project involving Data Migration would be appropriate, as it has consequences
throughout the whole business system. This was duly accepted, as the potential future employment
benefits from being involved with a live SAP implementation will be invaluable.
The project has entailed being initially trained to use the data migration tool, the Legacy System
Migration Workbench (LSM), researching the details of AETC's Legacy systems and the elements
involved in data transfer within the SAP R/3 system.
Module Appreciation.
I have been able to gain a wide breadth of knowledge much quicker from the project due to the
structure of the MSc modules I have taken and the content of them. The modules that have been
very relevant to the project were in the main Business Process Re-engineering, Business
Information Systems, Information Modelling, Information Systems Engineering and Distributed
Information Management.
Project Management.
The project objectives were highlighted and a project plan was developed, generally as follows,
Project Objectives.
Title: DATA MIGRATION FROM VARIOUS LEGACY SYSTEMS TO SAP R/3.
Initial aim?
To identify the data migration techniques in SAP R/3 as well as the accompanying legacy systems
at AETC Ltd, and analyse these and the methods used in implementation.
The following tables represent the requirements for each objective. As can be seen I have defined a
column for the information requirements, the desired completion date and fully completed date.
v
OVERALL OBJECTIVES:
• To undertake a comprehensive study of the SAP R/3 System (a review).
Area/ Content Info Comp Date Completed

What is SAP? 07/07/00
What is its position in Market Place for ERP? 07/07/00
What does it offer? Integration with modules etc 14/07/00
What are its functionality’s? Portability, etc. 14/07/00
Architecture of SAP? 14/07/00
Methodologies etc? Solutions, Best Practice? 14/07/00
Changes to company practises? Importance of using standard SAP? 14/07/00
Identification of possible risks and opportunities for improvement? 14/07/00
• To study the current Legacy Systems*, i.e. AS400 system, Kronos, etc, from which AETC
are extracting data.

What legacy systems are being migrated from? 19/07/00
Architecture of legacy systems? Is there a link with the SAP R/3 20/07/00
system?
What transfer programmes are available? 21/07/00
How do these Programme dumps for data, interface with other 21/07/00
systems?
Is the data transfer consistent in the legacy system? Transfer error in data. 21/07/00
Quality of DBMS? What are its pros/ cons. 21/07/00
• To examine the issues of Data Transfer from manual to automatic.

What factors have to be taken into account when migrating data? 04/08/00
Data cleansing/ purging: what, when, how and why? 08/08/00
Why is it costly when implementing a new system? 08/08/00
Data Transfer for business objects:
1. Identify fields.
2. Analyse legacy data.
3. Map legacy data to R/3.
4. Prepare legacy database.
5. Transfer data. 10/08/00
• To evaluate the current process of Data Migration within the SAP R/3 system.

What migration techniques are available? Study each and test with various 17/08/00
sets of data.
What are the differences between each? 24/08/00
Is there a limit to the data they can take? 24/08/00
Are there possibilities for improvements? 24/08/00
• To draw conclusions on Data Transfer/ Migration from Legacy Systems to SAP R/3.
To complete by the 31/08/00 *- With reference to AETC Limited.
v
The tables were used to initiate targets and milestones, so that information could be confidently
obtained and the objectives could be satisfied successfully.
Initial Project Schedule.

The project schedule was defined at the start of same and has been adjusted to accommodate
variations as and when they arise.
07 Feb '00 20 Mar '00 01 May '00 12 Jun '00 24 Jul '00
ID Task Nam e S W S T M F T S W S T
1 Draft Interim Report
2 Full tim e on Project

3 Project Planning
4 Study SAP R/3 System, inc background reading
5 Evaluating Legacy Systems for data migration

6 Examine issues of Data Transfer
7 Evaluate current process of Data Migration
8 Conclude on Data Migration from Legacy Systems
9 Write up Project
Re-Plan.
May June July August
ID Task Nam e 07 14 21 28 04 11 18 25 02 09 16 23 30 06 13 20
1 Draft Interim Report
2 Full time on Project
3 Project Planning
4 Study SAP R/3 System, inc background reading
5 Evaluating Legacy Systems for data migration
6 Examine issues of Data Transfer
7 Evaluate current process of Data Migration
8 Conclude on Data Migration from Legacy Systems

9 Write up Project inc Re-writes
The above project schedule was more conducive to working on what is, by its application, a flow
process, i.e. the initial objective provided an all round understanding of the possibilities and allowed
the ongoing objectives to be satisfied as appropriate.
vii
1.0 Introduction.
The project topic was not a defined internal MSc project, but was very relevant to the Information
Systems perspective. The possibility of undertaking a project with AETC Ltd (an ex employer of
the author) was highlighted through management contacts at the company.
AETC Ltd is an Investment Casting company that specialises in the manufacture of components for
the hot section of the Gas Turbine Engine. They supply such companies as Rolls Royce, Pratt &
Whitney, ABB and GEC, with components for both Aerospace and Industrial markets.
The project will focus on the Data Migration to the ERP system, SAP R/3, from a number of legacy
systems, as implemented into a live roll out at AETC Limited. The company at the time of writing
is implementing R/3 into its facilities, as a pilot for the roll out to its American parent company
Precision Castparts Corporation (PCC). SAP R/3 is to replace the existing legacy systems namely
the IBM AS/400, which has become a bespoke and inflexible system and therefore has become
increasingly expensive to maintain.
The aim of the project is to identify the data migration techniques in SAP R/3 as well as the
accompanying legacy systems at AETC Ltd, and analyse these and the methods used in
implementation. To initiate the process a number of objectives were defined to facilitate the
achievement of the project, they are listed as follows;
6. To undertake a comprehensive study of the SAP R/3 system (a review).

7. To study the current Legacy systems from which AETC Ltd are extracting data.
8. To examine the issues of Data Transfer from manual to automatic.
9. To evaluate the current process of Data Migration within the SAP R/3 system.
10. To draw conclusions on Data Transfer/ Migration from Legacy systems to SAP R/3.
The report is divided up into Six Chapters with the addition of various appendices that support the
material within each, as well as providing a comprehensive reference list.
Chapter 2 is designed to satisfy the first objective and provide an overview of the SAP R/3 system,
highlighting the background to SAP, as well as identifying the technical aspects associated with the
system.
v
Chapter 3 is aimed at satisfying the second objective by the identification of the legacy systems in
use at AETC Ltd and what if any characteristics they provide for effective migration to the SAP R/3
system.
Chapter 4 and 5 outline the process of data transfer and migration within SAP R/3. Identifying the
issues involved with migrating data from legacy systems and the methods adopted. Chapter 4
investigates the various transfer techniques that are used within SAP, looking primarily at the tool,
the Legacy System Migration Workbench and its associated interfaces.
The final Chapter draws together conclusions from the previous chapters, and highlights the overall
issues that need to be identified and addressed when data migrating, as well as the SAP R/3 tools
used for data transfer.
v
2.0 A Review of SAP R/3.
This chapter introduces SAP R/3 by describing the structure and functionalities of SAP and in
addition, the architecture and methodologies that SAP follow in implementation.
2.1 SAP AG.
SAP is an Integrated Business system that has evolved from an original concept, first developed by
five former IBM German systems engineers in 1972. Twenty eight years later, the company has
developed into the industry leader and fourth largest independent software company, providing
enterprise wide solutions, that integrate the processes within enterprises and among business
communities.
SAP™ stands for Systems, Applications and Products in Data Processing. SAP AG is a worldwide
company based in Walldorf, Germany. The company has pioneered the development of ERP
(Enterprise Resource Planning) software systems in the client/ server market, with 1999 revenues of
∈5.11bn and almost 23,000 employees (SAP AG Annual report,1999, www.sap.com)
SAP AG has developed three very distinctive and powerful software products in the ERP market,
these being R/2 (for Mainframe computing), R/3 (for Client/ Server computing) and mySAP.com.
All three are integrated systems with the latter two being e-business enabled via the Internet.
2.1.1 Market Position.
SAP AG was the largest listing in terms of market capitalisation on the New York stock exchange
at $70billion. The boom continued by 1999 it held 32% of the ERP market (Tapsell, 1999).
SAP holds a superior standing with the Fortune 500 companies, the following lists these (Tapsell,
1999);
6 of the top 10 use SAP.
7 of the most profitable use SAP.
9 of the top 10 with the highest market value use SAP.
7 of the top 10 Pharmaceutical, Computer and Petroleum companies use SAP.
6 of the top 10 Chemical companies use SAP.
8 of the top 10 Electronic and Food manufactures use SAP.
v
This demonstrates the extent of the SAP software and customer spread across industries worldwide,
it's not just the large multinationals that can afford to implement SAP. SAP is now targeting small
to medium sized companies in order to expand their markets and knowledge.
2.2 What is SAP R/3?
SAP R/3 is an integrated Enterprise Resource Planning system. It comprises a set of business
modules that are designed from industry 'Best Practice' techniques. The software is built to operate
in the client/ server market, which is where the business logic can be held either on the server or
partly on the client, depending on the circumstances (www.sap.com, 2000).
SAP uses relational tables and adopts transactional processing to present information to the user
(Blain et al, 1997). The required data is keyed in or inputted automatically from peripheral
equipment, i.e. a bar-code scanner, and is transacted in the background, within the database server
via the application server (if a 3-Tier architecture is utilised). It is then presented in the SAP user
interface for its required use.
2.3 What does SAP R/3 offer?
2.3.1 Modules.
SAP R/3 provides a complete set of integrated applications, referred to as modules. These are
developed around industry best practice by SAP and cover most business functions. They include
the following:
Finance and Accounting: This includes Financial Accounting, Controlling Assets management
and a Project System.
Human Resources: This involves the full set of capabilities required to manage, schedule, pay and
hire human resources.
Manufacturing & Logistics: This is the most complex function and comprises the largest set of
modules, including materials management, plant maintenance, quality management, production
planning & control and Project Management.
Sales & Distribution: This function provides customer relationship management, sales order
management, configuration management, distribution, shipping and transportation management.
Fig 1, Principal Modules within SAP (Scapens et al, 1998)
vii
The array of R/3 products are shown in the SAP matrix as follows,
The figure represents how the R/3

system is structured, i.e. the R/3 system
is client/ server based with the
integrated modules residing on the of
R/3 database.
Fig 2, The Family of SAP R/3 Modules (Hernandez, 1997)
2.3.2 Integration.
Bancroft et al (1998) argue that there is no other comparable product available in the market place,
that satisfies the company wide set of totally integrated solutions as well as R/3. The global take up
of the system and as a result SAP's market leadership, appears to satisfy this observation.
A fully integrated system, means that each module can access other business modules (depending
on the information structure of the database tables) and provide real-time information on any aspect
of the enterprise. As a result SAP has stated that companies should re-engineer their business
wherever needed, so as to reduce the possible consequences in other modules (as data is integrated
and used elsewhere in the system). Scapens et al (1998) reiterates this by recognising that most SAP
implementations are accompanied by business process re-engineering.
SAP R/3 is most effective when it is applied within a manufacturing environment, although it is
also applied within the service and sales sectors. A company that has a top down structure (i.e.
Hierarchical) is said to be better suited to SAP R/3 due to the structure of the software itself
(Scapens et al, 1998).
vii
2.3.3 Configuration & Customisation.
SAP R/3, although designed around industry best practice solutions, still has to be adapted to the
particular needs of the business. With most companies there needs to be a major development phase
involving not only configuration and re-engineering, but customisation of the generic package.
There is a risk that customisation can become problematical and due to the expertise required, very
expensive. By modifying the standard software package into a ‘bespoke’ system, a different set of
issues are created, e.g. future SAP releases will require modification and SAP’s expensive
involvement. Bancroft (1998) and Macmillan (1998/99) support this view, as there is a possibility
of ‘hot patches’ and updates to SAP not functioning on the customised system.
Although customisation is in theory not an advisable road to take, in reality, a company may have to
undertake some customisation, after they have configured each module to its full capabilities. There
are however SAP R/3 versions called Industry Solutions that come pre-configured and customised.
These have been targeted at the SME market (Manufacturing Computer Solutions, 2000).
2.3.4 Advantages.
Once SAP R/3 is installed there are many elements within the package that can be 'turned on' to
improve productivity and automate many processes, such as ‘Workflow’. This will be discussed in
the next chapter.
Giles Farrow who is Reporting Systems Manager at Guinness Ltd, explains that SAP manages to
produce many positive benefits, through the design of the system of transaction processing, which it
does brilliantly (Durban, 1999).
The major benefit of implementing SAP R/3 is the reduction in overall costs that are generated from
not having to maintain the separate legacy systems. (Scapens et al, 1998). The legacy system
concept and implications will be discussed in the next chapter.
One of the most quoted examples of legacy system numbers is that of Owens-Corning Fiberglass
corporation in Ohio (they were one of the original SAP customers in America). They identified that
prior to the implementation of SAP they estimated they had 200 legacy systems across 80 sites.
Once SAP was introduced the legacy systems were reduced to less than 10 and the year on year cost
benefits were considerable (Lienert, 1996).
vii
2.4 Opportunities for Improvement.
2.4.1 Standard SAP.
Because SAP does not customise a system to a client’s needs, it forces business processes to be
tightly integrated across applications and across departments, ensuring corporate wide consistency
of information (Lienert, 1996).
To gain the necessary benefits from R/3 and the support of SAP, keeping as close to the standard
package as possible is very important. SAP is continuously updating their modules in order to
become more flexible in operation and more user friendly. A result of this is mySAP.com, which
takes advantage of the Internet as a communication tool.
It is very apparent to the author, from both reading and active involvement in actual in site system
preparation, that the implementation of SAP R/3 requires superior skills in managing the process
and the ongoing business. The system being a standard package also requires high quality, cross-
functional communication and a supportive organisational structure.
2.4.2 Methodologies.
AETC are using SAP’s Accelerated SAP methodology which is a process-oriented (rather than a
task-oriented) approach to implementation. It details all the elements within an implementation and
is defined on a ‘roadmap’, which are self-explanatory. The roadmap is split into five sections and is
shown below (more detail in Appendix D),
Phases of ASAP.
1. Project Preparation - Initial
planning and scoping of project
objectives.
2. Business Blueprint - Detailed
documentation of results from
project preparation & refine
goals.
3. Realisation - Implement business
process requirements from
Blueprint. Implement system,
Test and configure. Includes
development of data migration
steps.
4. Final Preparation - System
testing, end user training and fine
tuning.
5. Go Live & Support - Move from
pre-live to a live operation,
Fig 3, ASAP Roadmap - Fast Track Implementation (Accelerated SAP, 1998). including end user support.
vii
2.4.3 Investment.
SAP invests a great deal into systems development. This has placed SAP in the position they are in
today and the position they will surely maintain in the future. The package itself comes with many
software development tools, including the ABAP/4 Development Workbench, the Legacy System
Migration Workbench (LSM) and other integrated tools. The LSM is an addition to R/3 that allows
the conversion and transfer of legacy data from the legacy systems, making the whole process of
migration far more efficient and controlled. The R/3 data dictionary stores every modification,
update or deletion of any data or programme, which is used in SAP.
2.4.4 MySAP.com.
SAP employs 5,400 software developers (www.sap.com, 2000). With the launch of mySAP.com,
they are developing the e-business solution for companies as well as improving certain modules and
incorporating extra functionality. The strategy is to embed and improve new concepts such as
Knowledge Management and Customer Relationship Management. Geraldine McBride who is SAP
New Zealand MD states that the aim is to give companies predictive knowledge to make future
decisions (Tapsell, 1999).
2.4.5 Application Service Providers.
Macmillan (1998/99) claims that most companies feel a fully adopted enterprise wide solution is far
cheaper than the development and maintenance of a bespoke (legacy) system. It seems that in the
new millennium companies are out-sourcing their complete IT infrastructure to ASP (Application
Service Providers), a new phenomenon that is being born with the Internet. As these virtual
businesses operate and maintain an organisations applications, it is said that this isolates the users
from technology changes (Ranger, 2000). Giga Information Group states that companies should not
use ASP's for ERP's, however BT has been providing a service for certain modules within SAP R/3
for two years. SAP has launched their very own ASP called SAP Hosting in February of this year
(www.sap.com). This, however, is an issue that would be an interesting area for future projects.
2.4.6 SAP Business Partners.
SAP's growth has come through a partnership between various companies within varying sectors of
business. SAP provide resources for a total implementation. However this route tends to be an
vii
expensive option. Initially once a SAP product is chosen, it is handled through a VAR (Value
Adding Reseller). The VAR is a SAP certified company that provides all the consultancy needs for
the installation of each module (defined by the package the company decides to purchase).
The other elements of the implementation partnerships include Platform and Hardware services, the
Integration of new technologies, database and operating systems. The final partnership provides the
addition of upgrades to the SAP software.
2.4.7 Risks, Opportunities and Weaknesses.
Risks
Bancroft et al (1998) states four possible risks with SAP R/3, these are based around technology,
flexibility, complexity and corporate strategy.
SAP is a standalone system that is based on 1980’s client/server technology. Because of this there
has been an alleged slow take-up. Bancroft et al (1998) argue that this is not the case as there have
been no recent developments in this technology and therefore no other comparable integrated
system. This appears to be the case, as only Oracle seems to be a close competitor.
SAP R/3 solutions are designed around American best practices and can therefore be difficult to
implement worldwide, which is significant, when re-engineering your business is part of the
implementation, as this usually involves a huge change in culture.
In the authors view implementing SAP R/3 is very complex, involving very detailed work plans and
schedules to assure a smooth and well executed cross over. It requires fundamental changes in
technology, business processes, management structures and job functions. Bancroft et al (1998)
states that the sheer scale of an implementation can overwhelm a SAP implementation team. This is
the main reason why SAP provides a VAR to offer a solid grounding of understanding that is vital
if the installation is to be successful.
SAP in all probability will not fit easily into a company’s corporate strategy and culture. Due to its
flexible integration capabilities, the many changes and configurations are almost always undertaken
successfully, allowing it to merge efficiently into the companies operations.
vii
Opportunities
There are many opportunities to be gained by implementing SAP, from the integration of business
processes and having a reduced number of legacy systems to maintain to the reduction in overall
operating costs. These advantages can easily outweigh the objections to implementation.
Weaknesses
As mentioned SAP is designed for transaction processing. However Giles Farrow (Durban, 1999)
admits that its design principles for information management are completely reversed. Farrow
highlights the fact that extracting meaningful data from SAP R/3 for business decisions is very
difficult, and is due to R/3’s uniquely constructed tables. The only viable option is to obtain the
services of an ABAP programmer to customise (previously deemed to be a bad idea) the interfaces
and pull the information from the required tables.
2.5 Functionalities.
SAP R/3 gains all its functionality, i.e. the integrated modules and the adaptability in the
configuration of them, through its Open Architecture structure and Portability. According to the
SAP 50 Basis Training Guide, the outstanding feature of the components, is the combination of up
to the minute technology with comprehensive business functions. The high level of application
integration ensures that all functions can be accessed directly through the system and therefore by
the user (SAP AG, 1998). This is achieved by the integrated relational database.
The Open architecture that SAP adopts also makes it fully compatible with most software and
hardware. It also enables interfacing through various standard protocols and networks, this is where
SAP gets its tag of ‘Guaranteed Portability’. These are combined in their own level, above which
the system components are independent of the hardware and software environment (SAP AG,
1998).
2.6 Summary.
SAP is a German company that develops the leading integrated Enterprise Resource Planning
software. SAP R/3 is an integrated modular business process reengineering ERP, which can be fully
configured and customised only if absolutely necessary, as customisation is an expensive option.
SAP has many business partners that can support a customer's implementation from start to finish
and throughout the life of the software. MySAP.com is the latest ERP software from SAP and is e-
vii
business enabled. SAP R/3 has an open architecture where it is platform independent and cross
functional in every aspect.
vii
3.0 Legacy Systems.
‘Legacy systems are the information resources currently available to the organisation. They include
existing mainframes, personal computers, serial terminals, networks, databases, operating systems,
application programs and all other forms of hardware and software that a company may own’ (SES
Software Holdings Limited, 1995). This also includes any paper systems, e.g. manually indexed
systems.
AETC Limited operates their business processes on the industry standard, IBM AS/400 server
system. They initially adopted same because of its tried and tested excellence in hardware and
software integration, i.e. it comes complete with operating system, database software and system
management tools, etc. There is therefore no need to source these essential components from
different vendors.
3.1 The AS/400.
IBM’s AS/400 is the world’s most popular multi-user business computer, with over 600,000 sold in
over 120 countries. It's installed in 98 percent of the Fortune 500 companies and is enabled in 49
languages (IBM Corporation, 2000). IBM sells on average 50,000 units every year and has become
the first choice for any level of enterprise (Midrange Computing Editors, 1997).
The AS/400 runs on the renowned OS/400 operating system that has more than 28,000 licensed
applications and 3,500 client server applications, developed to run on it (Midrange Computing
Editors, 1997). The software programs are written in the AS/400 language, RPG (Report Program
Generator) and can be accessed via IBM’s CL (Command Language). The 400 can also run a
variety of Java and Windows NT software components.
AETC’s AS/400 system has been customised over the last 14 years and has consequently become a
bespoke system. The market and competition in their field of business, is ever demanding and
changing, and so requires the business system to either change with it or be able to provide the
necessary information, that allows the company to make accurate decisions. As a result certain
elements of the software components have been developed to suit their particular business and
operational needs.
vii
Within AETC four AS/400 units are operated. They run particular elements of the business, e.g. the
Payroll system is called UNIPAY from Rebus. One is dedicated to the business functions of the
company, and another is configured to hold their Time and Attendance system from Kronos. They
also have an AS/400 at their Leicester site that runs an ERP system called MAPICS.
3.1.1 Business Information.
The main AS/400 server holds all the central AETC business information (for BMF, ROF, NGV
and PCF) from Manufacturing information, to Human Resources information to Payroll
information. For HR and Payroll, the information is taken from Kronos and Unipay respectively,
these are AS/400 compliant software programs.
Manufacturing information includes such things as Part numbers, Operation Routings, Materials
used, Work in Progress, Costs, Vendors, Customers and so on. Human Resources information is all
aspects involved with employees, from Name and Address to Next of Kin and Job Function.
3.1.2 Kronos.
AETC uses the Kronos TimeKeeper/ AS system for Time & Attendance, but will expand its use for
Job Booking (i.e. employee time is accounted for against various jobs that are carried out, which is
required for costing). The TimeKeeper is an integrated solution for proactively managing your
organisation’s most valuable and expensive resource, employees (Kronos Incorporated, 2000).
The system's base application provides a foundation upon which other integrated modules make up
the midrange market's most powerful, most flexible solution for frontline labour management. This
allows an organisation to make real-time decisions by managing labour resources proactively and
more efficiently (Kronos Incorporated, 2000).
The system is specifically written in RPG/ CL so it can operate on the OS/400 platform. The data is
recorded via Swipe Cards through Terminals, but requires manipulation in the payroll system to add
value. This added value takes place through transferring the data, as the data has to be ‘formatted’
so the Unipay system can make use of it. A Flat-File (ASCII) is created through an RPG program
and transferred by an IBM function called SNADS (Systems Network Architecture Distribution
Services). This uses an API that communicates the exchange of data via the IPX protocol. This is
the standard communication function used to communicate between AS/400’s.
vii
3.1.3 Unipay.
Unipay is also written in RPG and receives data from Kronos via the SNADS function, it can then
interpret the data and calculate the relevant information for every employee.
3.1.4 MAPICS.
MAPICS/ DB (Manufacturing Accounting and Production Information Control System/ Database)

is an ERP software that is capable of operating on the AS/400 and is used at the company’s
Leicester Site (NGV), where machining of pre-assembled Nozzle Guide Vanes, as well as
machining of raw castings, is carried out.
The MAPICS system is queried and accessed using CL via the standard AS/400 interface.
3.1.5 Other Systems.
There are other business systems that are separate from the AS/400, but are still critical to the
operation of the business. Operational procedures are such systems that are crucial to standard
organisational practice. The information relating to these systems includes documents such as
Standard Practice Instructions or Production Planning Sheets. They are stored not on the AS/400
but on Windows NT Servers and are vaulted by file name, therefore the filename is the only key
identifier. The software used for this is called Data Ease (this has now been phased out and has been
removed from the system) (Breen, 2000).
The company also uses Lotus Notes software for email etc, but will be utilising it further for its
capabilities in Workflow. The Workflow Management Coalition (1999) define this as the
automation of a business process, in whole or part, during which documents, information or tasks
are passed from one participant to another for action, according to a set of procedural rules. There is
a Workflow module within SAP that could be used to automate the approvals of purchase
requisitions.
Lotus notes however, will be interfaced to SAP, and will use workflow for a process called Non
Conformance Reporting (NCR).
vii
3.2 Legacy Problems.
There are a number of problems that have been highlighted with regard to the effectiveness of the
current Legacy systems. The main points are that they either do not hold the necessary data for
accurate business decisions (i.e. the data is obsolete and inaccurate) or that the information available
has to be manipulated to become value adding to the company. When one considers, e.g. the
traceability & quality audit trails required in the aviation industry, then obviously the existing
system has its inherent weaknesses.
The biggest problem facing the company with regard to their legacy systems is that they have
limited integration between each other (Breen, 2000), this seems to contradict the IBM philosophy.
Having a bespoke system that also runs external software like Unipay and Kronos for Payroll and
some HR functionality, means that some data is constantly repeated. If a new employee is added to
the AS/400 human resources system, it then has to be replicated into both the Kronos and UniPay
systems. This can lead to many problems including incorrect input of data, a possibility of missing
data or no data at all in a particular system.
3.3 Architecture of the Legacy Systems.
The AS/400 system holds the majority of the legacy data, and it is therefore necessary to compare
the architecture of the legacy to the SAP R/3 architecture and expose any similarities that may aid
in migration.
3.3.1 Open Standards.
The AS/400 uses a unique layered architecture that enhances its integration with other hardware and
software. This is defined within IBM’s ‘OPEN’ Blue print. Ricke (2000) describes the structure of
the blueprint as a guide that helps its users choose the technologies and products needed to create a
solution. In effect it provides a technology independent base for system design, where there are no
restrictions.
The openness of the system is enhanced through a number of features such as TIMI (Technology
Independent Machine Interface), this sits between the applications and the hardware. It allows for
hardware independence.
vii
3.3.2 Integration.
The AS/400 is the champion of client/ server technology and uses the DB2/400 relational database
as its database server for the OS/400 operating system. The AS/400 has all the functions required,
which are fully integrated into the system, such as system management as well as communication
and network protocols (TCP/IP, SNA and ATM, Token Rings, Ethernet respectively). It uses an
object-orientated architecture to store and retrieve information, where an object represents a table
(IBM Corporation, 2000).
The OS/400 runs on 64-Bit RISC processor technology and uses a single level storage system (i.e.
both memory and disk storage are treated as one virtual address space), these also add to the
AS/400’s high integration factor (IBM Corporation, 2000).
The AS/400 client/ server capability also allows for platform independence, which gives it the
possibility to operate within Windows, Unix, OS/2 and Macintosh, and connection through
numerous communications protocols (Powers, 1999).
3.3.3 The AS/400 and SAP R/3.
Dawson (1998) identifies a number of similarities and elements that make SAP R/3 and the AS/400
so compatible. Firstly there is the object-oriented nature of the SAP application and its
accompanying language which bonds well with the object oriented architecture of the 400 and the
RPG language.
The objects in the AS/400 are used to store data in Physical files or tables, this is also how SAP is
structured and based. Both are accessed using a form of SQL that has been modified to suit the
particular language, but still uses the standard syntax.
SAP has been developed to be platform independent (i.e. Open technology), i.e. it is designed to run
on Windows and Unix servers, as well as many relational databases (SAP R/3, 1999/2000). The
SAP GUI can operate across the board on Windows, Unix, Macintosh and OS/2 workstations. The
AS/400 is also platform independent due to its range of client communication software (Powers,
1999).
vii
The major similarity involves the functional aspect of each, the AS/400 is fully integrated and SAP
is a total environment application (i.e. Programming Language (ABAP/4), Editor, Change
Management, Database, Data Transfer, etc) as stated by Dawson (1998).
3.4 Transfer Programs.
The AS/400 has a number of programs that can be used in migrating data. It would be prudent to
investigate the transfer programs available. Firstly the AS/400 has a standard Query Report Writer,
which uses SQL type commands to access tables and can output to a screen, printer or to file.
Windows NT is the choice of platform that runs AETC’s Microsoft products and Lotus Notes
software, which is also designed for a server environment, through an IPCS (Integrated PC Server)
formerly FSIOPS as described by Hirsch (1995) and Ahn et al (1998). The AS/400 uses a particular
transfer program for the PC environment called Client Access.
Client Access integrates the AS/400 with the clients and provides a great deal of functionality in
connection to obtain business information, applications and resources across the enterprise (Hutt et
al, 1998).
3.4.1 Transfer Program Interfaces.
The Client Access interfaces through a standard windows GUI and uses the IPX (Internetwork
Packet Exchange) protocol. This connection works at the network level of the communication (the
network level being a Token Ring, Ethernet or ATM network). This however is not the only
connection that the AS/400 and clients can use to communicate by, as previously mentioned the
AS/400 uses SNADS (as well as TCP/IP - a SAP standard protocol) to communicate with other
AS/400’s.
3.4.2 Data Structure.
The standard data transfer operation requires a flat file, as it needs the ASCII format to allow the
target to recognise the data structure.
vii
Once the transfer file is in the flat file format, the consistency of transfer is 100%, there is very
rarely any discrepancies with data once transferred, it would only happen if the user had defined the
wrong path or had used incorrect SQL commands (Breen, 2000).
3.5 Summary.
Legacy systems include bespoke IBM AS/400 applications as well as off the shelf packages that
integrate with the AS/400.
AETC is migrating from four AS/400 systems, used for different parts of the business. The reason
for migration is that the information available has to be manipulated to add value to the function of
the business.
There are certain elements of both the SAP R/3 and AS/400 architectures (i.e. object oriented
structure), that facilitates the migration at the logical level. The openness and integration of the
architectures allows for communication and platform independence.
The data transfer programs used within the current legacy systems is Client Access and is very
effective at the job it is required to do.
vii
4.0 Data Transfer.
Data Migration is possibly the most significant stage of any new system implementation. In most
literature read, the view is that migrating data is the most costly and demanding on resources.
Hudicka (1999) has the view that people do not fully understand the complexities of data migration
when a number of heterogeneous sources are involved. The author having first hand experience can
understand the implications of the view put forward, as the perception of being able to move data
simply, is certainly not the case. There are many issues prior to migration that need to be fully
understood and effectively planned.
4.1 Methodologies.
As data migration requires major effort from a company’s resources, it is essential to have a sound
methodology prior to undertaking a migration project. SAP has a standard methodology, but there
are others to note such as Hudicka.
4.1.1 Dulcien Inc.
Hudicka (1999) has outlined a methodology that should be developed in line with the overall phases
of the project, i.e. it integrates with all stages of project development and includes the following,
Phases Explanation
Pre - Strategy Determine the scope of the migration – data to be migrated and from what systems.
Strategy Determine whether or not the scope is achievable by examining the actual data.
Pre - Analysis Determine procedures and who will perform tasks.
Analysis In parallel with the core Analysis of the project, as any change to the data element or
‘Object’ in SAP will change the data model.
Pre - Design This is essentially the start of data mapping, where the data model will be complete, i.e.
developed from legacy reports and user feedback.
Design Data Migration is an iterative process.
Pre - Test Looks at Logical errors and physical errors – identifies flaws in files, when mapping data.
Test Identify Logical errors and execute mapping to resolve it.
Implementatio Pilot run of the test data, after Testing is finalised.
n
Revise This is a subset of the last two and Maintenance. Clean up is undertaken here & revision of
data model.
Maintenance Data Mapping is validated and implemented through 'scripts', which have been put through
the test phase.
Fig 4, The Phases of Data Migration (Hudicka, 1999).
vii
Hudicka identifies the need for a strict methodology, as in most other systems development, data
migration is not deemed to be of such importance. He stresses that data migration should be
initiated at the first planning stage of a project development, so the consequences of the
complexities involved are identified early on.
AETC Limited have considerable experience of large project development and have been able to
obtain outside expertise from the VARs, who were able to guide them in ascertaining their
requirements for migration to SAP R/3.
4.1.2 ASAP Methodology.
As defined in the review chapter most SAP implementations follow the SAP standard ‘Accelerated
SAP’ implementation programme, this has enabled AETC to plan their implementation effectively
from start to finish. The five phases represent different stages in implementation, similar to
Hudickas but not in the same detail.
The emphasis on methodologies is apparent when comparing the two. Hudickas’ highlights the
requirement for data migration throughout all phases (but is driven at projects where data migration
is overshadowed). ASAP angles slightly differently (as data migration is an integrated part of R/3),
by identifying the milestones that need to be reached for the whole project, with pre-planning being
a major element, in understanding the obligation to R/3. Only in the Realisation (discussed in
Chapter 2) stage is data migration explored, but in great detail especially with regard to its
important role within the project.
4.2 SAP Data Transfer.
SAP uses 'business objects' to describe a business process and could be for example a Purchase
Order. The objects are called up by SAP’s BAPI (Business Application Programming Interface),
where any external applications can use the business object (SAP AG, 1997). BAPI is a method of
data transfer and will be explored further in the next chapter.
vii
SAP follows a standard process for migrating the Business Object, it uses the following flow
process;
Identify the • Understand the data to be transferred and required Business Object.
Fields • Determine the Target file structure.
Analyse Legacy • Determine legacy file structure.

Data • Determine relevant data in legacy system for R/3.
Map Legacy • Mapping assigns specific legacy data to SAP fields.

Data to R/3 • It defines the conversion process of the data.
Prepare the
Legacy data • Cleanse and Purge data before conversion
Transfer Data • Convert Legacy file to a Flat file (ASCII) format.

• Transfer data into R/3 by one of the methods available.
Fig 5, Flow Chart of Transferring Business Objects (SAP Labs, Inc, 1999)
The above flow chart provides an overview of the whole process of data migration within SAP,
from knowing your legacy systems and data, to how the data is formatted for SAP conversion.
There are several methods that can be used in SAP to transfer data.
4.3 Analysing Data.
Hudicka (1999) defines data migration as the collective process of data extraction, transformation
and cleansing, by moving data sets from one or more sources to an additional source. In AETC’s
implementation, the migration is taking place from the legacy systems as defined in chapter two, to
the SAP R/3 database. As highlighted within this chapter there are a number of issues that need to
be considered fully and understood, before migration takes place.
4.3.1 Types of SAP data.
SAP uses several types of data that are identified in its data dictionary. The data types are identified
by their functional purpose, these being Master Data, Transactional data and Customising Data
(Blain, 1997).
vii
Master Data (Static) is that which should change infrequently, for instance a Material Master,
Vendor Master, Customer Master, etc. This is critical business information that is migrated across
as a set of SAP Business objects, i.e. SAP uses business objects (as its Object Oriented Language)
to encapsulate R/3 processes and data, and make them available to the R/3 system (SAP AG, 1998).
Transactional Data (Dynamic) is used during data processing and is assigned to certain master data,
e.g. transaction data relating to a new purchase order, would be assigned to the Vendor Master
(SAP AG, 1999).
Customising Data includes system setting data and can control the business process, e.g. Material
Group Codes.
4.3.2 Issues with Data Transfer.
Initially those involved in migrating data need to understand firstly what data is to be migrated from
the legacy system, this can vary as data can come from heterogeneous data sources that are not
necessarily part of the main database systems. Secondly there is a need to understand the structures
of the data sources involved. This will provide the persons involved with an understanding of what
data is relevant and how the legacy data is to be structured within the SAP system. It is at this point
that the persons involved in migration realise the criticality of the data and the consistency of their
database.
4.3.3 Problems with Data.
A companies database historically can become overrun with obsolete, inaccurate and duplicated
data. These are not just the common problems faced, there is a further classification of problem
data, which involves data that does not conform to system standards. This is normally associated
with the target system, i.e. the SAP R/3 database.
An example of this at AETC is the data held for a material identification number on the AS/400.
The necessary data is displayed within three fields as a Category, Number and Suffix (Breen, 2000).
This is not in an acceptable data format for SAP, as SAP displays this in just one field. Therefore
preparatory formatting is essential to get the required information into the correct migration format
for SAP, this kind of data is commonly known as ‘Dirty Data’ (Hudicka, 1999).
vii
There are other issues such as Invalid Characters and Character Combinations (Hudicka, 1999),
which may not be supported by the target system, but need to be altered. In SAP during an upload
of data, if a non-recognisable character is contained within the data, the ABAP generated program
will place the data within speech marks, this can then be edited out. An example of this is text
containing commas and single quotes (Breen, 2000).
There are certain conditions that need to be followed, as with any database, Null values are not ideal
and SAP uses a standard ‘no data’ value, typically ‘/’ to represent this.
If these data violations (Hudicka, 1999) are not anticipated and dealt with there is a costly
consequence of having invalid data being migrated into the target system. This situation identifies
the major effort required in data migration, especially with Data Cleansing and Purging. This key
area will be discussed in the next section.
A problem that arose during the analysis stage at AETC identified that SAP required a ‘Material
Master’ file as a business object, but AETC did not have a valid material master in its entirety at the
PCF (Cawtheray, 2000). The result being the need to create one, which was a very lengthy and
expensive process that involved data cleansing of their AS/400 system, in order to create the
required file.
4.3.4 Data Cleansing & Purging.
Cleansing data can require a major effort and be very costly, data migration as a whole is said to
take up around 20% of the entire implementation budget (R/3 Simplification Group, 2000), data
cleansing can be a large percentage of this, depending on the complexities of the cleansing required.
Data cleansing is the process of removing dirty data from the legacy database, the result of which
creates a valid and consistent database (including any external paper systems etc). The majority of
data cleansing is focused on correcting the database so that the data is accurate, valid and current
(Blain, 1997).
There is another step that is known as ‘Data Purging’ and is identified as being the deletion process
for obsolete and unwanted data. AETC has needed to go through a major cleansing and purging
program, when creating their material master at the PCF.
vii
4.3.5 Data Source Structures.
The data source (AS/400) and target system (R/3) are of the relational database design and therefore
follow E. F. Codd’s twelve rules as set out by Date (2000). The AS/400’s DB2/400 uses single-
level storage, where each object (used to handle information) is addressed with a location in
storage. This allows for faster retrieval of information and greater management of data (IBM
Corporation, 2000).
SAP R/3 also uses the relational database architecture which is designed around thousands of tables
and a number of proprietary mechanisms (Durban, 1999) such as Pooled and Clustered tables,
which are defined within the ABAP Data Dictionary.
Table Pools
A pooled table has data stored in the appropriate table pool, i.e. data of several tables can be stored
together as a table pool in the database.
Clustered Table
A clustered table has data stored in the appropriate table cluster, i.e. several records from different
cluster tables can be stored together in one physical record in a cluster table.
Transparent Table
There is a third category of table called a transparent table that is created in the database, similar to
a ‘view’ created within SQL.
This gives a sense that the data stored within SAP is highly structured and uses the standard foreign
key to emphasise relationships and dependencies between tables. These are commonly known
within R/3 as Check Tables (Norvell, 2000).
Although there is a logical structure, there is no defined common structure to the data with regard to
the integration between the AS/400 and SAP R/3 (Breen, 2000). The SAP database requires far
more data than the AS/400 currently holds and this must be in a particular format for SAP to be able
to make use of it. The lack of a defined link is highlighted with certain 'Master Data’, for example
‘Routings’ and ‘Bills of Materials’. SAP requires defined links between master data and the
underlying tables, to allow for the transactions to take place.
Within the tables, header and item levels are used to reference the data. The header level defines the
top level of a file and the mandatory fields to be used within SAP for controlling the transaction,
vii
e.g. Part Number and Plant. The detail of the header level is held within the item level. The Header
has a one to many relationship (1 M) with the item level, an example of this could be a Bill Of
Material (BOM) for a given part number. The part has many materials that go into its manufacture
and therefore is seen as being multi-level.
4.4 Electronic vs Manual.
SAP uses an object to define master data (i.e. the business objects), but it also uses this information
to deduce the type of data transfer, i.e. Electronic or Manual. This is a decision made by the
migration team, and is primarily determined by the volume of data to be migrated. There is a
standard set of guidelines that is used to determine the transfer method, which can be viewed in
Appendix E.
Electronic data Transfer is via a standard program, which is developed for a specific Business
Object and ensures data consistency. It can also be performed by one of the other methods, which
are identified in section 4.4.1.
Manual data entry is carried out when there is little data to transfer. The data has no automatic
consistency checks, as it is transacted directly into the R/3 database. It therefore has to go though a
stringent process of accuracy and completeness checks, as the format has to be exact, i.e. the field
formats must conform to how they are set up in the SAP database. If configuration changes are
made to the table, then manual entered data has to be re-entered (R/3 Simplification Group, 1999).
Hudicka (1999) outlines the features required for a data transfer tool, as being able to report its
operation, to be able to generate code mapping (as defined in SAP Object transfer), to be able to
reduce script processing time and to be able to automatically detect any data integrity violations.
The Electronic transfer method available within SAP has all and more of these functions designed
into its operation. This will be evaluated in the next chapter.
4.4.1 Transfer Methods.
Once the type of transfer is determined, it is then possible to decide what method to use to transact
the objects into SAP, of which there are a number.
vii
If the manual method is used, the data is transacted in manually. It is important that all data is
transacted through using one of the defined methods, as the SAP software may not work correctly
(when data is transacted, Logs are created defining the meta data of the data transferred, including
location, size, etc.) (R/3 Simplification Group, 1999).
Within SAP R/3 the following transfer methods are available, the use of which depends on the
business object defined;
1. SAP Data Transfer Programs – Used for transferring standard SAP Business Objects.
2. SAP Workbench - Used to develop ABAP transfer programs.
3. LSM - The Legacy System Migration Workbench uses standard interfaces, such as
• Batch Input (BI), Direct Input (DI), BAPI's (Business Application Programming
Interfaces) or IDOC's (Intermediate Documents).
4. CATT - Computer Aided Test Tool which allows the recording of transactions.
All of the data held on the AETC legacy systems was manually formatted during the cleansing
process and presented in a flat file format. These flat files (that represented the business objects)
were then automatically transacted into the R/3 database, using primarily the Legacy System
Migration Workbench, Batch Input interface, which will be highlighted in the next section.
4.5 Legacy System Migration Workbench (LSM).
SAP R/3 incorporates a migration tool called the LSM. This allows companies to migrate data from
non-SAP systems (i.e. Legacy Systems) as well as SAP R/2 systems to SAP R/3. The LSM was
developed from the old R/2 – R/3 data transfer workbench, which is integrated into the capabilities
of the LSM (R/3 Simplification Group, 1999).
The LSM supports conversion of data from the legacy system in a convenient way, i.e. it has a
logical method that can be followed easily. The data can then be imported into the R/3 system via
one of the aforementioned interfaces. It also has the added benefit of providing a recording function
that allows you to generate a business object in an entry or change transaction. (R/3 Simplification
Group, 2000)
vii
4.6 Summary.
Hudickas methodology emphasises data migration activities throughout an implementation, whereas

SAP identifies data migration as the penultimate event in implementation.
There are many issues regarding the structure and format of data before migration can take place,
these involve consistency, structure, type and cleansing.
Data can be transferred electronically by numerous methods within SAP, i.e. the LSM or can be
transacted manually. SAP defines a data object, instead of fields and records that is migrated as a
whole into the R/3 database.
vii
5.0 Data Migration within SAP R/3.
As identified in the previous chapter, there are several methods available to transfer data into the
SAP R/3 database. This section will highlight each and use the ISO standard for evaluating
software. The author has taken the view, that the methods available are functionality’s of the overall
software product R/3 and therefore not stand-alone systems.
The standard method of migration, is to use the built in programs that are provided to transact the
various business objects into the R/3 database (see Appendix F). These are accessed by entering the
'Transaction Code' either within the LSM or with the SXDA (Data Transfer workbench) within
which there is a drop down list of objects.
These specific programs, have been developed from tried and tested solutions for migrating objects
from source to target, and therefore have assured results in data consistency. They have been
designed to accurately map the standard fields, by using established mapping conversion rules that
the SAP R/3 tables require for a relevant business object (Gradl et al, 1998).
If a standard program is not available then other methods can be used, all with varying degrees of
operation. As previously stated SAP has a standard tool, the LSM, that automates the whole process
of transacting data. There are alternative methods e.g. the ABAP Workbench (which is the core tool
within SAP) that can be used to develop a transaction program, such as the standard programs. The
Computer Aided Test Tool (CATT) is used primarily for creating manual and automatic test cases
e.g. test recorded transactions (SAP AG, 1999).
5.1 Evaluation Characteristics.
The criteria to be used is based on the ISO/ IEC 9126: 1991, Information Technology - Software
Product Evaluation (Quality characteristics & guidelines for their use) standard. There are a number
of sub-characteristics that are available within each main characteristic (see Appendix G).
vii
ISO 9126:1991
Characteristic Description.
i) Sub –
Charact
eristic
Functionality (1) Suitability (a) Attribute of software that provides set of functions for specified tasks.
Accuracy (b) Attributes of software that bears on the provision of correct results, effects.
Interoperability (c) Attributes of software that allow it to interact with specified systems.
Security (d) Attributes of software that allows ability to prevent unauthorised access.
Reliability (2) Maturity (a) Attributes of software that bears on the frequency of failure by faults.
Recoverability (b) To recover data and re-establish its level of performance.
Usability (3) Understanding (a) Attributes of software that allows users to recognise the application.
Learnability (b) Attributes of software that allows the user to learn the application.
Operability (c) Attributes of the software to allow effective operation & control by user.
Efficiency (4) Time Behaviour (a) Attributes of software that provides response & processing time &
throughput rates in performing its function.
Resource Behaviour (b) Attributes of software that bear on the amount of resources used in
performing function.
Maintainabilit Analysability (a) Attributes of software that bear on effort needed to diagnose deficiencies,
y (5) failures or identification of parts to be modified.
Changeability (b) Attributes of software to allow modification, fault removal etc.
Stability (c) Attributes of software that allows the unexpected effect of modifications.
Testability (d) Attributes of software that on effort to validate the software.
Portability (6) Adaptability (a) Attributes of software that allows it to adapt to other environments.
Conformance (c) Attributes of software that adheres to standards of portability.
Replaceability (d) Attributes of software that allows opportunity to use it in place of another
piece of software, in that environment.
Fig 6, Table of Characteristics ISO 9126:1991 (ISO/IEC 9126:1991, 2000).
The relevant characteristics in Fig 6 will be identified according to the manner in which the
characteristic fit the tools. The following sections will give a brief description of the tool and the
method it uses for transfer.
5.2 Legacy System Migration Workbench (LSM).
The LSM is a multi-functional tool and allows business objects to be created, deleted or changed
and then migrated (in the flat file format), via a 26-step migration process, which can be customised
depending on which 'interface' is chosen initially. The process takes the user through the whole
vii
migration concept by defining object attributes, structures, relationships, mapping conversion rules
and the actual required flat file.
5.2.1 How the LSM Works.
The LSM process

Accelerating Data Migration: LSM Workbench involves inputting
One or several source files that
How LSM Workbench works files have been converted
into a flat file and
Legacy data
on PC read into the LSM.
Read data Read data The data is
Structure L egacy data
relations on application converted. This
server
process determines
Field mapping Convert data
the structural
relations between
R/3 Standard
Batch Input
Conversion processing
source and target
rules and defines how the
Direct Input
Converted
processing
fields will be
data
mapped &
IDoc inbound
processing
converted. This
creates the load file,
which can then be
SAP AG July 1999 21
imported by one of
Fig 7, The LSM Workbench Process (R/3 Simplification Group, 2000) the Interfaces.
The first stage of the migration process is to determine the Project name and the desired object that
is to be transferred. Once the ‘object’ is identified, the following sequential process is used to
transact the object into the LSM, using one of the available interfaces.
vii
Command Line: Enter
transaction code
Once a step is
complete a log is
created, recording
Customised migration the history
process for a Batch Input
Interface.
Fig 8, Steps in LSM Migration Process (R/3 Simplification Group, 2000)
5.2.2 Import Interfaces.
Once the LSM generates the ABAP transaction program it is then required to be transacted, this is
achieved by one of the four interfaces. The interfaces update the database and provide the
consistency needed for an accurate database, which was highlighted by the author and Hudicka in
chapter 4.
5.2.2.1 Batch Input (BI).
This is the most common interface (for standard transfer programs) and is used to transfer large
amounts of data. BI simulates manual entry, ie. It follows the same screen transactions that one
would have to follow if doing same manually. When the BI is run it creates a BI session, which is a
data file that has details of conversion rules etc that have been previously defined. It also checks for
errors in the data before transacting it into the database (R/3 Simplification Group, 1999).
It is possible to see how the BI is processed, i.e. in the background (a Log is generated and provides
a history), foreground (ability to step through the transactions, similar to online entry) or display
errors only (errors are shown and can be amended online).
vii
5.2.2.2 Direct Input (DI).
The DI method is available for some core business objects, i.e. Master Data. It is used to check data
thoroughly, but does not have the capability of BI with processing options. Fortunately there are
two methods available,
1. If the DI program aborts mid way through processing, the user must be able to identify which
records were correctly transacted and delete them from the flat file.
2. If the user starts the program directly and it aborts prematurely, when restarted there is no need
to change the flat file, as the data was transacted successfully and when re-run does not
duplicate the records.
(R/3 Simplification Group, 1999)
5.2.2.3 Intermediate Documents (IDOC).
The IDOC was developed to exchange messages between systems. The IDOC technique converts
read data into 'packages' and stores same in its own format, until it is called up by the program and
processed (R/3 Simplification Group, 1999). This process is an option for bulk data transfer, but
was not used while the author was at AETC.
5.2.2.4 BAPI.
The BAPI as defined in section 4.2, defines the Business Object and provides the attribute of re-
usabulity due to its purpose, as with the re-usable conversion rules of the migration objects (R/3
Simplification Group, 1999).
5.3 ABAP Workbench.
The ABAP Workbench allows the creation of a flat file (as with the BAPI). It provides general
functions such as correction to a program, transport of a program, a data dictionary, etc. It is also a
test environment (this includes the CATT also), where the program can be compiled and run. It can
then be transported (the SAP term for transferring programs, configurations etc) into the system.
vii
Fig 9, ABAP Workbench Screen – Version 4.5B (SAP AG, 1999)
Tool Function
Repository Browser Ability to display and edit hierarchical lists of development objects.
Dictionary Ability to define and save data definitions Ability to store documentation, help
information, data relationships, and other information. The Dictionary can be
used to generate database objects like tables and indexes.
The Dictionary is a central storage area for system-wide data definitions. The
definitions are stored centrally and are therefore available for use anywhere in
any program throughout the system.
ABAP Editor Ability to create and edit program code.
Function Builder The Function Builder is used to define and store function modules. The
Function Builder stores these modules centrally. A library is available to write
new modules and look up information on existing modules.
Screen Painter Ability to design screens in an application's GUI.
Menu Painter Ability to design menus that appear in the GUI
Fig 10, ABAP Functions in detail (SAP AG, 1999)
The above table represents the functions of the workbench in detail.
5.4 Computer Aided Test Tool (CATT).
The CATT is the fully integrated test tool of the ABAP Workbench. The CATT is used to create
manual and automatic test cases, i.e. an automatic transaction that has been recorded (part of its
function - can also be recorded using the LSM). SAP AG states that the tool is very flexible in
transferring data and acts very similar to a BI.
It CATT uses the following sequence, record transaction, generate test module (using the relevant
transaction screens involved), assign parameters to the module and export this to create a text file.
Once the file is tested, data transfer can take place.
vii
5.5 Tool Similarities.
There is a visible relationship between the various ‘tools’. Using the LSM as a point of reference for
the others, there are certain attributes of CATT that are integrated into the LSM functionality’s, e.g.
testing, consistency checks and the ability to perform recordings. The ABAP workbench obviously
underpins both of these tools because of the ABAP language and the integration of the CATT. It
uses the ABAP editor to create code for a transaction and can test same within the ABAP
Workbench (Norvell, 2000).
AETC have made good use of the LSM but have not needed to use the IDOC or BAPI functions,
due to the effectiveness of the BI, DI and Recording capabilities.
AETC have used a standard transfer program in the AS/400 (Client Access) to import the data into
a flat file, by exporting it into an Excel spreadsheet. As a result AETC were able to use the LSM to
migrate this data into R/3 by highlighting which fields were relevant to SAP by using the SAP
standard field names.
5.6 Evaluation Results.
The following evaluation is based on the ability to create a data transfer program and uses a rating
to define the effectiveness of each tool, regarding the appropriate characteristics (section 5.1). The
rating will use a measure of 1 to 5, where five represents the best correlation to the characteristic. It
is acknowledged that the CATT is a functionality of the ABAP workbench, consequently these two
tools will be 'integrated' and evaluated as one.
The evaluation shows that although the ISO standard characteristics are reasonably rigid an
integrated tool can contain certain design elements that meet the requirement characteristics.
The LSM as identified is the standard tool and is designed to create a transaction program and use
its interfaces to transact data into the R/3 database.
5.7 Summary.
SAP uses a number of methods to create a transaction program, the preferred method is to use the
standard business programs that can be initiated by using the SXDA transaction code. The standard
vii
programs already have the required defined structures of the file and designate certain values to
certain SAP fields for the particular business object.
SAP has developed a migration tool called the LSM that can create and transact a business object
into R/3 by using a Batch Input, Direct Input, IDOC or BAPI interface.
The ABAP Workbench is a multifaceted tool, which is used primarily for program development. It
can perform other operations such as defining a recording for a transaction.
The evaluation of each tool using ISO 9126:1991 has proven that the LSM satisfies a majority of
the characteristics to a reasonable efficiency, as does the ABAP workbench. The author reiterates
that migrating data is the LSM's core design function.
vii
6.0 Conclusions.
SAP has been the pioneering force in the revolution of improving business integration and
performance, by developing enterprise wide systems. Its market leadership with R/3 the ERP
system for the client/server market is proving to be unbeatable.
R/3's architecture plays a key role in its adoption as 'open standards' and 'platform independence'
will surely continue to dominate the software market. Its fully integrated modular structure,
transaction processing and effective reporting capabilities have convinced companies in ever
increasing numbers to deploy same in place of their legacy systems.
SAP however is not the ideal software package in its standard form. SAP requires very careful
appraisal in its planning stage, in order to limit the amount of customisation that may otherwise take
place. It is an opportunity for process change, due to its process rather than task oriented nature.
SAP is a very complex system and as such, the whole process of implementing R/3 is very
demanding on an organisation, in the respect that existing processes and procedures will after re-
engineering be changed in many cases completely. A smooth implementation is paramount,
following SAP's ASAP methodology will provide a framework to follow. As with any other new
complex system implementation there are hidden problems that can hamper progress and hence
success.
The author concludes that data migration is certainly an element that if planned successfully can aid
effective implementation. Data migration is the fundamental building block for the whole system, if
the process is to be successful there are a number of fundamental issues that need to be understood.
The users must understand what historical data will be of use and in what format it needs to be.
There will always be a necessity to cleanse the data before migration as a database can become
overrun with obsolete, inaccurate and duplicated data. The challenge is to identify these early on
and purge them from the system, as the R/3 system will only be as good as the data that is in being
transacted into the system.
Data migration to SAP from legacy systems is a very structured and logical process, the use of the
various SAP tools, i.e. the LSM, provides the needed consistency that most databases fail to
achieve. The validation measures within the tools create data integrity and the SAP business objects
vii
extend the consistency. The only flaw is the inherent inconsistencies with manual data entry, which
is only limited to user entry.
It is true to say that the amount and complexity of data that needs to be captured and processed
simply cannot be underestimated. Understanding the structure of the existing legacy systems, i.e.
the AS/400, assists greatly in actual data preparation and utilising a tool that can query the database
and download data into a file can save considerable time. It is also important to understand the
relationships within the SAP database structure and how the data will relate to this.
Data migration is stated to take up about 20% of the overall implementation budget, when one takes
into account that a SAP implementation can run into the millions, then data migration becomes a
large constituent of this and therefore requires overall effective planning and management.
Overall the completed project has satisfied the objectives that were initially set. The contents have
highlighted the key issues that were identified, within the scope of what is a live project at AETC
Ltd.
The project’s completion has without doubt been assisted by a clear, concise and achievable plan.
The end product should have hopefully attained and satisfied, the standards that the intended
audience require.
vii
References.
• Accelerated SAP (1998), Accelerated SAP Implementation Assistant- version 4.15.0, SAP AG
• Ahn, J., Hofstetter, J., Mazema, L., Perera, L. & Zimmer, F (1998), SAP R/3 Implementation for
AS/400, 3rd Edition, International Business Machines Corporation.
• Apex Systems Ltd (1999), Data Migration Introduction, Apex Systems.
• Bancroft, N.H., Seip, H., Sprengel, A (1997), Implementing SAP R/3, 2nd Edition, Manning.
• Blain, J & Consultancy, ASAP World (1997), Special Edition Using SAP R/3, 2nd Edition, Que
Corporation.
• Breen, R (2000), IT Projects, AETC Limited.
• Cawtheray, P (2000), IT Manager, AETC Limited.
• Coalition, Workflow Management (1999), Terminology & Glossary, The Workflow
Management Coalition Specification, Doc No. WFMC-TC-1011, Issue 3, p 8.
• Curran, T., Keller, G. & Ladd, A (1998), SAP R/3 Business Blueprint: Understanding the
Business Process reference model, Prentice Hall.
• Date, C.J (2000), The Database Relational Model: A retrospective review and analysis,
Addison-Wesley Publishing company.
• Dawson, M (1998), SAP and the AS/400, Coffee Break,
http://www.midrangecomputing.com/coffeebreak/bi.cfm?bi=980401.cfm
• Dulcian (2000), Data Migration, http://www.dulcian.com/data_migration.htm
• Durban, M (1999), Access denied how Guinness overcame the difficulties of extracting data to
populate a data warehouse with valuable business information, Managing Information, Vol. 6,
no.6, pp 38-40.
• Faden, M (2000), Data Cleansing helps E-Business run more efficiently: Data Mining & E-
Commerce have exposed problems with the management of information, Information Week
Online.
• Gradl, J & Dascakowsky, K (1998), Accelerated Data Migration, SAP AG,
http://www.sap.com/press/magnews/regular/dt_1098e/s20.htm
• Gradl, J (1999), Making Migration, www.sap.com/press/magnews/regular/ma_1199/5056.htm
• Hernandez, J.A (1997), The SAP R/3 Handbook, McGraw-Hill,
http://advisor.gartnerweb.com/n_inbox/hotcontent/hc_081898_2.html
• Hirsch, H (1995), AS400 Integrated File Server (FSIOP),
http://www.tug.on.ca/articles/sep95v11n1AS400IntegratedFileServer.html
• http://www.mysap.com
• http://www.sap.com
vii
• http://www.sapfans.com
• Hudicka, J.R (1999), So, you say your Data’s clean, Huh?!?, Dulcian, Inc, www.dulcian.com
• Hudicka, J.R (1999), The complete data migration methodology, Dulcian, Inc,
www.dulcian.com
• Hutt, N., Kin, M.C., Lee, D., Rizzo, J., Roehm, B., Ryymin, J., Smith, M.M., Steen, G.V.,
Vebele, H (1997), Inside AS/400 Client Access for Windows 95/NT V3 R1 Mod2, IBM
Corporation, International Technical Support Organisation – Rochester Centre.
• IBM Corporation (2000), AS/400 Guided Tour,
http://www.as400.ibm.com/overview/tourindex.htm.
• ISO/IEC 9126:1991 (2000), Information technology: Software product evaluation (Quality
characteristics and guidelines for their use), International Standards Organisation.
• Kronos Incorporated (2000), TimeKeeper AS Suite, http://www.kronos.com/products/tkas.htm.
• Lienert, A (1996), Getting in the Pink, Management Review, vol.85, no.5, pp 18-23.
• Macmillan, M (1998/99), Enterprise-wide Systems in Education: A Case Study of SAP R/3 at
the University of Leeds, MSc Project - School of Computer Studies.
• Manufacturing Computer Solutions (2000), News & Analysis: Manufacturers to be offered
pre-configured SAP, Manufacturing Computer Solutions, vol. 6, no. 5, p 8.
• Midrange Computing Editors (1997), Coffee Breaks with the Editors,
http://www.midrangecomputing.com/coffeebreak/bi.cfm?bi=970618.cfm.
• Norvell, A (2000), SAP ABAP Consultant, Avalon Systems Development Ltd.
• Powers, S (1999), AS/400 System Handbook,
http://publib.boulder.ibm.com/pubs/pdfs/as400/V4R3PDF/EZ3AER01.PDF.
• R/3 Simplification Group (1999), Data Transfer Made Easy: Step by Step guide to SAP Data
Transfer, Release 4.0B – 4.5x, SAP Labs, Inc.
• R/3 Simplification Group (1999), Initial Data Transfer Made Easy: Step by Step guide to SAP
Initial Data Transfer, Release 4.0B, SAP Labs, Inc.
• R/3 Simplification Group (2000), Data Migration of Non- SAP Systems to R/3: Quick
introduction to working with the Legacy Systems Migration Workbench – Version 1.6.6, SAP
Labs, Inc.
• Ranger, S (2000), Hosting: beware the shake-out, Computing - 3rd August, p 9.
• Ricke, D (2000), Technical Notes- A 3 Dimensional framework for information technology
solutions, IBM Systems Journal, vol.39, no.2, pp 336-359.
• SAP AG (1997), BAPI Introduction and Overview- R/3 Release 4.0, SAP AG.
• SAP AG (1998), SAP 50 Basis Technology, SAP AG.
vii
• SAP AG (1999), SAP Online Help 4.5B- Glossary, SAP AG.
• SAP AG (1999/2000), SAP R/3, SAP Labs, Inc.
• Scapens, R., Jazayeri, M and Scapens, J (1998), SAP integrated information systems and the
implications to management accountants, Management Accounting, vol. 76, no.8, pp 46-48.
• SES Software Holdings Limited (1995), BOMA™-Legacy Systems, http://www.mpgfk.tu-
dresden.de/~weise/docs/boma/0-1.html.
• Sharpe, S (1999), SAP R/3 in 10 Minutes, SAMS Publishing.
• Tapsell, S (1999), The growth merchants, Management NZ, vol. 46, no.5, pp 20-24.
• Whatis.com (2000), Terminology, http://www.whatis.com/index.htm.
vii
Appendix A: Project Experience
vii
Project Experience.
Having the opportunity to undertake a project within a working environment has been a very
rewarding experience, especially one of this scale and relevance. I believe I have gained three
positives from the project,
1. I have been able to interact with highly qualified professionals.

2. I have gained valuable experience in a field, that I might not have done with an in house project.
3. I believe the environment and knowledge that I have been involved with has enabled me to
develop and further my inter-personal and management skills, which in today’s labour market is
very important.
SAP R/3 as a whole is a very complex system to implement, and without question needs dedicated
project management. SAP R/3’s underpinning methods are certainly cutting edge and trying to
understand fully what it can achieve has been an absorbing experience. Its flexibility in both
operation and integration is without doubt superior to any other product on the market.
It is absolutely essential to be involved within a live implementation because of the access to

documentation that would otherwise need to be purchased, which in the case of SAP is normally
very expensive. There is also the benefit of gaining knowledge from professionals involved with
implementation.
I have found it quite strange that software implementations have such highly specific guidelines for
project management, there are numerous publications, documentation’s etc that back this up. In the
case of an implementation that involves data migration, there is little or no information available
that both describes and encourages the pro-active management of a data migration project.
Having clearly defined objectives and a plan of how they are to be achieved has certainly been very
beneficial. Identifying the required scope, literature and knowledge to achieve them has provided an
excellent future in project management, as my career progresses.
Above all careful planning is absolutely essential and understanding how to satisfy the objectives is
of paramount importance, to a successful project.
vii
Due to the remit of this project, I have found it stressful at times with regard to following the MSc
Project handbook. I feel it is biased or too focused towards a software development project. If a
student wishes to understand an element of the course in more detail, then the MSc Project
Handbook should be able to guide the student along, not produce some statements that are
confusing.
My advice to any future project undertaken, is if an obstacle interrupts the train of thought, then
step back and focus on a small part of the project that can be achieved without any problems, i.e.
keeping an effective reference list or making sure the whole project is formatted correctly. This will
give the feeling of flow and will improve the overall productivity of the project.
Above all, try and obtain a project that is value adding and enjoy it, four months goes very quickly.
vii
Appendix B: Objectives & deliverables
vii
School of Computer Studies
MSC PROJECT OBJECTIVES AND DELIVERABLES
This form must be completed by the student, with the agreement of the supervisor of each
project, and submitted to the MSc project co-ordinator (Mrs A. Roberts) by 7th April 2000.
A copy should be given to the supervisor and a copy retained by the student. Amendments
to the agreed objectives and deliverables may be made by agreement between the
student and the supervisor during the project. Any such revision should be noted on this
form. At the end of the project, a copy of this form must be included in the Project Report
as an Appendix.
Student: Geoffrey WARRISS.
Programme of Study: Information Systems.
Supervisor: Prof. Martin Dyer.
Title of project: Data Migration from various Legacy Systems to SAP

R/3.
External Organisation*: AETC Ltd.

*(if applicable)
AGREED MARKING SCHEME
Understand Produce a Evaluation Write -Up Appendix TOTAL

the Problem Solution * A
%
20 40 20 15 5 100
* This category includes Professionalism (see handbook)
OVERALL OBJECTIVES (continue overleaf if necessary):
• To undertake a comprehensive understanding of the SAP R/3 System.
• To analyse the current Legacy Systems, i.e. AS400 system etc, from which AETC are extracting
data.
• To examine the issues of Data Transfer from manual to automatic transfer.
• To evaluate the current process of Data Migration within the SAP R/3 system.
• To draw conclusions from Data Transfer/ Migration.
vii
DELIVERABLE(s):
1. A project report.
2. An Interim report.
3. A final presentation of the overall project.
Signature of student: Date:
Signature of supervisor: Date:

Agreed objectives and deliverables (continued):
Amendments to agreed objectives and deliverables:

Date Amendment
vii
Appendix C: Marking Scheme &
Interim Report Header
vii
Appendix D: ASAP Documentation
vii
Appendix E: SAP Data Transfer
Matrix
vii
Conversion Evaluation Matrix
Score
Number of Objects < 500 501-2,500 2,500-10,000 >10,000
Weight See note 1 0 1 2
Number of Legacy Inputs 1 2 or 3 4,5, or 6 >6
Weight 3 2 1 0
Quality of legacy data Good Fair Poor
Weight 2 1 0
Amount of legacy data editing Little Average Extensive
Weight 2 1 0
Number of data element Few Average Many
translations
Weight 2 1 0
Complexity of legacy data Simple Average Complex Extra-complex
Weight 1 0 0 1
Number of SAP input data 1 or 2 3 to 5 6 to 10 >10
Weight 0 1 2 3
Complexity of SAP input Simple Average Complex Extra-complex
Weight 1 0 0 1
Does an SAP transfer Yes No
program exist?
Weight 5 0
Can data be entered as Yes No
needed?
Weight 0 1
Total Score:
Notes:
1. If the number of objects is less than 500, the legacy data is complex, the SAP input is complex,
and an SAP standard data transfer program exists, an automatic conversion is the best solution.
Otherwise, a legacy data report and manual data input should be used.
2. A score of 5 or less indicates that a manual conversion is the most cost-effective solution.
3. A score between 5 and 10 indicates that either a manual conversion or an automated conversion
may be a cost-effective solution, but the evaluation factors should be carefully reviewed before
deciding a recommended course of action.
4. A score of 10 or more indicates that an automated conversion is justified.
vii
Appendix F: Business Object Transfer
Programs
vii
SAP Standard Business Object Data Transfer Programs.
Module Business Object Program/ Transaction

Financial Accounting Accounting Documents RFBIBL00
Assets RAALTD01 (Batch Input)
RAALTD01 (Direct Input)
G/L Account Master RFBISA00
Customer Master RFBIDE00
Vendor Master RFBIKR00
FI- Bank Data Transfer of Bank Data (Austria) RFBVAT_0

Transfer of Bank Data (Canada) RFBVCA_0
Transfer of Bank Data (Germany) RFBVD__2
Transfer of Bank Data (Great Britain) RFBVGB_0
Transfer of Bank Data (Italy) RFBVIT_0
Transfer of Bank Data (Spain) RFBVES_0
Transfer of Bank Data (Switzerland) RFBCH_0
Human Resources Master Data (Organisational Units) RPUSTD00

Payroll Account RPULKT00
Personnel Planning Data RHALTD00
Materials Management Create Characteristics RCCTBI01

Create Classes RCCLBI01
Create Classification RCCLBI02
Change Classification RCCLRI03
Material Master RMDATIND
Purchase Information Records RM06IBI0
Purchase Requisitions RM06BBI0
Open Purchase Order RM06EEI0
RM06EEI1 Purchase Order
RM06EEI1 Order
Development
RSTXLITF Long Texts
Reservations RM07RRES
Stocks (Inventory Management) RM07MMBL
Vendor Master RFBIKR00
Materials Management Phrases CG31

(EH&S)
Sources CG32
Substances CG33
Plant Maintenance Measuring Point RIIBIP00/IBIP

Measurement Documents RIIBIP00/IBIP
Notifications - General RIIBIP00/IBIP
Functional Location RIIBIP00/IBIP
Object Link RIIBIP00/IBIP
Equipment RIIBIP00/IBIP
Maintenance Plan RIIBIP00/IBIP
vii
Scheduling Maintenance Plan RIIBIP00/IBIP
Order Confirmation RIIBIP00/IBIP
Equipment Task List RIIBIP00/IBIP
General Maintenance Task List RIIBIP00/IBIP
Functional Location Task List RIIBIP00/IBIP
Production Master Create Bill of Material RCSBI010

Change Bill of Material RCSBI020
Create variant Bill of Material RCSBI030
Create Bill of Material with Long Texts RCSBI040
Routings/ Task Lists RCPTRA01
Documentation Info Record RCVBI010
Production Planning Demand Management RMMM60BI (Batch Input)

RM60IN00 (Direct Input)
SAP- EIS Several Records for SAP-EIS RKCFILE0
Sales & Distribution Condition Records (Pricing) RV14BTCI

Customer Master RFBIDE00
Open Sales Orders FVINVB00

Invoicing External Transactions RVAFSS00
Warehouse Storage Bins RLPLAT00

Management
Stocks on Storage Bins RLBEST00
vii
Appendix G: ISO 9126 : 1991
Software Evaluation
vii
Functionality
A set of attributes that bear on the existence of a set of functions and their specified properties. The
functions are those that satisfy stated or implied needs. (ISO 9126: 1991, 4.1)
Functionality
Suitability:
Attribute of software that bears on the presence and appropriateness of a set of functions for specified tasks.
(ISO 9126: 1991, A.2.1.1)
Accuracy:
Attributes of software that bear on the provision of right or agreed results or effects. (ISO 9126: 1991,
A.2.1.2)
Interoperability:
Attributes of software that bear on its ability to interact with specified systems. (ISO 9126: 1991, A.2.1.3)
NOTE -- Interoperability is used in place of compatibility in order to avoid possible ambiguity with
replaceability. (ISO 9126: 1991, A.2.1.3)
Compliance:
Attributes of software that make the software adhere to application related standards or conventions or
regulations in laws and similar prescriptions. (ISO 9126: 1991, A.2.1.4)
Security:
Attributes of software that bear on its ability to prevent unauthorised access, whether accidental or
deliberate, to programs and data. (ISO 9126: 1991, A.2.1.5)
Reliability
A set of attributes that bear on the capability of software to maintain its level of performance under stated
conditions for a stated period of time. (ISO 9126: 1991, 4.2)
NOTE -- Wear or ageing does not occur in software. Limitations in reliability are due to faults in
requirements, design and implementation. Failures due to these faults depend on the way the software
product is used and the program options selected rather than on elapsed time. (ISO 9126: 1991, 4.2)
Reliability
Maturity:
Attributes of software that bear on the frequency of failure by faults in the software. (ISO 9126: 1991,
A.2.2.1)
Fault tolerance:
Attributes of software that bear on its ability to maintain a specified level of performance in cases of software
faults or of infringement of its specified interface. (ISO 9126: 1991, A.2.2.2)
Recoverability:
Attributes of software that bear on the capability to re-establish its level of performance and recover the data
directly affected in case of a failure and on the time and effort needed for it. (ISO 9126: 1991, A.2.2.3)
Usability
A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a
stated or implied set of users. (ISO 9126: 1991, 4.3)
NOTES
1. `Users' may be interpreted as most directly meaning the users of interactive software. Users may
include operators, end users and indirect users who are under the influence or dependent on the use
of the software. Usability must address all of the different user environments that the software may
affect, which may include preparation for usage and evaluation of results.
2. Usability defined in this International Standard as a specific set of attributes of software product
differs from the definition from an ergonomic point of view, where other characteristics such as
efficiency and effectiveness are also seen as constituents of usability. (ISO 9126: 1991, 4.3)
Usability
Understandability:
Attributes of software that bear on the users' effort for recognising the logical concept and its applicability.
(ISO 9126: 1991, A.2.3.1)
Learnability:
Attributes of software that bear on the users' effort for learning its application (for example, operation control,
input, output). (ISO 9126: 1991, A.2.3.2)
vii
Operability:
Attributes of software that bear on the users' effort for operation and operation control. (ISO 9126: 1991,
A.2.3.3)
Efficiency
A set of attributes that bear on the relationship between the level of performance of the software and the
amount of resources used, under stated conditions. (ISO 9126: 1991, 4.4)
NOTE -- Resources may include other software products, hardware facilities, materials, (e.g. print paper,
floppy disks) and services of operating, maintaining or sustaining staff. (ISO 9126: 1991, 4.4)
Efficiency
Time behaviour:
Attributes of software that bear on response and processing times and on throughput rates in performing its
function. (ISO 9126: 1991, A.2.4.1)
Resource behaviour:
Attributes of software that bear on the amount of resources used and the duration of such use in performing
its function. (ISO 9126: 1991, A.2.4.2)
Maintainability
A set of attributes that bear on the effort needed to make specified modifications. (ISO 9126: 1991, 4.5)
NOTE -- Modifications may include corrections, improvements or adaptation of software to changes in
environment, and in requirements and functional specifications. (ISO 9126: 1991, 4.5)
Maintainability
Analysability:
Attributes of software that bear on the effort needed for diagnosis of deficiencies or causes of failures, or for
identification of parts to be modified. (ISO 9126: 1991, A.2.5.1)
Changeability:
Attributes of software that bear on the effort needed for modification, fault removal or for environmental
change. (ISO 9126: 1991, A.2.5.2)
Stability:
Attributes of software that bear on the risk of unexpected effect of modifications. (ISO 9126: 1991, A.2.5.3)
Testability:
Attributes of software that bear on the effort needed for validating the modified software. (ISO 9126: 1991,
A.2.5.4)
Portability
A set of attributes that bear on the ability of software to be transferred from one environment to another. (ISO
9126: 1991, 4.6)
NOTE -- The environment may include organisational, hardware or software environment. (ISO 9126: 1991,
4.6)
Portability
Adaptability:
Attributes of software that bear on the opportunity for its adaptation to different specified environments
without applying other actions or means than those provided for this purpose for the software considered.
(ISO 9126: 1991, A.2.6.1)
Installability:
Attributes of software that bear on the effort needed to install the software in a specified environment. (ISO
9126: 1991, A.2.6.2)
Conformance:
Attributes of software that make the software adhere to standards or conventions relating to portability. (ISO
9126: 1991, A.2.6.3)
Replaceability:
Attributes of software that bear on the opportunity and effort of using it in the place of specified other
software in the environment of that software. (ISO 9126: 1991, A.2.6.4)
NOTES
3. Replaceability is used in place of compatibility in order to avoid possible ambiguity with
interoperability.
vii
4. Replaceability with a specific software does not imply that this software is replaceable with the
software under consideration.
5. Replaceability may include attributes of both installability and adaptability. The concept has been
introduced as a subcharacteristic of its own because of its importance.
Evaluation process
Source ISO 9126: 1991, 5.3.
The evaluation process consists of three stages and it may be applied in every appropriate phase of the life
cycle for each component of the software product:
Quality Requirement Definition: The purpose of the initial stage is to specify requirements in terms of quality
characteristics and possible subcharacteristics. Requirements express the demand of the environment for
the software product under consideration, and must be defined prior to the development. As a software
product is decomposed into major components, the requirements derived from the overall product may differ
for the different components.
Evaluation Preparation: The purpose of the second stage is to prepare the basis for evaluation. This stage
consists of three components:
Quality metrics selection
: The manner in which quality characteristics have been defined does not allow their direct
measurement. The need exists to establish metrics that correlate to the characteristics of the software
product. Every quantifiable feature of software and every quantifiable interaction of software with its
environment that correlates with a characteristic can be established as a metric. [...] Metrics can differ
depending on the environment and the phases of the development process in which they are used.
Metrics used in the development process should be correlated to the user respective metrics, because
the metrics from the user's view are crucial.
Rating levels definition
: Quantifiable features can be measured quantitatively using quality metrics. The result, the measured
value, must be interpreted as a rated value, i.e. divided into ranges corresponding to the different
degrees of satisfaction of the requirements. Since quality refers to given needs, no general levels for
rating are possible. They must be defined for each specific evaluation.
Assessment criteria definition
: To assess the quality of the product, the results of the evaluation of the different characteristics must be
summarised. The evaluator has to prepare a procedure for this, using, for instance, decision tables or
weighted averages. The procedure usually will include other aspects such as time and cost that
contribute to the assessment of quality of a software product in a particular environment.
Evaluation Procedure:
The last step of the Evaluation Process Model is refined into three steps, namely measurement, rating and
assessment.
Measurement:
For measurement, the selected metrics are applied to the software product. The result is values on the
scales of the metrics.
Rating:
In the rating step, the rating level is determined for a measured value.
Assessment:
Assessment is the final step of the software evaluation process where a set of rated levels are
summarised. The result is a statement of the quality of the software product. Then the summarised
quality is compared with the other aspects such as time and cost. Finally managerial decision will be
made based on the managerial criteria. The result is a managerial decision on the acceptance or
rejection, or on the release or no-release of the software product.
vii
Appendix H: Legacy System
Migration workbench
vii

Data Migration From Legacy To SAP R3

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Data Migration From Legacy To SAP R3

Enviado por

Direitos autorais:

Formatos disponíveis

Data Migration from various Legacy Systems to SAP R/3

MSc in Information Systems

1. To undertake a comprehensive study of the SAP R/3 system (a review).

ABAP Advanced Business Application Programming

Fig No. Description (Reference) Page

1 Principal Modules within SAP (Scapens et al, 1998) 4

List of Abbreviations ………………………………………... iii

List of Figures & Tables …………………………………….. iv

Contents Page ………………………………………………... v

Project Development ………………………………………... vii

1.0 Introduction …………………………………………………. 1

2.0 A Review of SAP R/3 ………………………………………... 3 – 11

2.1 SAP AG ………………………………………………… 3

2.2 What is SAP R/3? ………………………………………. 4

2.3 What does SAP R/3 offer? ……………………………... 4

2.4 Opportunity for Improvement ………………………….. 7

2.5 Functionalities ………………………………………….. 10

2.6 Summary ……………………………………………….. 10

3.0 Legacy Systems at AETC Ltd ……………………………… 12

3.1 The AS/400 …………………………………………….. 12

3.4 Transfer Programs ……………………………………… 17

3.5 Summary ……………………………………………….. 18

4.0 Data Transfer ………………………………………………... 19 – 27

4.1 Methodologies ………………………………………….. 19

4.2 SAP Data Transfer ……………………………………... 20

4.3 Analysing Data …………………………………………. 21

4.4 Electronic Vs Manual …………………………………... 25

4.5 Legacy System Migration Workbench …………………. 26

4.6 Summary ……………………………………………….. 27

5.0 Data Migration within SAP R/3 ……………………………. 28 – 36

5.1 Evaluation Characteristics .……………………………... 28

5.2 Legacy System Migration Workbench (LSM) ..……….. 29

5.3 ABAP Workbench ……………………….……………... 32

5.4 Computer Aided Test Tool (CATT) ……..……………... 33

5.5 Tool Similarities ………………………………………... 34

5.7 Summary ……………………………………………….. 36

6.0 Conclusions ...………………………………………………… 37 - 38

B Objectives & Deliverables.

C Marking Scheme & Interim Report Header Sheet.

E SAP Data Transfer Matrix.

F Business Object Transfer Programs.

G ISO 9126: 1991 Software Evaluation

H Legacy System Migration Workbench

Title: DATA MIGRATION FROM VARIOUS LEGACY SYSTEMS TO SAP R/3.

• To undertake a comprehensive study of the SAP R/3 System (a review).

Area/ Content Info Comp Date Completed

Area/ Content Info Comp Date Completed

• To examine the issues of Data Transfer from manual to automatic.

Area/ Content Info Comp Date Completed

Area/ Content Info Comp Date Completed

Initial Project Schedule.

2 Full tim e on Project

4 Study SAP R/3 System, inc background reading

5 Evaluating Legacy Systems for data migration

7 Evaluate current process of Data Migration

8 Conclude on Data Migration from Legacy Systems

2 Full time on Project

5 Evaluating Legacy Systems for data migration

6 Examine issues of Data Transfer

7 Evaluate current process of Data Migration

8 Conclude on Data Migration from Legacy Systems

6. To undertake a comprehensive study of the SAP R/3 system (a review).

2.1 SAP AG.