Skip to main content

Oracle

Articulated & Optimized EBS Upgrade Strategy – Why, What & How?

Istock 1255683032

Due to the end of Premier Support for EBS R12.1.3 approaching quickly, R12.2 upgrades are in extremely high demand.  I thought I would share a few things I’ve learned based on my experience. Most of the DBAs across the shores in my circles are having a very hard time trying to upgrade both 19c and R12.2 within a single downtime window, due to the complexity caused by the multitenant database with dual file systems and its effect on the applications. Let’s dive in further and walk through what is needed for an effective and seamless upgrade.

Roadmap12082020

Image Courtesy – Release Schedule of Current Database Releases (Doc ID 742060.1)

Why the sudden surge to EBS database and applications upgrades?

Database 12.1.0.2 Extended Support has a fee waiver until July 2022 and EBS R12.1 Premier Support is provided through December 2021.  Due to these dates fast approaching, customers are expediting their journeys to the 19c database and EBS R12.2.  See the following documents for more details on the current support expiration dates.

Extended Support License Uplift Fee Waiver for Oracle Database 12.1 and 11.2 for Oracle E-Business Suite (Doc ID 2522948.1) – This document explains about the fee waiver on R12.1 database until July 2022.

ANNOUNCEMENTS: E-Business Suite 12.1 Premier Support Now Through Dec. 2021 and 11.5.10 Sustaining Support Exception Updates (Doc ID 1495337.1)

Oracle - Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud
Guide to Oracle Cloud: 5 Steps to Ensure a Successful Move to the Cloud

Explore key considerations, integrating the cloud with legacy applications and challenges of current cloud implementations.

Get the Guide

Whether to perform an on-prem upgrade is no doubt a tough decision due to Oracle’s Cloud ERP offering being another option. This blog is not about the on-prem vs Cloud ERP discussion, it is focused on best practices of a seamless 19c/EBS 12.2 upgrade that apply to systems hosted both on-prem and within OCI (Oracle Cloud Infrastructure).  Without a question, combined 19c/EBS R12.2 upgrades are way more complex, but the right planning makes it manageable. Here are a few thoughts based on my experience on how best to consider things pro-actively and plan it up front, and how that can help produce a smooth and seamless upgrade.

What is the best approach for patching?

We all know these upgrades are more about patching, which starts with interoperability, PSU, upgrade technology stacks and update packs and ends with many standalone patches for specific bug fixes. Your patching strategy is key to drive the upgrade effectively and reduce the downtime window. Thorough patch analysis along with appropriate parameter and option usages can make a significant difference on upgrade time.  A lot of crafting and drafting is needed to optimize this. Many times DBAs may choose to pick the ‘-1’ version on the patches like PSUs or technology stack. But due to the complexity and the number of upgrade iterations involved, the project duration could easily take anywhere from a single quarter to over a year.  As a result, whether you choose the latest and greatest available patch versions is very important otherwise you could effectively be installing different patches in each upgrade iteration.  For stability, try not to add the latest versions of patches each time, and lock the patching document on some of these patch types after a couple of iterations.  Of course this rule has to be flexible.  Circumstances like a bug or performance issue might require a newly released version of a patch, but those should undergo approval and thorough testing before they are included in the upgrade. Adding these kinds of patches right before go-live is a big no-no, and the earlier you apply that rule in the project, the better.  You can always bring an instance up to date on patch versions after go-live, as part of support best practices and regular maintenance.

What is needed for a seamless approach?

This is a complex effort and here are a few things you should consider to help you drive the complete effort seamlessly.

  1. Take it very seriously. Many IT teams may not realize the full impact of the upgrade project, based on the fact that these upgrades are not subset version upgrades as their names suggest (e.g. R12.1 to R12.2).  These teams should strongly consider project management due to the massive stakeholder involvement in these upgrades.
  2. Document every detail and solidify the implementation document with the applicable time taken for each step. Also maintain an issues log through all testing performed across the teams. Lock the document after a couple of iterations to avoid any surprises during go-live.
  3. Perform as many iterations as possible to reduce the go-live downtime window, and to improve repeatability.
  4. Split the activity proportionate to the complexity of topology in your environment and when necessary use subsequent weekends after go-live for non-critical business configurations.
  5. Make sure to thoroughly follow below doc for Oracle Best Practices to reduce the upgrade downtime effectively.

Best Practices for Minimizing Oracle E-Business Suite Release 12.2.n Upgrade Downtime (Doc ID 1581549.1)

Businessman Pushing A Sphere Leading The Race Against A Group Of Slower Businessmen Pushing Boxes

How to organize any additional configuration pieces along with upgrade?

If the business downtime granted is just a weekend, because there is so much to deliver in addition to the database and EBS upgrade, you should determine a well-planned and approved approach considerably ahead of go-live. Many times the upgrade team is expected to deliver a bunch of additional modifications within a single upgrade window on top of just the database and EBS upgrades, such as SSO, TLS, TDE, JWS, DMZ (iReceivables, iSupplier, iExpense etc), and many other oracle product configurations, like Endeca, ECC, CCG etc.  Try to only add the products to the go-live window that are critical to business operations and handle the rest as post go-live.  To achieve this, the plan must be thoroughly designed in advance to determine exactly how much can be accomplished in the approved downtime window. Always discuss with your customer the option to split the upgrade into a few separate chunks as a workable strategy to meet the business needs and limit downtime.  This entire activity is very dynamic and it can be accomplished very smoothly with the right experts involved.

There are many more approaches to streamlining or reducing the downtime while still achieving an effective and efficient upgrade. Please reach us out for any questions on EBS database and application upgrades.  Our panel of Perficient experts is always here to serve and support your business.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Suresh Kapa, Technical Architect

Suresh Kapa is a Technical Architect in the Oracle ERP practice based out of Dallas, a Certified Oracle Cloud Infrastructure Architect with expertise in Oracle EBS/Oracle Databases and Associated Technologies. Suresh leads our Global Delivery Center ERP DBA production support team (24X7).

More from this Author

Categories
Follow Us
TwitterLinkedinFacebookYoutubeInstagram