As an Oracle EBS customer, you must be aware that premier support for version 12.1 has already ended. It means that you no longer will receive critical patch updates (CPU) related to security, taxes, legal and regulatory updates, and major releases for product and technology. You must be wondering what should be your next step. Well, upgrading to EBS 12.2 is a sustainable option for you since Oracle has promised to offer premier support till 2030.
Although, EBS 12.1 to EBS 12.2 upgrade keeps you compliant by ensuring delivery of new updates, fixes, or security patches, it is the last difficult upgrade you’ll ever make. In this article, we’ll discuss the best practices to ensure seamless Oracle EBS 12.2 upgrade.
The very first step of EBS 12.1 to EBS 12.2 upgrade is evaluation. Before initiating an actual upgrade, you need to evaluate the new capabilities and architectural enhancements that will come with the upgrade. You can refer to release notes to understand what will change in an upgraded system.
Planning is very important for a successful upgrade. You need to plan the project timelines, budgets, tools, and testing scope to ensure a successful upgrade.
CEMLI stands for Configurations/Customization, Extension, Modification, Localization and Internationalization, and Integration. CEMLI may either totally get removed or will require updates due to upgrade. With the help of evaluation, you can easily find out the amount of support needed from development teams. Furthermore, this will also highlight areas that may need additional focus during the upgrade testing activities.
Oracle EBS 12.2 upgrade involves significant changes in data model and functionality. Since R12.2 offers new features, functionalities and processes, it is critical to perform an assessment of your current applications usage, identify key processes, analyze third party components, and review existing customizations, modifications and enhancements. In case, some of the customizations or enhancements may get removed during upgrade, they need to be reimplemented.
You now need to start testing iteration on the practical clone of your production instance to understand the potential issues. Any of the issues need to be documented properly.
Since there’s a possibility that custom codes will get impacted during the upgrade, you need to make sure that there should be no process deviation. The custom codes shouldn’t be overwritten during the upgrade process. To ensure this, all interfaces, customized forms, descriptive flexfields, and customized reports need to be tested thoroughly.
Test scripts modification:
Test scripts used during initial implementation should be used as the baseline test scripts for the upgraded test environment. However, these test scripts need to be modified and additional scripts required to validate any change in the functionality.
User Acceptance Test:
This is the final step in which you need to validate functionality, business processes and data.
As you’re now aware that multiple rounds of testing is required along with the participation of business users, doing this manually isn’t a viable option. Availability of business users is also a matter of great concern since they’ve other jobs to do. It is recommended that you should opt for test automation. Since all test automation tools don’t solve your purpose, let us explain what you should look for in a test automation tool.
No code automation:
Since business users are involved in creating and executing functional testing, you need a no code test automation platform that can create scripts without requiring programming knowledge.
Prebuilt test accelerators:
Creating test cases from scratch is a daunting task. Prebuilt test accelerators will cut down your initial setup time.
Opt for a test automation platform that offers end to end testing across all the key integration points.
Test cases retrofitment:
Opt for test automation platform in which test cases can be retrofitted with simple drag-drop interface. This will significantly alleviate the burden of the business users.