In-place upgrades (e.g., OBIEE 11.1.1.7 to 11.1.1.9) carry hidden risks since there’s no reference environment to compare against. Common issues include unnoticed layout changes, logical query errors causing wrong data in charts, undetected security/access problems, and limited testing time before release. BI Validator solves this using its ELV architecture — teams baseline dashboards and reports before the upgrade, then run automated comparisons after, quickly surfacing any regressions in an intuitive, easy-to-understand format.
Key Takeaways
- No reference environment increases risk — unlike out-of-place upgrades, in-place upgrades lack a parallel environment for comparison, making it hard to confirm dashboards haven’t regressed after updates.
- Layout and logic errors can slip into production — presentation-layer defects (e.g., extra columns) or logical query bugs (e.g., incorrect “count distinct” results) often go unnoticed until users spot them.
- Limited testing windows raise the stakes — compressed timelines for QA and business analysts mean issues like broken access/security permissions may only surface after go-live.
- BI Validator enables baseline-and-compare testing — its ELV architecture lets teams capture a pre-upgrade baseline and run automated post-upgrade comparisons, clearly flagging differences before they impact business users.
In-place upgrades (e.g., OBIEE 11.1.1.7 to 11.1.1.9) carry hidden risks since there’s no reference environment to compare against. Common issues include unnoticed layout changes, logical query errors causing wrong data in charts, undetected security/access problems, and limited testing time before release. BI Validator solves this using its ELV architecture — teams baseline dashboards and reports before the upgrade, then run automated comparisons after, quickly surfacing any regressions in an intuitive, easy-to-understand format.
As most of us in the BI community are aware, In-Place upgrades are fairly common when clients want to go through minor upgrades (e.g OBIEE 11.1.1.7 to 11.1.1.9 or Business Object 4.1 SP5 to 4.1 SP 7). However, there are a number of risks which need to carefully addressed in such scenarios. Below are few examples of what can potentially go wrong and how you can leverage BI Validator to validate “In-Place” Upgrades.
- Since there is NO reference environment unlike an “Out-of-Place” upgrade, comparing dashboards and reports, performance etc becomes challenging. As an example, let’s say you have 50 dashboards with extensive customization, what is your confidence level that the dashboards have not regressed after an upgrade from say, OBIEE 11.1.1.7 to 11.1.1.9?
- Often, defects or regression in the Presentation Server module in the newer version of OBI may accidentally change the layout of the reports. For example OBIEE 11.1.1.7 to 11.1.1.9 caused an extra column to be added in the table view. In our experience, such issues slip through the cracks and and go into production, completely unnoticed. This could be minor but will leave a negative impression on the business user’s mind.
- In few cases, a minor upgrade may have an unintended impact on logical queries and that could result in unwarranted data differences in the upgraded environment. For example, in OBIEE 11.1.1.9, if you exclude a measure column with “count distinct”, the chart shows wrong data. It works find in the edit mode but shows wrong numbers when we run it.
- While in-place upgrades are inherently risky, the time allocated for Business Analysts, Quality Analysts and Testing Teams is relatively less and they may not be able to go through complete testing cycles. As an example, security (access) issues could go undetected until a business user files a service request indicating that they do not have access to a specific report in production.
- Since the production will also be upgraded, there is a need for running a quick set of regression tests before releasing the environment to the users. However, business cannot afford the long down times generally needed for validating the environment manually post upgrade.
Now, how can BI Validator help in the above situations?
BI Validator makes testing the above scenarios amazingly easy for you. Using our patented ELV architecture, you can baseline your dashboards and reports prior to the upgrade using simple user interfaces and then, run the tests after the upgrade. BI Validator presents any differences in a very intuitive manner so that the user can understand the exact differences and act accordingly.
Stay tuned to know how BI Validator can help during an “Out-of-place” Upgrade:
Try BI Validator today. It hardly takes 5 minutes to get up and running.
FAQs: In-Place BI Upgrades
1) Why are in-place BI upgrades risky compared to out-of-place upgrades?
In-place upgrades do not provide a separate reference environment for comparison. As a result, teams cannot easily verify that dashboards and reports continue to function correctly after the upgrade, making issues detectable only through testing of the upgraded production environment.
2) What kinds of problems commonly go unnoticed after an in-place upgrade?
Common issues include dashboard and report layout changes such as missing or extra columns, query logic errors that generate incorrect metrics or visualizations, and broken security or access permissions that prevent users from viewing reports.
3) How does limited testing time affect upgrade quality?
Compressed QA and business validation timelines often leave insufficient time to manually verify every dashboard and report. This increases the likelihood that subtle issues, including data discrepancies and access problems, remain undetected until after deployment.
4) How does BI Validator help reduce risk during in-place upgrades?
BI Validator automates regression testing by comparing reports, dashboards, KPIs, filters, security settings, and underlying data before and after the upgrade. This helps teams quickly identify changes, validate upgrade quality, and reduce the risk of production issues.
Rajesh Kumar A
Digital Marketing Manager, Datagaps
Digital Marketing Manager at Datagaps. Drives data-driven growth through content, performance campaigns, and marketing technology.
S P S Murthy Akella
Director, Technology Strategy, Datagaps
Director of Technology Strategy at Datagaps. Business solutions architect and Certified Scrum Master in data engineering, responsible AI, and ML across BFSI, telecom, aviation, and energy.
