Learn from the mistakes of others and make sure your R12.2 upgrade is a success.
R12.2 is considered by many to be the most technically complex Oracle E-Business Suite release due to new development standards that must be followed, and the many code changes required to make sure your current objects are compliant in R12.2.
Conversely, R12.2 presents the opportunity to consolidate business units into a single instance, reduce operational costs, and improve productivity with new functionalities like mobility and online patching.
So, how do you ensure your Oracle EBS R12.2 upgrade is successful? Here are six essential tips to increase the rate of success.
Tip #1 - Purge Strategy
- Removing historical data from the Production environment can be a key contributor to short upgrade execution.
- Remember: All Oracle modules do NOT have seeded archiving abilities.
- Upgrade execution time can potentially be shortened by removing historical data from the Production environment. Legal involvement in the decision for purge windows can slow the process.
- Purge and archive processing is not without issues, i.e. indexes needed, table space issues, etc.
Tip #2 - Simplify Object Remediation
- Remove all non-relevant objects from the scope. This applies to seeded and custom object remediation between Oracle Apps versions.
- Perform an impact assessment to pinpoint which customizations will be impacted or potentially impacted by the upgrade. This type of assessment can help you decide which customizations can be replaced with standard functionalities available in R12.2.
- Identify all custom objects, who owns the custom code, and the status of each object. Then, assign priority and ownership to the internal or integrator project team.
- Plan early for new RICE functionality replacement (Reports, Interfaces, Conversions, and Enhancements (or extensions)) or enhancement associated with gaps between Oracle releases.
Tip #3 - Technical Upgrade Strategy
- Allocate the appropriate amount of time and resources for an iterative upgrade approach. (nn simulations of the upgrade).
- Right-size Servers and Nodes — Capture accurate sizing to determine if existing hardware can be reused and will support production requirements or if switching to a new hardware platform is required during the upgrade.
- Perform full M-log refreshes.
- Develop an instanced strategy early on.
- Capture baseline execution timing starting with the first upgrade simulation.
- Set a clear backup strategy and capture regular backups during the upgrade process. This may be helpful if any issues are encountered during the upgrade process, as you may be able to restore the application environment to a specific stage rather than starting over. to start over the entire upgrade.
- Define a tight approach for patch tracking/application (patches required outside of the upgrade process to resolve application issues).
Tip #4 - Integration Touchpoint Planning
The number of integration touchpoints and third-party systems involved will impact the level of effort involved in your R12.2 upgrade. The more integration touchpoints or third-party systems involved, the greater the complexity and opportunity for risk. For example, there may not be enough test instances to have a 1-1 correlation to Oracle Applications. Understanding the impact of integration touchpoints and third-party systems will help you determine the optimal upgrade path and complexity of your upgrade.
Tip #5 - Oracle Apps Configuration
Make sure to document profile options before and after, and understand how to profile options have changed between your current EBS version and R12.2.x. You can also ease new instance setups by documenting new or revised application configurations.
Tip #6 - Run Book Documentation
The run book is a record of how you plan to execute the upgrade, the steps that will be followed, and the order in which each steps will be executed. It is never too early to start building a detailed list of execution activities with timing and ownership for the upgrade go-live. The run book should include activities owned by the business including configurations, penny-testing, etc. Documenting how your environment behaves during the upgrade is critical to ensuring the success of the overall upgrade and reducing the window for maintenance.
7 Additional Best Practices for Your R12.2 Upgrade
- Automate the remediation and testing of RICEFW (Reports, Interfaces, Conversions, Enhancements, Forms, and Workflows) and CEMLI objects (Configuration, Extension, Modification, Localization, and Integration).
- Decide on new business process changes early on.
- Reduce downtime by performance tuning the upgraded application.
- Prepare the business community and make sure users are available for User Acceptance Testing (UAT). User feedback is critical to understand whether there are any issues using the application, and if the application behaves as anticipated. Lack of availability during UAT can delay an upgrade by a month or more, especially during month-end or period-close. This roadblock can be avoided by mapping out your timeline accordingly.
- Account for systems and compliance. During the technical upgrade, it is critical to understand which systems and operations will be impacted by any outages and take into account areas like changes to database upgrades or hardware upgrades.
- Understand the project risks and know how to mitigate them - This can be as straightforward as utilizing pre-defined upgrade templates to help avoid common R12.2 upgrade pitfalls.
What's next?
Schedule a free consultation with our R12.2 upgrade team or book a demo to see how automation can simplify your R12.2 upgrade. Check out our other Oracle EBS blogs for tips and guides.
