10 Sep 2026

OBIEE to Power BI Migration: Steps, Tools, and Best Practices

Quick Summary

OBIEE to Power BI migration is the process of moving Oracle Business Intelligence Enterprise Edition dashboards, the RPD semantic layer, BI Publisher reports, Agents, and security from OBIEE to Microsoft Power BI. Because the RPD is a proprietary, three-layer semantic model with no Power BI import path, migration is a structural rebuild: the Physical, Business Model and Mapping, and Presentation layers are redesigned as a Power BI semantic model using Power Query and DAX; Answers and Dashboards are rebuilt as Power BI reports; BI Publisher's pixel-perfect output becomes Power BI paginated reports; and OBIEE security is remapped to Microsoft Entra ID, row-level security (RLS), and object-level security (OLS).

What Is OBIEE to Power BI Migration?

OBIEE to Power BI migration is the process of moving an organization's business intelligence assets the RPD semantic layer, Answers/Analyses, Dashboards, Agents, and BI Publisher reports off Oracle Business Intelligence Enterprise Edition and onto Microsoft Power BI.

Because the RPD is a proprietary, three-layer semantic model with no Power BI import path, migration is a structural rebuild. We re-derive physical table mappings, business logic, and presentation catalogs as a Power BI semantic model, and rebuild every dashboard and report built on top of it. The scope of an OBIEE migration typically spans the semantic layer, every interactive dashboard, every pixel-perfect BI Publisher report, and the scheduled Agents that deliver them.

Can OBIEE Be Migrated Directly to Power BI?

No. You can't simply open or import QlikView and Qlik Sense applications into Power BI, and you can't import an OBIEE RPD either. The RPD's three-layer semantic model, BI Publisher's proprietary layout format, and OBIEE's session-variable-based security have no direct import path into Power BI. Migration requires rebuilding each asset using its Power BI equivalent: Power Query and DAX for the semantic model, Power BI Report Builder for paginated reports, and RLS roles for security.

The goal is not to reproduce the OBIEE file; the goal is to reproduce the required business outcomes and reporting experience on the Power BI platform, validated against the original output before cutover.

What Gets Migrated from OBIEE to Power BI?

An OBIEE to Power BI migration typically covers six layers:

RPD semantic model: Physical layer connections, Business Model and Mapping logic, and Presentation layer subject areas
Answers and Analyses: interactive reports built on RPD subject areas, rebuilt as Power BI Desktop reports
Dashboards: OBIEE dashboard pages rebuilt as Power BI report pages or dashboard tiles
BI Publisher reports: pixel-perfect, print-oriented output rebuilt in Power BI Report Builder as RDL-based paginated reports.
Agents: scheduled report delivery and threshold alerts rebuilt using Power BI subscriptions or Power Automate flows
Security: OBIEE application roles, session variables, and data filters rebuilt as Microsoft Entra ID groups, RLS roles, and OLS policies

An inventory often reveals low-usage or duplicate reports better retired than migrated. Rationalizing the catalog before migration reduces active scope and improves the quality of what gets rebuilt.

How to Migrate from OBIEE to Power BI

Migrating from OBIEE to Power BI is a rebuild, not a direct conversion. The process follows six phases:

1. Discovery and Inventory

Catalog every RPD subject area, Answers/Analysis, Dashboard, Agent, and BI Publisher report, along with usage frequency and business owners. Classify each report as an interactive dashboard or a pixel-perfect paginated report candidate, and identify low-usage content for retirement before migration begins.

2. Semantic Model Design

Design the Power BI semantic model structure, tables, relationships, and DAX measures based on the RPD's Business Model and Mapping layer. This is the core deliverable of any OBIEE migration: a well-structured Power BI semantic model with clean star-schema relationships and validated DAX measures that replaces the RPD's logical SQL and calculation logic.

3. Rebuild and Validate

Recreate dashboards as Power BI reports, implementing DAX measures and display folders for the rebuilt subject areas. Rebuild BI Publisher compliance reports in Power BI Report Builder as RDL-based paginated reports. Validate rebuilt output against the original OBIEE reports, comparing data points, row counts, totals, and calculated values before any report is approved for production.

4. Security and Distribution Rebuild

Reimplement OBIEE Data Filters and session-variable-based security as Power BI RLS roles and OLS policies. Rebuild Agent-based delivery as Power BI subscriptions or Power Automate flows. Validate security with representative user accounts, not just admin accounts.

5. Pilot Before Scaling

Run a pilot covering both an interactive dashboard and a pixel-perfect paginated report before scaling to the full RPD. The pilot validates the semantic model design, DAX measures, paginated report layout, security, and validation workflow before applying them across every subject area.

6. Cutover and Decommission

Migrate in waves by subject area or business unit. Run legacy OBIEE and Power BI in parallel during a defined validation window, then retire OBIEE infrastructure once output parity is confirmed.

OBIEE to Power BI Asset Mapping

OBIEE Asset	Power BI Equivalent	Migration Note
RPD Physical layer	Power Query connections	Physical table joins rebuilt as Power Query queries against the same or migrated sources
RPD Business Model and Mapping layer	Power BI semantic model tables and relationships	Logical fact/dimension structure rebuilt as star-schema tables and DAX measures
RPD Presentation layer	Power BI display folders	Subject area groupings rebuilt as display folders for report authors
Repository/session variable	DAX measure or Power Query parameter	Dynamic RPD calculations reimplemented as DAX measures or query parameters
Answers/Analysis (interactive)	Power BI Desktop report (.pbix)	Rebuilt on the semantic model, not a pixel-for-pixel port
Dashboard	Power BI report pages or dashboard tiles	OBIEE dashboard pages become Power BI report pages
BI Publisher report	Power BI Report Builder (RDL paginated report)	Closest match for print/compliance-oriented, pixel-perfect output
Agent (scheduled alert/delivery)	Data-driven subscription or Power Automate	Basic delivery via subscriptions; advanced per-recipient bursting via Power Automate
Data Filter/RPD session security	RLS roles, OLS policies, Entra ID groups	RPD-level security rebuilt across Microsoft's layered security model

OBIEE to Power BI Migration Tools

Migration tooling can automate parts of an OBIEE to Power BI migration, but tools do not replace architectural decisions, RPD reverse-engineering, DAX development, or validation work.

Tool or Approach	Purpose in OBIEE Migration
OBIEE/RPD analysis tools	Inventory and reverse-engineer RPD metadata, subject areas, and catalog usage
Migration and conversion utilities	Accelerate report discovery, object mapping, and conversion of repetitive patterns
Power BI Desktop	Rebuild interactive OBIEE Answers and Dashboards as Power BI reports
Power Query	Rebuild RPD Physical layer data connections and transformation logic
DAX	Rebuild RPD calculations, session variables, and business logic as semantic model measures
Power BI Report Builder	Rebuild pixel-perfect BI Publisher output as RDL-based paginated reports
Power Automate	Rebuild OBIEE Agent-based per-recipient report bursting and advanced scheduled delivery

How Does OBIEE Security Map to Power BI?

OBIEE's security model uses RPD session variables, application roles, and Data Filters to control what data each user sees. These do not map one-to-one into Power BI. The migration rebuilds OBIEE security using a combination of Microsoft Entra ID, Power BI RLS, and OLS:

Microsoft Entra ID groups: replace OBIEE application roles and WebLogic user management, providing centralized identity management integrated with Microsoft 365 and Azure
Row-level security (RLS): DAX-filtered RLS roles control which data rows each user or group can see within the Power BI semantic model, replacing OBIEE Data Filters
Object-level security (OLS): restricts access to specific tables or columns within the Power BI semantic model where the target access model requires object-level restrictions.

Security is not copied from OBIEE to Power BI; it is redesigned. Validate all RLS and OLS rules with representative user accounts, not just admin accounts, before decommissioning OBIEE.

Why Enterprises Are Moving Off OBIEE

Licensing and infrastructure costs: OBIEE licensing and WebLogic infrastructure can create high operating costs, while Power BI offers a different licensing and capacity model. The financial impact depends on deployment size, user requirements, and existing Microsoft licensing.
Native Microsoft ecosystem fit: Power BI connects natively to Excel, Teams, SharePoint, and Fabric, accelerating adoption for organizations already standardized on Microsoft 365 and Azure
Self-service analytics: business users can build their own DAX measures and reports against a governed semantic model, reducing dependency on a centralized OBIEE/RPD development team
Platform modernization: Oracle organizations evaluating modernization may consider moving from legacy OBIEE deployments toward newer analytics platforms such as Oracle Analytics Cloud or Power BI, depending on their ecosystem and roadmap
Simpler operating model: retiring OBIEE's WebLogic application server and RPD development tooling removes a significant maintenance and patching burden
Unified analytics: Power BI semantic models built from OBIEE-sourced data can sit alongside reports built on other systems, supporting broader analytics consolidation

Common OBIEE Migration Challenges

RPD complexity: years of accumulated business logic, calculated measures, and physical joins need careful reverse-engineering before they can be rebuilt as a clean Power BI semantic model
Pixel-perfect fidelity: BI Publisher's print-oriented layouts require dedicated Report Builder RDL work to preserve exact formatting for compliance-driven reports; there is no automated conversion
Security model mismatch: RPD session variables and Data Filters do not map one-to-one onto RLS and OLS roles; access rules need redesign and validation with real user accounts.
Report bursting: OBIEE's per-recipient scheduled delivery does not fully replicate through Power BI subscriptions alone; advanced per-recipient distribution requires Power Automate
DAX and Power Query skills: the RPD uses logical SQL and Oracle-specific calculation syntax; Power BI requires DAX for measures and Power Query for data transformation, which represents a meaningful skills transition for OBIEE development teams

OBIEE Migration Best Practices

Start with a full inventory: catalog every RPD subject area, Answers, Dashboard, Agent, and BI Publisher report before any migration work begins. Retire low-usage content rather than migrating it.
Design a shared semantic model: build one governed Power BI semantic model that replaces the RPD's Business Model and Mapping layer, rather than rebuilding logic separately for every dashboard.
Pilot both report types first: run a pilot covering one interactive dashboard and one pixel-perfect paginated report before scaling to the full RPD
Establish naming conventions early: DAX measures and Power Query steps need clear naming conventions from the start, since every converted RPD calculation will be re-expressed through them.
Validate security with real users: test RLS and OLS roles with representative user accounts, not admin accounts, before decommissioning OBIEE.
Run in parallel before cutover: run legacy OBIEE and Power BI reports side by side during a defined validation window, comparing data points, row counts, and totals before switching over.

How Long Does OBIEE to Power BI Migration Take?

Migration timeline depends on the number of RPD subject areas, total report and dashboard count, BI Publisher report complexity, security requirements, and validation scope.

Migration Scope	Typical Effort
Small or focused single subject area	Weeks to a few months
Mid-size OBIEE environment	Several months
Large enterprise RPD with complex security and BI Publisher usage	Multiple phases across quarters

A pilot covering one interactive report and one paginated report is the most reliable way to calibrate effort before scoping the full migration. Cost scales with the number of subject areas, reports, and RPD complexity, and is typically assessed against the cost of retiring OBIEE's WebLogic infrastructure and licensing against any Power BI capacity the enterprise already owns.

Illustrative Example: OBIEE to Power BI Migration

Illustrative Example. The following is a representative profile of an OBIEE-to-Power BI migration engagement, not an account of a specific named client. It reflects patterns seen across enterprise BI modernization projects.

The challenge: A utilities company ran its regulatory and operations reporting on an aging OBIEE deployment, with a small team maintaining RPD logic and BI Publisher reports critical for compliance filings. Licensing and WebLogic infrastructure costs were significant, and business users lacked self-service analytics.

The approach: DataTerrain reverse-engineered the RPD's business model, rebuilt it as a governed Power BI semantic model with DAX measures and star-schema relationships, recreated BI Publisher compliance reports in Power BI Report Builder as paginated RDL reports, remapped OBIEE security to Power BI RLS and OLS roles, and validated output against OBIEE before cutover. Legacy OBIEE and Power BI ran in parallel during the validation window.

Area	Before (OBIEE)	After (Power BI)
New report turnaround	IT-dependent, days	Self-service, hours
Pixel-perfect compliance reports	OBIEE BI Publisher	Power BI Report Builder (RDL)
Semantic layer	12 separate RPD subject areas	One governed Power BI semantic model

OBIEE to Power BI Migration with DataTerrain

17+ Years Experience | 400+ US Clients | RPD & BI Publisher Migration | Free Assessment

DataTerrain delivers end-to-end OBIEE to Power BI migration, covering RPD analysis, semantic model redesign, dashboard rebuilding, BI Publisher conversion, security remapping, and validation. Our Automated BI reports conversion service accelerates OBIEE report discovery and repetitive migration tasks while DataTerrain specialists handle RPD complexity, DAX conversion, and paginated report fidelity.

Get your free OBIEE migration assessment.

Key Takeaways

OBIEE to Power BI is a rebuild, not a direct conversion.
Answers and Dashboards become Power BI reports; BI Publisher becomes paginated reports.
The RPD semantic model is redesigned using Power Query and DAX.
Security is rebuilt with Entra ID, RLS, and OLS.
Inventory and validate first to retire unnecessary reports and ensure output parity.
Parallel validation helps confirm readiness before OBIEE cutover.

Conclusion

OBIEE to Power BI migration is a multi-layer rebuild: RPD semantic model redesign, interactive dashboard reconstruction, BI Publisher-to-paginated-report conversion, security remapping, and side-by-side validation. Organizations that approach the migration with a complete RPD inventory, a single governed semantic model design, and parallel-run validation before cutover consistently produce Power BI environments that accurately replace OBIEE for both everyday analytics and compliance reporting. Contact DataTerrain for a free assessment of your OBIEE environment.

Frequently Asked Questions

Is OBIEE to Power BI migration a direct conversion?

No. The RPD's three-layer semantic model and BI Publisher layouts have no direct import path into Power BI. Migration requires rebuilding the RPD as a Power BI semantic model, rebuilding Answers and Dashboards as Power BI reports, converting BI Publisher reports to paginated reports, and remapping OBIEE security to Power BI RLS and OLS. Each asset is rebuilt and validated, not imported.

How does the OBIEE RPD map to Power BI?

The RPD Physical layer maps to Power Query data source connections. The Business Model and Mapping layer maps to Power BI semantic model tables, relationships, and DAX measures. The Presentation layer maps to Power BI display folders. The three-layer RPD structure is redesigned as a single governed Power BI semantic model rather than migrated as a file.

Can Power BI replicate OBIEE's pixel-perfect BI Publisher reports?

Yes, largely. Power BI Report Builder generates RDL-based paginated reports designed for print and compliance output. BI Publisher reports are rebuilt in Report Builder rather than converted directly, and output is validated against the original BI Publisher layout before cutover.

How is OBIEE security migrated to Power BI?

OBIEE application roles, session variables, and data filters are rebuilt using Microsoft Entra ID groups for identity management, Power BI row-level security (RLS) to control data row access, and object-level security (OLS) to restrict column or table access. We validate security with representative user accounts before cutover.

How long does an OBIEE to Power BI migration take?

A focused single-subject-area migration may take weeks to a few months. A mid-size OBIEE environment typically takes several months. A large enterprise RPD with complex security and BI Publisher usage may require multiple phases across quarters. A pilot covering one interactive report and one paginated report is the most reliable way to calibrate effort before scoping the full migration.