Here's a quick follow-up to my earlier post regarding EPM 126.96.36.199 Initial Thoughts.
If you installed Oracle EPM 188.8.131.52 shortly after it was released in December 2019, you are likely considering moving up to EPM 184.108.40.206 so you may enjoy the new certifications for Microsoft Edge and Google Chrome.
But do you need to start all over? No, you don't!
As mentioned in the installation guide, 220.127.116.11 provides a Maintenance Upgrade option, whereby you may perform an in-place upgrade on 18.104.22.168 and bring it up to 22.214.171.124.
I ran this process over the weekend, and here are my observations:
In short, the process is easy and and is identical to how the in-place upgrade worked within the 11.1.1.x and 11.1.2.x series of releases. The installTool.cmd utility detects the previous installation and forces you to upgrade the existing components first before allowing you to go back and install additional components.
When you perform an in-place upgrade from 126.96.36.199 to 188.8.131.52, the binaries for Oracle WebLogic Server and Oracle HTTP Server initially remain untouched. All of the .ear files underneath \Oracle\Middleware\EPMSystem11R1\products, however, will be replaced by the upgrade.
One thing to note is when installTool.cmd reaches 97% progress and seems stuck at "updating Oracle Inventory", there are some additional things happening behind the scenes; the installer applies Oracle Middleware and Essbase patches during this phase. Patches previously applied by 184.108.40.206's installTool are re-applied by 220.127.116.11's installTool. These patches include Oracle WebLogic, Oracle HTTP Server, and Essbase.
If you use SmartView for Essbase, you will need to reapply the Java fix for Essbase SmartView ad-hoc. This is because installTool applies the Essbase patches in a slightly incorrect order, leaving two Java artifacts in Oracle\Middleware\EPMSystem11R1\common\EssbaseJavaAPI\18.104.22.168\lib\ with an incorrect version. Click the link within this paragraph to see the exact fix.
After you finish running installTool, configTool indicates the web applications need to be redeployed. In truth, this doesn't provide much benefit as WebLogic automatically picks up the newer .ear files the next time you restart services.
It isn't a bad idea to run the redeploy step, though, because the act of redeploying makes a few minor updates to the Shared Services Registry database. Specifically, a few components will have their version numbers updated from 22.214.171.124 to 126.96.36.199. This makes the EPM System Registry Report and also Help->About EPM System->Show Details slightly more accurate (although not exactly accurate in all cases). Doing this will help reduce some confusion should you need to work with Oracle Support in the future.
April 23, 2020 update: Michael Fredericks of FinWeb Solutions noted he received a Communication Error when trying to login to EPM Workspace after performing the upgrade. He resolved the issue by running the redeploy step. He also reminds us that when redeploying, we need to go back and re-apply any Java Heap customizations. Thanks for your comment on LinkedIn, Michael!
One final point about this in-place upgrade: You don't need to touch or re-do RCU.