Pull-quote: “The RPD is not a black box. It is a graph of joins, hierarchies, and security predicates. Treat it that way and migration becomes tractable.”
Why this matters
Oracle BI EE is one of the most widely deployed enterprise BI platforms. It also has accumulated technical debt — schema drift, layered RPDs, undocumented session variables, and report logic split between the BMM and the report itself. Most “migration” projects start by trying to lift-and-shift everything, get blocked, and stall.
The right approach is methodological. The RPD is treatable as three layers, each of which has a clean Databricks SQL equivalent.
The three-layer translation
OBIEE Databricks
───── ──────────
Physical layer ─────► Delta Lake tables in Unity Catalog
+ Lakehouse Federation for live sources
BMM (logical) ─────► Databricks SQL semantic model
(Lakehouse views with row/column security)
Presentation ─────► Power BI / Tableau on Databricks SQL
(dimensions, measures, time intelligence)Migration sequence
| Phase | Length (typical) | Output |
|---|---|---|
| 1. Discovery | 2–4 wks | Catalog of subject areas, RPDs, repositories, presentation catalogs · usage telemetry · report criticality matrix |
| 2. Source mapping | 2–4 wks | Mapping of physical layer to landing tables in Bronze/Silver Delta · federated sources documented |
| 3. Semantic model design | 4–8 wks | Logical-to-Databricks-SQL semantic model with row/column security |
| 4. ETL conversion | parallel with 3 | Native ETL → Lakeflow / DLT / Spark with DLT expectations |
| 5. Report rebuild | 4–10 wks | Top reports rebuilt in Power BI Direct Lake or Tableau |
| 6. Cutover & decom. | 2–6 wks | Parallel run · UAT · sign-off · legacy decommissioning |
| 7. Hyper-care | 30/60/90 days | Stabilization with SLA-backed support |
Security translation
| OBIEE security primitive | Databricks equivalent |
|---|---|
| Application Roles | Unity Catalog groups (Entra/IDP-mapped) |
| Data filters on logical tables | Dynamic views with current_user() and is_member() |
| Column-level filters | mask() functions in dynamic views |
| Session variables | Catalog-scoped configuration tables |
| Init blocks | Replaced by IDP/Entra group claims |
Common pitfalls
- Trying to lift-and-shift the BMM. Some logic in the BMM is workaround for OBIEE limitations. Rebuild as Lakehouse views; don’t translate one-for-one.
- Skipping usage telemetry. Half the reports in a typical OBIEE deployment are unused. Don’t migrate them.
- Translating session variables literally. Most session variables become dynamic-view predicates or IDP claims.
- Building the semantic model in Power BI instead of Databricks SQL. Power BI imports work in the short term and create future modernization debt. Direct Lake is the target.
Closing
The OBIEE → Databricks migration pattern is reproducible when you treat the RPD as a graph of joins, hierarchies, and security predicates rather than as a black box. The result is a cleaner semantic model on a platform that supports SQL, ML, streaming, and agentic AI — instead of a single-purpose BI server.
