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.
- Because there’s no separate reference environment (unlike an “out-of-place” upgrade), comparing dashboards, reports, and performance before and after the upgrade becomes challenging. For example, with 50 dashboards carrying extensive customization, confidently confirming none of them have regressed after an upgrade from OBIEE 11.1.1.7 to 11.1.1.9 is difficult without a systematic baseline.
- 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 and access compliance 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.
| # | Risk | What Can Go Wrong |
|---|---|---|
| 1 | No reference environment | Comparing dashboards, reports, and performance is hard without a baseline to check against |
| 2 | Presentation Server regressions | Layout changes (e.g., an extra table column) can slip into production unnoticed |
| 3 | Logical query impact | Minor upgrades can silently change query behavior (e.g., “count distinct” measures returning wrong data) |
| 4 | Compressed testing timelines | Limited time for QA can let issues like security/access misconfigurations go undetected until users report them |
| 5 | Limited downtime for validation | Production upgrades need fast regression testing, but manual validation takes longer than the business can afford |
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.
