Oracle E-Business Suite (EBS) is out of Premier Support for clients who failed to upgrade to Release 12.2 by December 2021. Some clients are desupported, others purchased Market Driven Support, and others went with third party vendors. Unfortunately, in all scenarios, clients are exposed to the risks and costs of working with an EBS software version that is no longer benefitting from the latest innovations or receiving updates, fixes, or security patches.
We’ve seen firsthand how some clients have had their entire operations halted by bugs that are not covered in desupported versions of EBS, or the added costs of having to patch code to make sure it stays somewhat stable. All in all, making the upgrade to R12.2 is critical, even if you’re getting ready for the cloud as it’s much better to do so from a stable system.
One of the things that put some clients uneasy about their EBS modernization to R12.2 is the volume of customizations in their software. Next, we’ll address some of the most pressing concerns clients have about customizations and what can be done to overcome them.
EBS Customizations
Customizations are implemented in the EBS software middle tier and the database. Generally speaking, customizations can be, but are not limited to:
- Modifications or extensions to the EBS code
- New database objects or modifications to the existing database objects
- Modifications of standard EBS partitioning schemes with custom partitions
- Third-party virtualization technologies for any of the EBS tiers: database, application server, or desktop
- Third-party tools for database modifications
- Third-party software integrations with the EBS environment for reporting purposes, or any other industry-specific functionality
- Third-party tools to manage or configure the EBS environment
- Third-party file systems to run EBS
In short, any modification introduced into the EBS environment that isn’t tested by Oracle is considered a customization and is not covered or patched by Oracle Support. The risk level of customizations depend on the level of involvement they have in EBS operations. Invasive customizations are typically non-advisable, and you can see Oracle’s support policies regarding customizations here. In summary, these Oracle policies come down to:
- Issues isolated to EBS will be investigated by EBS development
- Issues isolated to customizations or third-party tools should be addressed by the third-party vendor
- EBS Development will provide ebs patches for issues that can be reproduced in environments built using EBS documented procedures and tools
- If third party vendors can’t solve issues isolated to their tools, clients are advised to restore from a backup and revert to Oracle’s tools and procedures.
Regardless if you plan to keep your Oracle EBS environment on-premises or migrate to the cloud, you will benefit from having a customization strategy with EBS best practices.
Customizations, oftentimes referred to as CEMLIs, should be remediated to leverage standard functionality and minimize customizations to the greatest extent possible.
If you do decide to employ customizations, you should use personalizations and implement customization as extensions so as to not modify standard objects.
Last but not least, you should make sure your customizations or CEMLIs are compliant with R12.2 standards by ensuring adherence to the Global Standards Compliance Checker and Readiness Reports. Any customizations flagged as non-compliant, you should replace by creating extensions or personalizations.
Care to see a real-life case study from one of our clients to see how we helped expedite the Oracle R12.2.x upgrade? Download the case study here.
