• 26 Aug 2026

Oracle BI to Power BI Migration: Complete Guide for OBIEE, OAS and OAC

Quick Summary

Oracle BI to Power BI migration rebuilds Oracle BI assets - OBIEE RPDs, dashboards, BI Publisher reports, calculations, and security rules - as native Power BI components. The Oracle RPD is redesigned as a Power BI semantic model using Power Query and DAX; OBIEE dashboards become interactive Power BI Desktop reports; BI Publisher documents become Power BI paginated reports. Security roles and session variables are rebuilt as Entra ID groups and Row-Level Security. Migration is a structured redesign process, not a direct file import.

Oracle BI to Power BI migration is the process of moving Oracle Business Intelligence assets, including OBIEE repositories (RPDs), dashboards, analyses, BI Publisher reports, calculations, and security rules, to Microsoft Power BI. Because Oracle BI and Power BI use different semantic architectures, migration involves assessment, semantic model redesign, report rebuilding, security remapping, validation, and phased deployment rather than a direct file conversion. This guide covers the full migration: from Oracle RPD migration through DAX conversion, BI Publisher to paginated reports, and production deployment.

Which Oracle BI Platforms Can Be Migrated to Power BI?

All major Oracle BI platforms share the RPD-based semantic architecture, making the core migration approach consistent across each:

Why Enterprises Are Migrating from Oracle BI to Power BI

• Oracle BI licensing cost savings: Oracle BI licensing, whether OBIEE on-premises or OAC consumption-based pricing, carries a heavier cost profile than Power BI, especially for organizations with existing Microsoft 365 or Azure agreements that make Power BI licensing largely incremental.
• Microsoft ecosystem fit: enterprises standardizing on Azure, Fabric, and Microsoft 365 gain a unified analytics stack by retiring Oracle BI in favor of Power BI rather than maintaining a separate Oracle BI environment alongside Microsoft infrastructure.
• Self-service analytics: Power BI enables business analysts to build their own measures and reports against a governed semantic model without depending on IT-authored Oracle BI analyses, reducing the report backlog common in OBIEE environments.
• Modern data architecture: Power BI connects natively with Azure, OneLake, Microsoft Fabric, Lakehouse, and Data Warehouse environments, supporting a unified data estate rather than a separate Oracle BI silo.
• AI-assisted analytics: Power BI provides AI-assisted analytics capabilities through Microsoft Copilot and related Microsoft ecosystem features, which can be a factor for organizations standardizing on Microsoft's analytics platform.
• Talent availability: organizations may find it easier to recruit Power BI developers and architects than specialists with deep OBIEE and RPD experience, which can affect long-term platform sustainability.

Oracle BI vs Power BI: Architecture Comparison

The biggest architectural difference between Oracle BI and Power BI is how they store and access business metadata. Oracle BI centralizes business metadata through the RPD's multi-layer architecture, while Power BI uses a tabular semantic model based on relationships, tables, columns, and DAX measures.

Oracle BI data flow: Data Sources → Physical Layer → Business Model and Mapping Layer → Presentation Layer → OBIEE Dashboards

Power BI data flow: Data Sources → Power Query/Dataflows → Semantic Model (tables, relationships, measures) → Reports → Power BI Service

Oracle RPD Migration to Power BI Semantic Model

Oracle RPD migration is the highest-risk and most technically demanding component of any Oracle BI to Power BI project. An Oracle RPD cannot be imported into Power BI. Migration requires interpreting the business logic across the RPD's three layers and redesigning it as a Power BI semantic model.

The semantic model redesign is the prerequisite for everything else. Reports built against a poorly designed semantic model produce incorrect KPIs regardless of how accurately the visuals are rebuilt. Designing the Power BI semantic model before rebuilding individual reports is the most important sequencing decision in an Oracle BI to Power BI migration.

What Can and Cannot Be Directly Migrated?

What can often be reused or carried forward: business KPI definitions and requirements, source data connections (with reconnection work), existing SQL logic (with adaptation), security role definitions, hierarchy and dimension documentation, and subject area structure as a blueprint for the semantic model.

What requires redesign and rebuilding: RPD metadata and logical joins; OBIEE calculations and logical columns; Oracle SQL functions and initialization blocks; dashboard layouts and action links; prompt and filter behavior; OBIEE application role security; BI Publisher report layouts; and agent scheduling and delivery workflows.

What requires special handling: BI Publisher bursting and per-recipient delivery; Essbase/OLAP cube integrations; complex session variable patterns; custom OBIEE plugins and extensions; and pixel-perfect compliance document layouts.

Step-by-Step Oracle BI to Power BI Migration Process

• Phase 1: Discovery and assessment. Inventory every RPD subject area, OBIEE dashboard, analysis, BI Publisher report, scheduled agent, user, and application role. Use usage analytics to separate actively used content from legacy clutter before any rebuild work begins.
• Phase 2: Rationalization. Classify each asset as migrate, retire, consolidate, or redesign. Not every Oracle BI asset should be rebuilt in Power BI: migration is the right time to eliminate duplicate, unused, and low-value reports rather than recreate Oracle BI's reporting sprawl in a new platform.
• Phase 3: Power BI semantic model design. Design the star schema, define tables and relationships, establish DAX measure standards, map security, and set naming conventions before rebuilding any individual report. This is the foundational phase, and where expert architectural judgment matters most.
• Phase 4: Report and dashboard migration. Rebuild OBIEE analyses and dashboards as Power BI Desktop reports; rebuild Oracle BI Publisher reports as Power BI paginated reports. Recreate prompts and filters as Power BI slicers and filter interactions; rebuild action links as drill-through pages and navigation buttons.
• Phase 5: Security migration. Map OBIEE application roles to Microsoft Entra ID security groups and Power BI workspace permissions; rebuild data-level security filters as Power BI RLS roles using DAX expressions. Validate each role with representative user accounts before cutover.
• Phase 6: Validation, deployment, and optimization. Run parallel testing between Oracle BI and Power BI outputs. Compare row counts, KPI values, aggregations, filters, drill-throughs, and security. Deploy through Power BI deployment pipelines, configure refresh schedules and gateways, establish workspace governance, and train users before retiring Oracle BI.

Migration Validation Framework

A successful migration validates business outcomes: confirmed KPI accuracy and security parity, not simply that reports visually resemble their Oracle BI versions.

Security Migration: OBIEE Application Roles to Power BI RLS

OBIEE security is rebuilt in Power BI across three layers: workspace permissions controlling who can view or edit content, Microsoft Entra ID security groups replacing OBIEE application roles, and Row-Level Security (RLS) roles defined in the semantic model replacing data-level filters and session variables.

Oracle BI to Power BI Migration: Manual, Automated, or Hybrid?

For large Oracle BI estates, a hybrid approach is typically the most effective: automation handles discovery, RPD structure extraction, asset inventory, and repetitive conversion work, while BI architects redesign complex semantic models, Oracle-specific SQL logic, security patterns, and critical reports. Automation can accelerate asset discovery, metadata extraction, and mapping documentation. Complex semantic logic, DAX calculations, security configuration, and output validation still require expert review regardless of the tooling used.

Key Oracle BI to Power BI Migration Challenges

• RPD complexity: years of layered business logic across physical, business, and presentation layers rarely map cleanly to a single Power BI semantic model. Subject areas built up over a decade may contain overlapping logic, deprecated objects, and undocumented calculations.
• Oracle-specific SQL: initialization blocks, session variables, and Oracle SQL functions need careful analysis to determine whether they move to Power Query, DAX, or the source data layer.
• Semantic model redesign: recreating hierarchies, aggregation rules, and calculated logical columns as DAX requires deep RPD knowledge and Power BI DAX expertise.
• Security remapping: OBIEE application roles and data filters must be rebuilt as Power BI RLS roles without opening access gaps. Silent security failures, where users see data they should not, are the highest-stakes validation requirement.
• BI Publisher to paginated reports: Oracle BI Publisher layouts with complex banding, subreports, and pixel-precise formatting require dedicated effort in Power BI Report Builder rather than a direct template import.
• Action links and navigation: OBIEE action links that provide guided navigation between analyses must be rebuilt as Power BI drill-through pages, buttons, and bookmarks, with dedicated testing for each navigation path.

Oracle BI to Power BI Migration Checklist

Assessment

• Inventory RPD subject areas, dashboards, analyses, and BI Publisher reports
• Document data sources, Oracle SQL, and initialization blocks
• Identify report owners, usage data, and application roles
• Classify assets: migrate, retire, consolidate, or redesign

Design and Migration

• Design Power BI semantic model before rebuilding any report
• Rebuild RPD logical columns and calculations as DAX measures
• Rebuild OBIEE dashboards as Power BI Desktop reports
• Rebuild BI Publisher reports as Power BI paginated reports
• Map OBIEE application roles to Entra ID groups and RLS roles
• Configure on-premises data gateway where required

Validation and Cutover

• Validate row counts, KPIs, aggregations, and filter behavior against Oracle BI
• Test security with real user accounts per application role
• Run Oracle BI and Power BI in parallel until each wave is signed off
• Obtain business sign-off before decommissioning Oracle BI licenses

Key Takeaways

• Oracle RPD cannot be directly imported into Power BI. The three-layer metadata architecture must be interpreted and redesigned as a Power BI semantic model.
• Build the semantic model before rebuilding reports. The correctness of every Power BI KPI depends on the governing semantic model: building reports first means rebuilding them again after the model is redesigned.
• Oracle BI Publisher maps to Power BI paginated reports. Interactive OBIEE dashboards migrate to Power BI Desktop; print-ready BI Publisher documents migrate to Power BI Report Builder.
• Rationalize before migrating. Retire duplicate, obsolete, and low-usage Oracle BI assets before any rebuild begins.
• Security must be rebuilt, not assumed. OBIEE application roles and session variables require individual mapping and validation with real user accounts in Power BI.
• Hybrid migration suits large Oracle BI estates. Automation accelerates discovery and structural analysis; expert architects handle semantic model design, DAX, and security.

Final Thoughts on Oracle BI to Power BI Migration

Oracle BI to Power BI migration succeeds when the Oracle RPD semantic layer is treated as an engineering project requiring deliberate redesign, not a file import, and when the Power BI semantic model is built and validated before rebuilding individual reports. Organizations that invest in rationalization before building, design the star schema and DAX measures first, validate KPIs against Oracle BI output before cutover, and plan security from the architecture phase consistently achieve better outcomes than those that start with report-level conversion without an agreed semantic foundation.

Contact DataTerrain to discuss your Oracle BI environment and build a migration plan around your actual RPD estate.

Related Articles

• Power BI Migration Services: The Complete Enterprise Guide
• BI Modernization Checklist: A Step-by-Step Guide for Enterprises
• IBM Cognos to Power BI Migration: A Complete Enterprise Guide

Frequently Asked Questions