Categories
- All Categories
- Oracle Analytics Learning Hub
- 19 Oracle Analytics Sharing Center
- 18 Oracle Analytics Lounge
- 231 Oracle Analytics News
- 44 Oracle Analytics Videos
- 15.9K Oracle Analytics Forums
- 6.2K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 86 Oracle Analytics Trainings
- 15 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Backward compatibility between OAS 2025 and OAS 2024 during staggered upgrades
Hi all,
We’re planning a staggered upgrade from Oracle Analytics Server (OAS) 2024 to OAS 2025 across multiple environments (DEV → TEST → UAT → PROD). We’ll be upgrading one environment at a time, so there will be a period during which some environments run on 2024 and others on 2025.
Before we lock dates, I’d like to confirm compatibility and promotion paths during this mixed-version window.
If you have official docs/notes, compatibility matrices, or a MOS note that spells this out for OAS 2025 vs 2024, I’d really appreciate the references. Also, happy to hear real-world experiences from anyone who’s done a staggered 2024 → 2025 rollout.
Thank you
Best Answer
-
Hi Stephanie (@User_XF8Z3),
Welcome to the Oracle Analytics Community! We are glad you are here, and it is a good question.
Our documentation (or MOS notes) will provide guidance on how to upgrade (i.e. - steps), but not so much on the strategy.
I will definitely welcome community comments for that part. There is a lot of experience in this community.
What I will say, is that when developing your upgrade plan, is that you do not want to develop in a newer update environment (OAS 2025) and deploy elements in an lower update environment (OAS 2024). This is especially true with Data Visualization Workbooks (i.e. export DVA) and snapshots. You can get away with it on the Classic Dashboard/Analysis side with catalog archive/unarchive, but a best practice is to not move from newer to older instances.
It may be worth the extra resources to have a dual DEV2024/DEV2025 and TEST2024/TEST2025.
I will be interested to hear what the community shares with you here, in terms of their vast experiences.1
Answers
-
The short version is: what Steve said :D
When you deploy objects in OAS, in some of the processes (there are many way to deploy different pieces, not all works exactly the same) there is a step checking if the objects need to be upgraded. If required, it happens automatically, without even noticing if you don't dig in your logs to find the line saying it did happen.
That's definitely the case when deploying a BAR file.By design, historically, the product was never really built to support "downgrades", there were undocumented methods to go from newer to older versions, but it was mostly at your own risk and if you were really desperate enough.
Therefore, plan your upgrade to do as Steve said: always moving content only from 2024 → 2025 or from 2025 → 2025. Maintaining this rule should then drive the order in which you upgrade your environments, based on your own processes around development, testing and releases to prod. Because of this rule it could sound like the suggestion is to first upgrade your PROD, as it's the final piece in the deployment chain: that's probably not what you want to do (except if are planning out-of-place upgrade to also upgrade hardware/OS etc.).
Most of the time, in the upgrades I saw, a freeze in deployments has been required when not having a new environment and only working with in-place upgrades on DEV-TEST-PROD. As an upgrade is a yearly or every two years, it often isn't a huge issue to freeze deployments for it.
2
