OBIEE to Oracle Analytics Cloud Migration Guide 2026

Oracle Analytics Cloud is Oracle's cloud-native successor to OBIEE. If you're running Oracle Fusion HCM and still on OBIEE — on-premises 11g, 12c, or the legacy cloud version — Oracle has been pushing OAC migration for three years. This guide covers every breaking change, the Logical SQL syntax differences that silently corrupt report output, and a realistic four-week migration timeline for HCM-heavy environments.

Why OAC Migration Is Happening Now

Oracle has made no secret that OBIEE on-premises is in maintenance mode. New features — AI-augmented analytics, self-service workbooks, augmented data prep — are OAC-only. More practically: Oracle's standard support for OBIEE 12c ended in 2025, and Oracle BI Cloud Service (BICS) was discontinued. If you're on HCM Cloud and still running a separate OBIEE instance, you're also running infrastructure Oracle is actively sunsetting.

The more immediate pressure is the Oracle Analytics Cloud migration incentive program: Oracle has been offering discounted OAC licensing for OBIEE customers through 2026, but those programs require active migration projects. Organizations that delay are finding fewer incentive windows and longer internal approval cycles.

The result: migration projects that were "on the roadmap for next year" in 2024 are now in active planning in 2026.

What's Actually Different: OAC vs OBIEE

Most documentation frames OAC as "OBIEE in the cloud." That's true for the subject area and Logical SQL layer — the data model is the same. But there are enough surface-level differences to cause real breakage in existing reports.

Breaking Change #1: EVALUATE() Is Blocked in OAC SaaS

This is the change that causes the most migration failures. OBIEE's EVALUATE() function lets you pass database-native SQL directly to the physical query layer, bypassing OBIEE's Logical SQL processing. It was commonly used in Oracle HCM OBIEE environments for:

• Regular expression operations (REGEXP_SUBSTR, REGEXP_REPLACE)
• Oracle-specific date functions not exposed in Logical SQL (ADD_MONTHS, LAST_DAY)
• String manipulation beyond what OBIEE's built-in functions covered
• Custom aggregation logic using EVALUATE_AGGR()

In OAC SaaS, Oracle's security model restricts arbitrary database code execution. Many EVALUATE() calls return an error or simply return NULL without warning — the report appears to run but the column is blank.

How to Find All EVALUATE() Usage in Your Catalog

Before migration, run this SQL against your Oracle BI Presentation Catalog metadata (or use Oracle's catalog migration utility to export XML and grep it):

-- If you've exported catalog to XML files, search with:
-- grep -ri "EVALUATE(" /path/to/catalog/export/ --include="*.xml" -l
-- Or query the UsageTracking data if enabled:

SELECT
  LOGICAL_SQL_QUERY,
  PRESENTATION_NAME,
  USER_NAME,
  START_TS
FROM S_NQ_ACCT
WHERE LOGICAL_SQL_QUERY LIKE '%EVALUATE(%'
   OR LOGICAL_SQL_QUERY LIKE '%EVALUATE_AGGR(%'
ORDER BY START_TS DESC;

Rewriting EVALUATE() for OAC

Most EVALUATE() calls can be rewritten using OAC's supported Logical SQL functions. The key OAC-supported replacements:

-- BEFORE: EVALUATE() for REGEXP_SUBSTR (fails in OAC SaaS)
EVALUATE('REGEXP_SUBSTR(%1, %2, 1, 1)',
  "Worker"."Email Address",
  '[^@]+')

-- AFTER: Pure Logical SQL (OAC supported)
SUBSTRING("Worker"."Email Address"
  FROM 1
  FOR POSITION('@' IN "Worker"."Email Address") - 1)

-- BEFORE: EVALUATE() for ADD_MONTHS
EVALUATE('ADD_MONTHS(%1, %2)',
  "Worker"."Date of Hire", 6)

-- AFTER: TIMESTAMPADD in Logical SQL
TIMESTAMPADD(SQL_TSI_MONTH, 6, "Worker"."Date of Hire")

-- BEFORE: EVALUATE_AGGR() for custom aggregation
EVALUATE_AGGR('MEDIAN(%1)', "Compensation"."Annual Salary")

-- AFTER: Use PERCENTILE_CONT in OAC (or MEDIAN if available)
PERCENTILE_CONT(0.5) WITHIN GROUP
  (ORDER BY "Compensation"."Annual Salary")

Breaking Change #2: Presentation Variable Behavior in Workbooks

OBIEE Classic Dashboards use @{varName}{default} syntax for presentation variables, set via dashboard prompts. OAC Workbooks use a different prompt mechanism. If you're migrating to OAC Workbooks (not Classic Dashboards), the variable binding behavior changes:

• Classic Dashboards in OAC: presentation variable syntax is unchanged — port directly
• OAC Workbooks: prompts work through Data Actions and Filters — not presentation variables in the traditional sense
• Mixed scenarios: if you're embedding Workbook content inside Classic Dashboards, variable scoping gets complex

The safest migration path for HCM-heavy environments: migrate report SQL first to Classic Dashboards in OAC (1:1 compatibility), then progressively rebuild high-value reports as Workbooks for the new UX. Don't try to migrate to Workbooks in one pass.

Breaking Change #3: BIP Data Model Connections

If your OBIEE environment feeds BI Publisher (BIP) reports via OBIEE subject area data models, the connection configuration changes in OAC. Specifically:

• The OBIEE data source type in BIP becomes the OAC data source type
• Connection pool references change from the OBIEE RPD to the OAC Semantic Model
• BIP SOAP/REST API endpoints change (OBIEE uses /xmlpserver/services, OAC uses /xmlpserver/services but on a different host)
• Any BIP reports calling OBIEE Logical SQL directly via the "Oracle BI EE" data source type need the data source updated to point to OAC

What Doesn't Break: OTBI Reports

If your Oracle HCM reporting stack uses primarily OTBI — Oracle Transactional Business Intelligence, the subject-area-based reporting tool built into HCM Cloud — you have almost no migration work to do. OTBI uses the same underlying Oracle Analytics Server that powers OAC. The subject areas are identical. The Logical SQL syntax is the same.

OTBI reports that use standard subject areas (Workforce Management - Worker Assignment Real Time, Payroll - Payroll Run Results Real Time, etc.) port to OAC without modification. The subject area join logic, column names, and filter syntax are unchanged.

The only OTBI edge case to test: any OTBI report that uses FILTER() function with a cross-subject-area measure. These are rare in standard HCM reporting, but worth auditing.

Pre-Migration Data Quality: The Step Most Teams Skip

Data quality issues that exist in your OBIEE environment don't disappear in OAC — they're often exposed more clearly. Assignment orphans, effective date gaps, and missing TL rows that OBIEE "tolerated" (by returning incomplete results silently) may cause OAC reports to error or return different row counts than your team expects.

Before starting any SQL migration work, run data validation queries against your Oracle HCM instance. At minimum, check:

• Assignment orphans (PER_ALL_ASSIGNMENTS_M rows with no parent PER_ALL_PEOPLE_F)
• Effective date gaps in assignment history
• Active employees with no payroll assignment
• Missing _TL rows (blank display names in reports)

Finding these before migration prevents a common failure pattern: migrated reports return different row counts than OBIEE, investigation takes two weeks, and the difference turns out to be pre-existing data quality issues rather than migration bugs.

Four-Week Migration Checklist

Week 1: Inventory and Risk Classification

• □Export OBIEE catalog to XML (via Catalog Manager or Oracle's migration utility)
• □Count total reports, dashboards, and prompts in scope
• □Run Usage Tracking query — identify reports not accessed in 6+ months (candidates for retirement)
• □Grep catalog for EVALUATE() and EVALUATE_AGGR() — classify each as rewritable vs. complex
• □Identify all BIP reports with Oracle BI EE data source type
• □Document all presentation variables and dashboard prompt dependencies
• □Run HCM data quality checks against live environment
• □Classify each report: HIGH risk (EVALUATE), MEDIUM risk (complex prompts), LOW risk (standard SQL)

Week 2: Migrate HIGH Risk Reports

• □Rewrite all EVALUATE() calls to OAC-compatible Logical SQL (see examples above)
• □Test each rewrite against OBIEE output for row count and value match
• □Reconfigure BIP data model connections from OBIEE to OAC data source
• □Migrate HIGH risk reports to OAC Classic Dashboards first (not Workbooks)
• □Document any intentional output differences (e.g., NULL handling changes)

Week 3: Migrate Remaining Reports + UAT

• □Migrate MEDIUM and LOW risk reports (standard SQL — mostly copy-paste)
• □Side-by-side output comparison: OBIEE vs OAC for every migrated report
• □Run UAT with report owners — 2 days minimum per major report cluster
• □Test all dashboard prompts and presentation variable bindings in OAC
• □Load test large reports against OAC row limits
• □Test direct data export reports (Excel/CSV download behavior may differ)
• □Fix and retest any UAT failures

Week 4: Cutover and Post-Go-Live

• □Obtain UAT sign-off from business stakeholders
• □Update report bookmarks, links, and scheduled email delivery configurations
• □Switch OBIEE usage tracking off (or set to read-only) — not OAC yet
• □Cutover: redirect users to OAC; OBIEE instance stays up in read-only for 30 days
• □Monitor OAC logs for errors in first week
• □Decommission OBIEE instance after 30-day parallel run

RPD to Semantic Model: The Complex Case

If your OBIEE environment has a customized RPD — custom subject areas, custom joins, extended HCM metadata — the migration is more involved. Oracle provides an RPD migration tool that converts the binary RPD to OAC's XML-based Semantic Model, but custom extensions require manual validation.

Standard Oracle HCM-delivered RPD content (the HCM Analytics subject areas) migrates cleanly via the tool. Custom joins, custom dimensions, or extended fact tables added by your implementation team need manual review and testing in OAC Modeler.

For environments with heavy RPD customization, plan an additional 1–2 weeks for Semantic Model validation and custom content rebuild.

OAC-Specific Optimizations Worth Doing During Migration

Migration is the right time to address performance and design issues that accumulated over years of OBIEE development. A few worth doing while you're touching each report:

• Retire unused reports: any report with zero Usage Tracking hits in 12 months is a candidate — confirm with owners before deleting
• Consolidate duplicate reports: OBIEE environments often have 3–5 versions of the same headcount report built by different teams at different times
• Add EFFECTIVE_LATEST_CHANGE filters: if your HCM reports are returning duplicate rows from PER_ALL_ASSIGNMENTS_M, add EFFECTIVE_LATEST_CHANGE = 'Y' — this fixes a chronic HCM reporting issue
• Convert OBIEE Dashboards to OAC Workbooks: for your 10–15 most used reports — Workbooks have better mobile and self-service UX

Common Migration Mistakes

1. Migrating EVALUATE() without testing each rewrite

The Logical SQL equivalents for EVALUATE() work for 80% of cases. The other 20% have subtle differences in NULL handling, type coercion, or aggregation behavior. Every EVALUATE() rewrite needs a side-by-side output comparison before sign-off.

2. Skipping data quality validation before migration

Pre-existing data issues in Core HR (orphaned assignments, date gaps, missing TL rows) surface as "new" report discrepancies after migration. Your team spends days debugging what turns out to be a data issue that existed before you touched anything. Run the checks first.

3. Migrating to OAC Workbooks instead of Classic Dashboards first

Workbooks are the future of OAC, but they have a different UX paradigm. Migrating to Classic Dashboards first gives you 1:1 functional parity and a stable baseline. Then progressively upgrade to Workbooks for your highest-traffic reports.

4. Decommissioning OBIEE before the 30-day parallel run completes

Users will find discrepancies. Some are bugs. Some are pre-existing data issues. Some are intentional behavior differences. You need OBIEE running to diagnose which is which. Keep it up for 30 days minimum post-cutover.

5. Not auditing report usage before migration

The average OBIEE catalog has 30–50% of reports that haven't been accessed in over a year. Migrating them consumes budget and introduces risk for zero benefit. Pull Usage Tracking data and get owner confirmation before migrating anything with low usage.

Summary: What to Prioritize

If you're starting a migration project today, the order of work matters:

1. Run data quality checks first — before any SQL migration. 30 parameterized queries, 24 hours, reveals every pre-existing issue that will look like a migration bug
2. Audit EVALUATE() usage — this is your highest-risk SQL. Identify and plan rewrites before writing a line of code
3. Classify and retire — pull Usage Tracking, retire the dead weight, reduce the migration scope
4. Migrate to Classic Dashboards first — establish functional parity, then upgrade to Workbooks selectively
5. Keep OBIEE running in parallel — 30 days minimum, then decommission