R/3 System R/3 OS/DB-Migration

Copyright 1998 SAP AG. All rights reserved. No part of this brochure may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice. SAP AG further does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP AG shall not be liable for any special, indirect, incidental, or consequential damages, including without limitation, lost revenues or lost profits, which may result from the use of these materials. The information in this documentation is subject to change without notice and does not represent a commitment on the part of SAP AG for the future. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft, WINDOWS, NT ,EXCEL and SQL-Server are registered trademarks of Microsoft Corporation. IBM, DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, und OS/400 are registered trademarks of IBM Corporation. OSF/Motif is a registered trademark of Open Software Foundation. ORACLE is a registered trademark of ORACLE Corporation, California, USA. INFORMIX-OnLine for SAP is a registered trademark of Informix Software Incorporated. UNIX and X/Open are registered trademarks of SCO Santa Cruz Operation. ADABAS is a registered trademark of Software AG SAP, R/2, R/3, RIVA, ABAP, SAPoffice, SAPmail, SAPaccess, SAP-EDI, SAP ArchiveLink, SAP EarlyWatch, SAP Business Workflow, SAP Retail, ALE/WEB, SAPTRONIC, SAP Scope are registered trademarks of SAP AG.

SAP AG

Neurottstrae 16

69190 Walldorf

Germany

Contents
R/3 OS/DB Migration ..................................................................................................................... 3 R/3 Platforms .................................................................................................................................. 3 What Does OS/DB Migration Mean?.............................................................................................. 3 Homogeneous System Copy ........................................................................................................... 3 Heterogeneous Copy/Migration ....................................................................................................... 4 Effects of a Migration....................................................................................................................... 4 The Migration Procedure ................................................................................................................. 4 Registering the Migration................................................................................................................. 5 Defining the Migration Project.......................................................................................................... 5 Approving the Migration................................................................................................................... 5 Procuring the Hardware................................................................................................................... 6 X.25 Access.................................................................................................................................... 6 Test Runs for the Migration.............................................................................................................. 6 Performance Analysis in the Target System ..................................................................................... 6 Final Migration ................................................................................................................................ 6 Time Schedule................................................................................................................................ 7

R/3 OS/DB-Migration

August 1998

You can find this and other current literature on our hompage in the media centers for each subject http://www.sap.com

R/3 OS/DB Migration

R/3 Platforms
The SAP R/3 software supports a variety of hardware platforms and database systems. When purchasing a license for the R/3 System, the customer decides on a hardware platform and a database system. The SAP license for R/3 is tied to this hardware/database combination. The R/3 license enables the customer to install a test system, an consolidation system, and a training system in addition to the production R/3 System, provided these systems run on the same hardware platform and database. As time passes, customers may have to replace the hardware running the R/3 database, particularly when the server performance can no longer keep up with the R/3 system load.

R/3 License

What Does OS/DB Migration Mean?

OS/DB migration referred to below simply as migration, describes the process in which an existing R/3 System is moved to another operating system or database. The general procedure is to generate a copy of the existing system and then installing it on another computer with the required operating system and database. This process is also called a heterogeneous system copy. The alternative to the heterogeneous system copy is the homogeneous system copy in this case, the copied system runs on the same operating system and the same database.

Homogenous and Heterogeneous System Copy

Homogeneous System Copy

Customers can perform a homogenous migration themselves, using the documentation provided by SAP. However, SAP recommends defining a project for this purpose and letting a certified Basis consultant perform the actual migration. If new server types are used, or significant hardware additions (such as redesigning the disk configuration) are involved, the hardware partner should also be involved in the project.

New Hardware

Heterogeneous Copy/Migration
Changing the Operating System or Database System
An OS/DB migration, in contrast, involves a much more complex process. Before a heterogeneous migration can be started, you should carefully examine whether all possibilities for improving performance through operating system and database means have really been exhausted. If this is the case, you should check whether a newer, more powerful server from the same platform meets your requirements. An operating system or database migration should only be your last resort.

Effects of a Migration
Risks Involving Availability and Performance
An OS/DB migration involves considerable risk concerning the availability and performance of your production R/3 System. Decisive factors for the performance of an R/3 System are the parameter settings of the database, the operating system, and the R/3 System itself (the R/3 System settings also depend on the specific database and operating system). During a migration, the old configuration cannot simply be copied. Determining the new parameter values requires an iterative configuration process during which the availability of the migrated system will be greatly limited

The Migration Procedure

One of SAPs highest priorities is that the customers R/3 System continues to run as a stable product with high availability, security, and performance even after an operating system or database migration.

OS/DB Migration Service

To minimize the uncertainties associated with a heterogeneous migration, SAP offers the OS/DB Migration Service to accompany and support the customers migration project. The OS/DB Migration Service makes it possible to use special tools developed by SAP for the operating system and database migration. These tools are available for R/3 Systems starting with Release 3.0D. A database migration using tools other than those provided by SAP is generally not possible, since migrating the R/3 Repository - the data that controls the R/3 System itself - requires knowledge about the structure of that data. The OS/DB Migration Service is linked to an installation number. Accordingly, the OS/DB Migration Service allows the customer to migrate all the systems that belong to the same installation number (production system, consolidation system, test system, training system).

Registering the Migration

The customer initially reports a migration request as an OSS message, application area XX-SER-OSDBMIG, which is sent to SAP. SAP then provides information on how to proceed. The general steps involved in this procedure are described briefly below.

Registration via OSS

Defining the Migration Project

SAP offers its consulting partners a special training program on the subject of OS/DB migration. The program is open to certified Basis consultants, who can earn the qualification for performing database and operating system migrations in customer projects. Migration projects are performed by customers together with a certified migration partner who has earned the qualification for OS/DB migrations. The customer and partner jointly determine a project schedule for the migration, based on a checklist provided by SAP. A project schedule is drawn up for each system for migration. The project schedule contains the specific activities required for the individual items in the checklist, as well as items that the hardware/database partner feels are important. All the following activities must be described in the project schedule. The migration is performed in three main phases. 1. 2. 3. Preparation: the requirements for the migration are met Test runs for the migration Final migration

Partner Contact

Determining the Project Schedule

Approving the Migration

The customer sends their contract documents to the OS/DB Migration Service, together with the project schedules. The project schedules include a list of all the people and companies involved in the project. SAP verifies that the migration is feasible under the given circumstances. The goal of this verification is to avoid obvious errors and to eventually reach a point where SAP can assume support for the migrated system. However, SAPs verification of the feasibility of the migration project does not represent a guarantee on SAPs part that the migration project will be successful.

Verifying Feasibility

Procuring the Hardware

New Server for the Target System
A new server must be procured for the target system. During an OS migration, the hardware is always changed, and a second server is also required for a database migration, since the test migration must be managed while the production system continues running. Moreover, a successful test migration is no guarantee that the production migration will also succeed, which means that the existing system must still be available as a backup in case of failure. The target server must be at least as powerful as the existing server.

X.25 Access
Remote access must be available to both the existing server and the target server.

Test Runs for the Migration

Iterative Tests
The project team iteratively exports the database from the existing system, sets up the target system, and verifies consistency and performance. At the same time, the parameters for the migration tools are adapted and improved - as are the data transfer techniques - in order to use these improvements in the next iterative step.

Performance Analysis in the Target System

Once the tests in the target system are successful, SAP conducts a performance analysis. This performance analysis takes place within the framework of the Going Live Technical Check, which is part of the migration package.

Final Migration
Migrating the Production System
When all the preceding steps have been completed successfully, the final migration is prepared and executed. Whether production operations can be moved from the existing system to the target system depends on the results of tests in the migrated system. Until these tests are positive, the existing system must remain available for production work at all times. Once production work has been moved to the new platform, the closing actions of the Going Live Technical Check are performed on that platform.

Time Schedule
Time Frame
Project registered Project approved by SAP GoingLive

1-2 weeks

4 weeks

3-4 weeks

1-2 weeks

2-4 weeks

GoingLive Migration Checks

The specified interval of four weeks between project approval and the first GoingLive Migration Check is only a rough estimate. More time may be necessary to migrate complex R/3 Systems.