7.1 Application migration planning

< Day Day Up >

Application migration is another major step in the entire migration project. The application migration process includes:

Check of software and hardware availability and compatibility
Education of developer and administrators
Analysis of application logic and source code
Setting up of the target environment
Change of database specific items
Application test
Application tuning
Roll-out
User education

The planning includes the creation of a project plan. Plan enough time and resources for each task. IBM and our business partners can help you with questions in order to define a well prepared project.

For the in-house developed applications, the migration effort is on the shoulder of the migration team. For package applications, you can contact the vendor for a recommended migration process. In 7.3, "Package applications migration planning" on page 250, we explain the recommended migration process of some packages.

Check software and hardware availability and compatibility

The architecture profile is one of the outputs of the first task of migration planning assessment. While preparing the architecture profile, you need to check the availability and compatibility of all involved software and hardware in the new environment.

Education of developer and administrators

Ensure that the staff has the skills for all products and the system environment you will use for the migration project. Understanding the new product is essential for analyzing the source system.

Analyze of application logic and source code

In this analysis phase you should identify all the Oracle proprietary features and the affected sources. Examples of Oracle proprietary features are direct SQL queries to the Oracle Data Dictionary, Optimizer hints and Oracle joins, which are not supported by DB2 UDB. You also need to analyze the database calls within the application for the usage of database API.

Setting up the target environment

The target system, either the same or a different one, has to be set up for application development. The environment can includes:

The Integrated Development Environment (IDE)
Database framework
Repository
Source code generator
Configuration management tool
Documentation tool

A complex system environment consists usually of products from different vendors. Please check the availability and compatibility before starting the project.

Change of database specific items

Regarding the use of the database API, you need to change the database calls in the applications. The changes include:

language syntax changes

The syntax of database calls varied in the different programming languages. In 7.2, "Self-build application" on page 228, we discuss the varieties of C/C++ and Java applications. For information regarding other languages, please contact IBM Technical Sales.
SQL query changes

Oracle support partly non-standard SQL query like including of optimizer hints or table joins with a (+) syntax. To convert such queries to standard SQL, you can use the MTL SQL Translator.

You need to modify the SQL queries to the Oracle Data Dictionary as well, and change them to select the data from the DB2 UDB Catalog.
Changes in calling procedures and functions

Sometimes there is a need to change procedures to functions and vice versa. In such cases, you have to change all the calling commands and the logic belonging to the calls in other parts of the database and of the applications.
Logical changes

Because of architectural differences between Oracle and DB2 UDB, changes in the program flow might be necessary. Most of the changes are related to the different concurrency model.

Application test

A complete application test is necessary after the database conversion and application modification to ensure that the database conversion is completed, and all the application functions work properly.

It is prudent to run the migration several times in a development system to guarantee the process, then run the same migration in test system with existing test data, then a copy or subset of productions data, before eventually running the process in production. Chapter 9, "Testing" on page 275 discusses the testing steps in detail.

Application tuning

Tuning is a continuous activity for the database since data volume, number of users, and applications change from time to time. After the migration, the application tuning should be concerned with the architectural differences between Oracle and DB2 UDB. For the details, please see Chapter 9, "Testing" on page 275, in the DB2 UDB Performance-tuning Guidelines, and the redbook DB2 UDB V7.1 Performance Tuning Guide, SG24-6012.

Roll-out

The roll-out procedure varies and depends on the type of application and the kind of database connection you have. Prepare the workstations with the proper driver (e.g. DB2 UDB Runtime Client, ODBC, JDBC) and the server according to the DB2 UDB version.

User education

In case of changes in the user interface, the business logic, or the application behavior because of system improvements, user education is required. Be sure to provide enough user education since the acceptance of the target system is corresponding to the skills and satisfaction of the users.

< Day Day Up >