If there is one thing all Oracle EBS Upgrade project managers agree on, it is to expect the unexpected.
There are many unknowns throughout the project, especially if your Oracle EBS system is customized.
As part of the upgrade, Oracle changes, deletes or obsoletes standard objects.
These may include: APIs, views, tables, packages, forms, alerts, concurrent programs, concurrent reports, profiles, framework files, workflows and more…
Oracle takes care of the standard code. However, if you have your own custom code, which is the case for most Oracle EBS shops, you are on your own!
Here is one example:
The standard table called: AP.AP_AE_HEADERS_ALL exists in the current version, but is obsolete in the target version you are about to upgrade to. Oracle will adjust all standard code referring to this table, but what happens if you have 5 custom reports, 2 alerts and 3 workflows referring to this table? They will all seem to work correctly in the upgraded instance, but the results will be incorrect since the table is no longer being populated by Oracle.
This is where the upgrade team comes into play!
Your Oracle EBS Upgrade Journey
If you are not using automated tools to support you through your upgrade journey you will be doing this investigation – one way or another – on your own:
Prepare a dev instance of the upgraded version
Do full regression testing to find out which objects are impacted
Investigate which customizations use the impacted standard objects
Fix /replace /adjust your custom code
Identify all entry points which are related to your code fix
Test them all!
We have gathered insights using our crowd wisdom analytics, based on over 500 successful Oracle EBS upgrade projects done with Panaya.
Learn How Synaptics saved 42% on their Oracle EBS upgrade >>
Planning an Oracle EBS Upgrade Project? Why stay in the dark? Contact us and gain full visibility and control over your upgrade project before it even begins!