Migration project

Migration project: It is moving data from a product of lower version to a product of higher version (the other way is also called migration only) or Migration of data means moving the data from one system to another using Interface Programs/APIs where both the systems have same structure of data.

E.g. Oracle Apps 11.5.7 to Oracle 11.5.10) or moving data from some legacy system to Oracle Apps.

Process of Migrating of data:

Ø   Identify the data to be imported to new system (Business requirement).

Ø   Extract the data into flat file/Staging table

Ø   Load the data into Interface Table(using SQL* Loader/DB Link/Others) after validation(If loading the data using Interface)

Different phases in Migration Project:

1.     Migration phase...First we will take a clone of the instance migrate the applications to the new version with the old data), Oracle provide the scripts to migrate the data and the software will install the new application objects.

2.    Optimized migration--We redo the migration phase again in short span of time to calculate the exact cut over time

3.    MTP--Movement to production

Expectations from Customer:

1.      Higher performance from the system

2.      Added new Functionality

3.      Better support from oracle

4.      The system is supposed to work the same way as it operates..But look and feel might be a bit different...Functionality should remain intact

Major challenges:

1.    The amount of customization in the legacy system

2.    Type of Customization--whether custom built modules /Standard process Customized

3.    Integration with other systems

4.    Support of new environments

5.    Amount of change in the product from old to new version

6.    Whether Standards followed while customizing the standard objects like (standard reports, standard forms, workflow...)

Few things are we need to Consider when we doing migration:

1.    Environmental change: some time the old systems might be in a different environment and new system will be on a different environment.
Like old one in AIX and new ones in red hat Linux.
One of the problems to expect is some commands in AIX might not work in Linux environments. So if we have shell scripts in or host script files..those need to be checked and changed for the new environment

2.   Database Layer Change: As the product is migrated there might be a database change happened like new not null columns getting added up
so incase you have any direct inserts happening into the oracle tables even interfaces they might need to be corrected and values need to be populated to the new not null columns

3.    Standard Report Modifications: Because the upgrade will get new application objects any modification done to the standard report objects will be lost. 
it is better to rename those objects and re-register them to keep intact the object for future migration

4.   Custom reports migration: For reports we need to just open the report in the new version of the report builder in case the report builder version difference exists use shift+cntrl+k to compile the objects and save it. This should make the reports work.
But from my personal experience we need to run all the reports and data validation should be done for all... This might be tedious task if there are huge numbers of reports, but it has to be done. Project plan should include the testing of each and every report (Just data level validation) One more important thing i heard the compilation of the report builder will not validate the query... so any column changes will not get reflected at migration time they can only be find out at run time 

5.    Standard Form object migration: Migration will take care of the Upgradation of standard objects. Hope that there is no customization at the code level for the standard objects. In case if there are any try to redo the customization using the new features like forms  personalizations,custom.pll.One more important thing is before doing the customization check whether those are really required in the new system also..Even the customer process also might have changed...so check with the customer also before redoing them. 

6.   Custom Form Objects Migration: This is not as simple as the reports..There is a FLINT60 (up to 11.5.10.2) or Corresponding utility available to 
upgrade the forms from the previous version to the new version. The major road block is if the forms are not developed 
as per oracle application standards. Like property paletter not defined, seperate button to popup lov’s and other...In that case the form has to migrate using the flint60 utility and manually changes need to be made to have 
the same look and feel of the new version. 

Conversation: Conversion of data means translating the data to suite target system (data should be formatted according to target system)  and then move the translated data using Interface Programs/APIs.

v   Identify the data to be imported to new system (Business requirement).

v   Extract into flat file/Staging table

v   Translate/Convert/Format the data

v   Load the data into Interface Table(using SQL* Loader/DB Link/Others) after validation(If loading the data using Interface) and then launch standard Interface concurrent program to load the data to Oracle Apps Base Tables

v   If using API, fetch the data, validate it and then call API to import the data

Legacy System Integration: This will be one of the big task..The first step we need to do is figure out how the legacy systems are integrated
1.Through File system
2.Through DB Links 
3.Third party software’s 

1. For file system integration check the directory permission and UTL_DIR_PATH variables in the legacy and new system

2. For dblinks one checks whether the dblinks can be created between the new database version and the database version of the legacy system. Better to confirm at the assessment stage itself in case not, time need to be allocated for alternative solution implementation

3. Check thoroughly the compatibilities in case something like this exists

Pro*c Programs: The pro*c files need to be recompiled on the new instance.Pro*C Environment need to be set on the new application .If there any custom pro*c programs Pro*c environmental 
setup should be a task in the migration Process.

General Observations: One important thing to remember is the migration will get overwrites all the standard objects and standard application data ex: FND Messages. Suppose in the old instance you have changed the standard message text, then that change will be lost in the migration process. Those changes have to be redone.