White Paper on Oracle Apps Migration Project

Things to take care in a migration project..
These are all my personal observations if any one has anything new to add plz put out a mail i will incorporate them also..

Now a days we are coming across many migration projects..comparitviely these are supposed to be easy and straight forward..
But if we take care of few more things..it would be even smoother...

What is a migration project.??
It is moving from a product of lower version to a product of higher version(the other way is also called migration only)

What will the customer expect??
He expects a higer performance from the system
Added new Functionality
Better support from oracle
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

What are the major challenges for it?
1.The amout of customization in the legacy system
2.Type of Customization--whether custom built modules /Standard process customised
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 customising the standard obejcts like (standard reports,standard forms,workflow..)

What are different phases in it?
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.Optimised migration--We redo the migration phase again in short span of time to calculate the exact cut over time
3.MTP--Movement to production

What all we need to take care???

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 problem 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

Database Layer Change:As the product is migrated there might be a database change happend 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

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

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 number 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
Standard Form object migration: Migration will take care of the upgradation of standard objects. Hope that there are no customisation at
the code level for the standard objects.In case if there are any try to redo the customisation using the new feautures
like forms personalizations,custom.pll.One more important thing is before doing the customisation 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 redoiing them .

Custom Form Objects Migration:This is not as simple as the reports..There is a FLINT60(upto 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 migrated using the flint60 utility and manually changes need to be made to have
the same look and feel of the new version.
For detailed steps of using flint60 and custom form migration check my blog http://oracleappstechnicalworld.blogspot.com/

Legacy Sytem 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 softwares
1.For file system integration check the directory permission and UTL_DIR_PATH variables in the legacy and new system
2.For dblinks one check whether the dblinks can be created between the new database version and the database version of the legacy system.Better to confirm at the assesment stage itself in case not, time need to be allocated for alternative solution implementation
3.Check througthly the compatabilities in case some thing 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 enviromental
setup should be a task in the migration.process.


General Observations: One important thing to remember is the migration will get overwrite 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 has to be redone.