7.3 Package applications migration planning

< Day Day Up >

For package applications, the according vendor delivers the application and database based on DB2 UDB. The migration limits to:

Check software and hardware availability and compatibility
Education of developer and administrators
Analyze of customized changes in application and database
Setting up the target environment
Change of customized items
Test of data migration and customized items
Roll-out

To keep the support from the vendor, you have to meet the prescribed migration plan and process. We show you in this chapter the migration approach for SAP, Siebel, and PeopleSoft environments.

7.3.1 SAP

An SAP system is divided in different layers. The application and business logic is independent of the database. SAP uses only common database types and functionality. However, in planning of the migration efforts, you have to take into account your self-made customizations.

Migration requirements

For database migration, SAP requires the customer to use the SAP Migration Service in order for the system to be supported after the migration is complete. The SAP Migration Service is fee-based and will provide you with the following:

Cross check of the database migration project plan
Migration tools
Migration keys
Remote Going Live Migration check
Support in case of migration tool problems

The SAP R/3 software for your new IBM DB2 system will be delivered by SAP after the necessary contractual/licensing changes.

Migrating a SAP R/3 system to a different operating system or database needs to be planned and approved by SAP, and therefore SAP requires that you use their migration tools.

To perform a migration you need a migration key. This key will be provided to you by SAP. The key is mandatory for the data export step and data import using SAP's tools.

The migration project plan

To successfully perform a migration, you need to follow a well-defined process using the steps shown in Figure 7-2. Therefore, SAP demands a project plan for your migration project. This plan is made by the customer and the migration partner. SAP Migration Service will check this plan to ensure that your migration will be successful. Sample project plans can be found at Web site: http://service.sap.com/osdbmigration

click to expand
Figure 7-2: SAP R/3 database migration project

The migration project

Figure 7-2 gives you an overview of a SAP R/3 database migration project:

As database migration comprises several tasks, we recommend that you begin planning three to four months in advance.

Figure 7-3 provides a typical time line for planning a migration.

click to expand
Figure 7-3: SAP R/3 database migration timeline

Migration test and check

Before the final migration, SAP requires at least one migration test run. This will assure that all your SAP R/3 data and functionality are moved correctly to the target system.

After the first functional test of the migrated system, end users should be involved in the test process as well. This ensures that the target system is tested comprehensively.

The Going live migration check is a part of the migration services from SAP. It should be scheduled after the test migration, and three to four weeks before the final migration.

Final migration and verification

This step is performed after a successful test of the target system and SAP's Going live migration check.

The final migration is usually scheduled for a weekend as downtime is required while the switch to a new platform occurs. The steps are the same as with the test run, but in addition, you should do a full backup afterwards.

The Going live migration verification is again a part of the migration services from SAP. The migration verification step is done twice. The first time should be scheduled one to two weeks after the final migration; the second time it should be scheduled six to eight weeks after the final migration. This should ensure that all daily, monthly, and other reports and functions are operating correctly.

7.3.2 PeopleSoft

PeopleSoft migration limits to the conversion of the database objects and data from the source to the target as well as the adoption of the administration tasks to the target. The application for the proper database is delivered by PeopleSoft. Most PeopleSoft installations have done some degree of customization of their databases. The customization can be of the following types:

Modifications to DDL
Use of stored procedures and triggers
Use of non-ANSI SQL
Use of non-ANSI data types

PeopleSoft offers the tool DataMover to generate script files, which you can use to build the database objects in the target DB2 UDB.

To migrate the customizations, please follow our recommendations in Chapter 4, "Porting with MTK" on page 63, and Chapter 5, "Conversion reference" on page 149.

Migration project

The migration project includes the following key steps:

Selection of migration service provider
Project planning and analysis
Migration of development, test and production
Education and training of administrators and end-user
Acceptance test

Regarding education and acceptance test, see the information in 7.1, "Application migration planning" on page 226.

Selection of migration service provider

Select a service provider of your choice, which helps you to run the migration process. Your PeopleSoft provider or IBM supports you in your project. For contacts, please have a look to the IBM migration Internet site: http://www.ibm.com/software/data/db2/migration/

Project planning and analysis

Analyze the number and type of your database environment. Determine the number and identity of customized tables, indexes, and views. Create a migration plan as we recommend in Chapter 2, "Oracle migration project planning" on page 29 together with your vendor and service provider.

Migration process

PeopleSoft recommends that you migrate first the development, and if available, the test environment before migrating the production environment. In a typical PeopleSoft installation, there is the time required in each of the following phases:

Development: one to three weeks
Test: one to two weeks
Production: one to two weeks

The migration steps are:

Load RDBMS onto system.
Load Peoplesoft software onto system.
Select data unload/load tool (provided by PeopleSoft or RDBMS vendor provider).
Create database.
Include extensions/customizations.
Define tablespaces/physical layout.
Unload source database.
Load destination database.
Test load and repeat steps if necessary.

Data migration

For moving data from Oracle to DB2 UDB in a PeopleSoft environment, you have to export the Oracle data and import it into DB2 UDB. Therefore, you have these options:

DataMover utility

A graphical utility to move PeopleSoft databases across operating systems and database platforms
Creating a flat file by exporting data from tables. Once the flat file has been created in one of the three acceptable formats which are:
- ASCII
- ASCII delimited file
- Integrated Xchange Format (IXF)
IBM DB2 Information Integrator

View popular relational data sources and non-relational data sources as if they were local DB2 UDB data sources.

DataMover Tool

DataMover is a PeopleSoft Tool that provides a convenient way to perform the following tasks:

Transfer application data between PeopleSoft databases
Move PeopleSoft databases across operating systems and database platforms
Execute SQL statements against any PeopleSoft database, regardless of the underlying operating system or database platform
Control database security and access

DataMover is used to create, edit, and run scripts. These scripts may include any combination of SQL commands and DataMover commands for exporting and importing database contents, among other things. The default file extension for scripts is .DMS (for DataMover Script).

DataMover commands are platform-independent and are unique to DataMover. You can use DataMover commands for importing, exporting, and other tasks, such as controlling the run environment, renaming fields and records, database security administration, and denoting comments.

If you plan to create or edit DataMover scripts, you will need to keep the syntax rules in mind to make sure your commands run successfully.

Further information

For more information about PeopleSoft:

Redbook:
- Planning for a Migration of PeopleSoft 7.5 from Oracle/UNIX to DB2 for OS/390, SG24-5648
- Planning to Install PeopleSoft with DB2 for OS/390, SG24-5156-01
PeopleSoft Web site: http://www.peoplesoft.com

7.3.3 Siebel

Siebel solutions are implemented in a layered architecture with database independence. Thus, the Siebel application layer and business logic layer is not affected from the database migration. Figure 7-4 shows the typical migration process of a Siebel System.

click to expand
Figure 7-4: Siebel migration process

We recommend that you involve Siebel or a certified partner in the migration planning for a successful realization.

For detailed information about Siebel migration, see the redbook Migrating Siebel Database from DB2/Oracle for NT to DB2 for OS/390, SG24-6236.

Planning tasks

Before performing a migration, there are a few planning tasks that need to be carried out. It is important to migrate a version of Siebel on a source system to the same level of Siebel on a target system. Whichever database migration process you use, it will be sensitive to Siebel versions, as each version of Siebel may have different database tables and columns.

If you need to migrate to a later version of Siebel, you need to upgrade your existing implementation to that level before migrating.

You need to make sure that your installation has all the required FixPacks applied for the version of Siebel you are trying to install. These can be found in Siebel's Product Availability Matrix.

Estimate the size of the target database server and the size needed for a data migration.

Identify personnel with database and Siebel customization skills. Analyze the amount of customization, and plan workarounds especially when Oracle specific features are used.

Once these tasks have been carried out, it will be possible to plan the data migration in more detail.

Setting up the target system

To set up the environment, consider the recommendations from Siebel.

Data migration

You have more options to migrate data from the source database to the target. Siebel delivers two utilities called Dataexp and Dataimp, which are often used by Siebel services personnel to move data.

You can pass each utility the name of the database and a list of tables to process. The Dataexp utility will export the data from the tables and stores the results in a data file, which is independent of the database implementation. Dataimp takes this file and inserts the contents into a target database.

Having a database independent data file means that we can use Dataimp to insert the data to a different target. This is exactly how Siebel handles distributing the seed and base repository data for different operating systems.

Dataexp and Dataimp is the ideal method for migrating any Siebel data with the minimum of coding and administration. Running Dataimp for very large volumes is not advisable due to the insert process. Alternatively, you can use the tools mentioned in Chapter 6, "Data conversion" on page 211, which may help you get around the potential long run times.

Migrating additional programs

In a typical Siebel installation there are additional programs such as batch jobs, which are not delivered by Siebel. You have to migrate these programs using the custom-build databases and application migration process we provide in this book.

Test

Once the data migration process has been completed, you should run various tests against the old system and the new system to make sure that they operate the same way, and return the same data with the same search criteria.

Further information

More information about Siebel application and database migration is available in:

Redbooks:
- Siebel 2000 Database Implementation on OS/390 Using NT Siebel Servers, SG24-5953
- Migrating Siebel Database from DB2 NT to DB2 S/390®, SG24-6236
Web site: http://www-3.ibm.com/software/data/partners/ae1partners/siebel/

< Day Day Up >