• 04 Aug 2026

On-Premise Reporting for Oracle Cloud: What Organizations Are Getting Wrong

Oracle Cloud adoption has accelerated sharply across enterprise finance, HR, and supply chain over the last five years. Organizations have migrated their ERP and HCM workloads to Oracle Fusion Cloud, but the reporting architecture has often lagged. Thousands of enterprises are still running Oracle Business Intelligence Enterprise Edition (OBIEE), BI Publisher, and Discoverer on-premises against Oracle Cloud data via custom ETL extracts, a fragile, maintenance-heavy architecture that Oracle has provided a direct solution for. DataTerrain has supported 400+ US Oracle clients through this transition and has a clear view of what is and is not working in practice.

Quick Summary: Oracle Cloud adoption has created a reporting architecture problem many organizations have not yet resolved: they moved their ERP and HCM workloads to Oracle Fusion Cloud but kept their on-premise reporting layer running on OBIEE or BI Publisher against custom ETL extracts. OBIEE 11g mainstream support ended December 2022. OBIEE 12c extended support ended December 2025. Organizations running on-premise OBIEE against Oracle Cloud data in 2026 are operating on unsupported software with custom ETL dependencies that add latency, failure risk, and maintenance cost. Oracle Analytics Cloud (OAC) with native Fusion connectors eliminates the ETL layer entirely and is the supported replacement for both reporting tiers.
Oracle Cloud Applications
  • Share Post:
  • LinkedIn Icon

The Reporting Architecture Problem with Oracle Cloud

When an organization moves its ERP or HCM application to Oracle Fusion Cloud, the application data no longer lives in an on-premises database that OBIEE can query directly. OBIEE's Physical Layer connection pools, which were configured to point at an on-premises Oracle database, now need to reach Oracle Fusion Cloud's data layer. This creates two broad approaches organizations take, and one of them compounds the problem rather than solving it.

The fragile approach is to maintain on-premises OBIEE and build custom ETL pipelines to extract data from Oracle Fusion Cloud into a local or replicated database that OBIEE can still query. This preserves the existing OBIEE report catalog but adds ETL latency, failure points, data freshness risk, and an ongoing maintenance burden for the ETL layer. It also produces a reporting environment that operates on data that is hours or days behind Oracle Fusion Cloud rather than in real time. The bigger issue in 2026 is that this approach runs on OBIEE software that Oracle no longer supports, meaning security vulnerabilities and bugs discovered in OBIEE 12c will not receive patches.

The supported approach is migrating to Oracle Analytics Cloud (OAC) through Oracle Analytics Cloud migration services and connecting to Oracle Fusion Cloud through native, certified adapters that read data directly in real time, with the full Oracle support lifecycle ahead.

Oracle Analytics Cloud

The OBIEE Support Lifecycle: Why This Is Urgent in 2026

The urgency of resolving the on-premise reporting architecture problem is not primarily architectural: it is a support lifecycle issue. Figure 2 shows the timeline clearly. OBIEE 11g mainstream support ended in December 2022. OBIEE 12c extended support ended in December 2025. As of August 2026, organizations still running either version are operating on Oracle software that no longer receives security patches, bug fixes, or technical support from Oracle. Any security vulnerability discovered in OBIEE after December 2025 will not receive an Oracle patch, placing those environments at risk for compliance and security.

Oracle Analytics Cloud

On-Premise Reporting Options for Oracle Cloud

For organizations that cannot immediately migrate to OAC but need to maintain reporting on Oracle Fusion Cloud data, four technical options are available. Each involves trade-offs between real-time access, maintenance overhead, and security risk.

Oracle Data Gateway

Oracle Data Gateway is a component within Oracle Analytics Cloud that securely connects OAC to on-premises data sources without exposing those sources directly to the internet. The gateway agent runs in the on-premises network, handles authentication, and creates an encrypted tunnel between OAC and the local database. This option requires an OAC subscription but enables hybrid reporting that combines Oracle Fusion Cloud data with on-premises sources within a single governed environment.

Oracle Smart View

Oracle Smart View pulls Oracle Fusion Cloud data directly into Excel on a local computer, enabling financial planning, ad hoc analysis, and formatted reporting from a familiar spreadsheet interface. Smart View supports Oracle Fusion ERP, HCM, and EPM data with drill-down capabilities and live refresh against Oracle Cloud. It is most appropriate for finance teams that need Excel-based analysis rather than full BI platform replacement.

BI Publisher on Oracle Cloud

Oracle BI Publisher (BIP) is available as a built-in reporting tool within Oracle Fusion Cloud applications. Organizations that maintain separate on-premises BI Publisher installations can use Oracle BI Publisher migration services to consolidate into the cloud-native version. The cloud version handles pixel-perfect formatted document generation, scheduled reports, and bursting: the same functions that on-premises BI Publisher handled. Organizations that are maintaining a separate on-premises BI Publisher installation for Oracle Cloud reporting can migrate that workload to the cloud-native BIP instance included with their Oracle Fusion subscription.

OTBI: Oracle Transactional Business Intelligence

OTBI (Oracle Transactional Business Intelligence) is the built-in self-service reporting tool for Oracle Fusion Cloud reporting. It provides subject-area-based ad hoc analysis, prebuilt, Oracle-maintained content for ERP and HCM, and real-time query access to Fusion transactional data without any ETL or replication. OTBI is the fastest path to replacing OBIEE for operational reporting use cases, though it lacks the depth of a full RPD-based semantic layer for complex cross-functional analytics.

Data Replication to Cloud Warehouses

Organizations that need to combine Oracle Fusion Cloud data with non-Oracle sources in a unified analytics environment can replicate Fusion Cloud data into a cloud data warehouse such as Snowflake or Azure Synapse Analytics. This approach uses Oracle's native data export capabilities or third-party connectors such as Fivetran to replicate data at a defined frequency, which then feeds into Power BI, Tableau, or OAC for analytics. It preserves on-premises reporting tool access for organizations that cannot immediately migrate, though it reintroduces latency: organizations needing full pipeline migration can explore ETL migration solutions and replication overhead that OAC native connectors eliminate.

Oracle Analytics Cloud (OAC): The Recommended Path

Oracle Analytics Cloud (OAC) is Oracle's cloud-native analytics platform and the direct successor to OBIEE. For organizations on Oracle Fusion Cloud, OAC provides the most direct and supportable path because it connects to Oracle Fusion Cloud ERP, HCM, and EPM through certified native connectors that require no custom ETL. The native connector reads data directly from the Oracle Fusion Cloud application layer, delivering real-time query access, automatic schema updates when Oracle updates the Fusion data model, and a governed connection that Oracle supports and maintains.

OAC also supports RPD-based semantic layer migration from OBIEE, meaning existing repository investments- years of report and business logic development- can be carried forward into the cloud environment rather than being rebuilt from scratch. OAC includes AI Narratives, which automatically generate natural-language summaries of dashboard data; Pulse for mobile analytics; and Oracle's ongoing quarterly feature updates that OBIEE on extended support no longer receives.

What Native OAC Connectors Enable That OBIEE Cannot

The shift from OBIEE with custom ETL to OAC with native connectors eliminates three categories of operational cost and risk that the custom ETL approach introduces:

  • Real-time data access: Native OAC connectors query Oracle Fusion Cloud data during report execution. Custom ETL extracts introduce a time lag between when data changes in Fusion Cloud and when it appears in OBIEE reports, leading to reconciliation issues for finance, HR, and supply chain reporting, where decisions depend on current data.
  • ETL maintenance elimination: Custom ETL pipelines built to extract Oracle Fusion Cloud data into an on-premises database require ongoing maintenance as Oracle updates the Fusion Cloud data model. Oracle releases quarterly updates to Fusion Cloud applications that can change table structures, add fields, or modify the data model. Native OAC connectors handle these changes automatically; custom ETL pipelines break and require manual repair after each Oracle update.
  • Security and compliance alignment: Running custom ETL that extracts Oracle Fusion Cloud data into an on-premises database creates copies of enterprise data outside the Oracle Cloud governance boundary. Data that resides in an on-premises OBIEE database requires its own security controls, backup management, and compliance documentation, in addition to those for the Oracle Cloud environment. Native OAC connectors keep data in Oracle Cloud and apply Oracle Cloud's governance controls to all reporting access.

What Organizations Are Getting Wrong

Four patterns account for most of the on-premise reporting problems DataTerrain encounters in Oracle Cloud migration engagements:

  • Treating reporting as a post-migration task: Organizations that migrate Oracle ERP or HCM to Fusion Cloud without a parallel plan for the reporting architecture create a gap that becomes increasingly expensive to close. Reporting migration planned concurrently with application migration costs significantly less than reporting migration addressed 12 to 18 months after go-live, when the custom ETL architecture has accumulated additional development and documentation debt.
  • Assuming OBIEE can access Oracle Cloud data the same way it accessed on-premises data: The connection model is fundamentally different. OBIEE's Physical Layer cannot directly connect to Oracle Fusion Cloud's data model the way it connected to an on-premises Oracle database. Custom ETL is not a direct connection: it is a copy, with all the latency and maintenance overhead that implies.
  • Underestimating OBIEE support lifecycle risk: Organizations that plan to maintain OBIEE for Oracle Cloud data for "another two to three years" while developing a migration plan are often unaware that OBIEE 12c has already reached end of support. The risk is not theoretical; it is current and affects the insurance, audit, and compliance posture of every organization still running OBIEE in 2026.
  • Not accounting for the Oracle BYOL migration credit: Oracle provides BYOL (Bring Your Own License) credits for organizations migrating existing OBIEE processor licenses to OAC subscriptions. Organizations unaware of this commercial option may be planning migration budgets that overestimate the cost of switching to OAC.

Still running OBIEE against Oracle Fusion Cloud data?

Get a free Oracle reporting architecture assessment to identify migration risks, unsupported components, and modernization opportunities.

Request Oracle Cloud Reporting Assessment

DataTerrain's OBIEE to OAC Migration Approach

DataTerrain migrates OBIEE environments to Oracle Analytics Cloud using a structured five-phase methodology covering OBIEE report conversion, repository migration, catalog content migration, connection reconfiguration, parallel validation, and post-migration optimization. Automated conversion tooling handles RPD version compatibility, catalog object migration, and output validation between OBIEE and OAC, reducing migration timelines by 40 to 60 percent compared to fully manual approaches. DataTerrain's Oracle HCM Analytics experience means we handle the HCM-specific OTBI subject areas and BIP report migration that general Oracle migration partners often treat as out of scope.

OBIEE to Oracle Analytics Cloud Migration Roadmap

This five-phase roadmap covers the end-to-end migration process from OBIEE to Oracle Analytics Cloud and supports searches for "OBIEE to OAC migration steps" and "Oracle Analytics Cloud migration process".

Phase Activities
Phase 1
Assessment
  • Inventory all dashboards, analyses, and prompts using OBIEE catalog usage statistics.
  • Review all RPD objects including logical tables, joins, and measures for version compatibility.
  • Identify unused reports (not accessed in 12+ months) for archival rather than migration.
Phase 2
Migration Planning
  • Map all OBIEE objects to their OAC equivalents and flag items requiring manual reconfiguration.
  • Define the OAC architecture: virtual datasource configuration, security model, and connection pools.
  • Identify all custom SQL dependencies, embedded JavaScript, and action links requiring special handling.
Phase 3
Migration
  • Convert and upload the OBIEE repository (RPD) to OAC; resolve all consistency check errors.
  • Migrate catalog content: dashboards, analyses, prompts, KPI watchlists, and agents.
  • Migrate the security model: application roles, data filters, object permissions, and SSO configuration.
Phase 4
Validation
  • Run side-by-side report comparison: compare OBIEE and OAC outputs for all migrated dashboards.
  • Data reconciliation: validate row counts and aggregate values between OBIEE and OAC for all datasets.
  • Performance testing: confirm OAC query execution times meet or exceed OBIEE baselines under load.
Phase 5
Go-Live
  • User training: role-based OAC training focused on DV canvas and self-service analytics features.
  • Monitoring: configure OAC usage-tracking and performance-monitoring dashboards post-cutover.
  • Optimization: review virtual datasource caching, query execution plans, and OAC feature adoption.

Key Takeaways

  • OBIEE 12c extended support ended December 2025: organizations running OBIEE against Oracle Fusion Cloud data in 2026 are on unsupported software that no longer receives security patches from Oracle.
  • OAC native connectors eliminate the custom ETL layer: real-time access to Oracle Fusion Cloud data without replication removes the latency, maintenance, and security boundary issues that the ETL approach introduces.
  • OTBI and BI Publisher are already available in Oracle Fusion Cloud; organizations that maintain separate on-premises reporting instances for operational reports and formatted documents can migrate those workloads to the cloud-native equivalents included in their Oracle Fusion subscription.
  • Oracle BYOL credits reduce OAC migration costs: existing OBIEE processor licenses can be credited toward OAC subscriptions, and this should be factored into any migration budget before the commercial case for OAC is assessed.

Conclusion

The on-premise reporting for Oracle Cloud problem has a clear, supported solution. Oracle Analytics Cloud (OAC) with native Fusion connectors eliminates the custom ETL latency and maintenance overhead that OBIEE-based architectures introduce, operates within Oracle's active development lifecycle rather than on expired support, and carries forward the RPD and catalog investments organizations have already made. Organizations still running OBIEE 11g or OBIEE 12c against Oracle Fusion Cloud data in 2026 are managing a security and compliance risk alongside an architectural inefficiency. The migration path is well-defined, and the commercial incentives (BYOL credits) are available. The question is no longer whether to migrate but how quickly the transition can be structured safely.

Why Organizations Choose DataTerrain for Oracle Cloud Reporting Migration

DataTerrain is a specialist Oracle Analytics migration partner with over 17 years of experience and 400+ US clients. For Oracle Cloud reporting migrations, DataTerrain migrates OBIEE and BI Publisher environments to OAC with automated repository conversion, catalog migration, and output validation, reducing migration timelines and ensuring report parity before cutover. DataTerrain also migrates the legacy report layer alongside Oracle HCM and ERP application migrations so the full analytics environment is production-ready at go-live.

Contact DataTerrain for a free Oracle Cloud reporting assessment, or visit our website to explore the full range of Oracle Analytics migration services.

Explore DataTerrain's Oracle Cloud Reporting Services

Frequently Asked Questions

OBIEE can connect to Oracle Fusion Cloud data through custom ETL or Data Gateway, but OBIEE 12c support ended December 2025, meaning organizations running it in 2026 are on unsupported software. Oracle Analytics Cloud (OAC) with native Fusion connectors is the supported replacement, delivering real-time data access without custom ETL.
Oracle Data Gateway runs as a lightweight agent in the on-premises network, creating an encrypted tunnel between OAC in Oracle Cloud and on-premises databases. It enables OAC to query on-premises data sources alongside Oracle Fusion Cloud data within the same analytics environment without exposing on-premises databases to the internet.
No. OBIEE 12c extended support ended December 2025. As of 2026, organizations running OBIEE 12c receive no security patches, bug fixes, or Oracle support. Oracle Analytics Server (OAS) is the on-premises successor, and Oracle Analytics Cloud (OAC) is the cloud-native successor. Both are in active support.
Oracle Analytics Cloud (OAC) is cloud-hosted, fully managed, with native Fusion connectors and automatic updates. Oracle Analytics Server (OAS) is on-premises, requiring organizations to manage infrastructure and upgrades. OAC is the recommended path for Oracle Fusion Cloud users; OAS suits organizations with strict on-premises data residency requirements.
Oracle Fusion Cloud includes OTBI for self-service ad hoc reporting, BI Publisher (BIP) for pixel-perfect formatted documents, Oracle Smart View for Excel-based analysis, and Oracle Analytics Cloud (OAC) for enterprise dashboards and augmented analytics. Each suits different use cases within the Oracle Cloud environment.
A mid-sized OBIEE-to-OAC migration with one repository and 200 to 500 catalog objects typically takes 8 to 16 weeks. DataTerrain's automated migration tooling reduces catalog migration effort by 40 to 60 percent through automated RPD conversion and catalog content migration with built-in output validation.
Oracle Analytics Cloud (OAC) is the cloud-native replacement for OBIEE. Oracle Analytics Server (OAS) is the on-premises replacement. OAC provides native Oracle Fusion Cloud connectors, automatic quarterly updates, and AI-powered analytics capabilities. OAS suits organizations with data residency requirements that prevent full cloud adoption.
No. OBIEE cannot directly query Oracle Fusion Cloud transactional tables. Organizations typically use OTBI (Oracle Transactional Business Intelligence), BI Publisher, OAC native connectors, or data replication approaches to access Oracle Fusion Cloud data for reporting. Each option has different latency, maintenance, and real-time access trade-offs covered in the reporting options section above.
OAC provides cloud scalability, native Oracle Cloud connectivity, automatic quarterly updates, and AI-powered analytics that OBIEE does not offer. OBIEE 12c extended support ended December 2025, making OAC the only actively supported Oracle analytics option for organizations currently on OBIEE. For organizations on Oracle Fusion Cloud, OAC's native connectors eliminate the custom ETL layer required by OBIEE.
Oracle Analytics Cloud (OAC) replaced OBIEE as the cloud-native Oracle analytics platform. Oracle Analytics Server (OAS) replaced OBIEE as the on-premises platform. Both share the same RPD-based semantic layer as OBIEE, enabling migration of repository and catalog content from existing OBIEE environments.
OBIEE 11g mainstream support ended in December 2022. OBIEE 12c extended support ended in December 2025. As of 2026, both versions are unsupported and receive no Oracle security patches or bug fixes. Oracle Analytics Server (OAS) and Oracle Analytics Cloud (OAC) are the supported successors.
OBIEE reports migrate to OAC or OAS through a structured process: export the RPD from OBIEE, validate compatibility using Oracle's Baseline Validation Tool, upload to OAC or OAS, migrate catalog content (dashboards, analyses, prompts), validate outputs against OBIEE baselines in a parallel run, and cut over after UAT sign-off. DataTerrain's automated tooling reduces catalog migration effort by 40-60%.
Oracle Fusion Cloud includes four native reporting tools: OTBI for self-service ad hoc analysis, BI Publisher for pixel-perfect formatted documents and scheduled reports, Oracle Smart View for Excel-based financial analysis, and Oracle Analytics Cloud (OAC) for enterprise dashboards and augmented analytics.
Yes. Oracle Analytics Cloud (OAC) is Oracle's designated OBIEE replacement. OAC supports RPD migration from OBIEE and catalog content migration, and produces equivalent analytical outputs using a modern visualization engine. OAC also provides AI narratives, natural-language queries, automatic updates, and native Oracle Fusion Cloud connectors that OBIEE does not support.

Related Articles

OBIEE to OAS Migration   |   Oracle BI Applications for Legacy BI Migration   |   Oracle HCM Analytics on Oracle Analytics Cloud   |   Migrating to Oracle Fusion Cloud ERP   |   Oracle BI Analytics Performance Metrics