Custom code can be expensive to develop but even more expensive to maintain.
Minimize EBS custom code
Try to eliminate as much custom code as possible. Research the more recent releases to see if new functionality replaces the homegrown code.
Set up queries or monitor the concurrent requests to see if reports and even interfaces are being used.
Global companies may see that the improved localization functionality in R12 can allow them to eliminate some custom code as well.
If you have taken copies of standard Oracle reports and modified them, the best practice is to take a new copy of that object from the new release and reintroduce the modifications. Don't spend inordinate amounts of time trying to get an old 11i report to work in an R12 environment.
The same recommendation holds true for workflow items.
While many standard open interfaces and APIs are typically not heavily changed during the migration to EBS R12, you may rename interfaces, and add new or additional parameters.
Event alerts are typically disabled during the upgrade, so you may need to re-enable them prior to testing.
Customizations to Oracle Forms can be tricky, as they are probably one of the most invasive customizations besides database triggers. If your business processes require modifications to the forms, replace them with personalizations as much as possible. If you do have customized forms, look to see if those forms will exist in the new, plain-vanilla version. Some EBS modules have quite a few brand-new forms.You should be able to replace some old forms with new OA Framework-based forms.
Finally, consider the third-party products that you may have previously licensed. You may be spending extra money for functionality that has now been introduced into the applications. Examples include third-party form and label software, check printing software, invoice printing and delivery solutions, and more.