Explain Migrating from On-Premise OBIEE to OAC in Oracle BI

43 / 55

OACadvanced

Migrating from On-Premise OBIEE to OAC

Explain the technical and organizational considerations involved in migrating an existing OBIEE/OAS deployment to Oracle Analytics Cloud.

Migration questions are common in senior interviews because so many organizations are mid-journey from on-premise OBIEE/OAS to OAC, and a candidate who's actually navigated this transition brings genuinely differentiated experience versus one who's only worked greenfield in either environment.

It's like relocating a well-organized physical office to a new building: most of the furniture and file cabinets (RPD, catalog) move over largely intact, but you still need new keys and badges for the new building's security system (identity federation), and anything hardwired into the old building's specific electrical setup (custom extensions) needs an electrician's review before it works the same way in the new space.

Key Concepts

The technically central migration path is the RPD and catalog lift: Oracle provides tooling (the Migration Tool Kit / Baseline Validation Tool and BAR-file-based upload) to package an existing on-premise RPD and web catalog and upload them into an OAC instance, largely preserving subject areas, security, and existing dashboards — meaning a well-modeled on-premise RPD is often *more* portable than people expect, since the underlying BI Server/RPD architecture is fundamentally shared between OAS and OAC. However, several things typically need rework post-migration: connection pools must be re-pointed to migrate-compatible data sources (direct on-premise DB connections require setting up the Remote Data Gateway discussed earlier, or migrating the source itself to a cloud database), security provider configuration needs to shift from WebLogic's embedded LDAP/on-premise AD to IDCS/OCI IAM (often the most organizationally complex part, requiring identity federation planning), and any custom Java extensions, Action Framework code, or heavily customized skins/branding built for on-premise WebLogic may need adaptation or aren't supported identically in the managed cloud environment.

RPD and catalog liftMigration Tool Kit / Baseline Validation Toolconnection poolssecurity provider configurationcustom Java extensions, Action Framework code, or heavily customized skins/branding

A Baseline Validation Tool (BVT) approach is the recommended safety net: capturing a snapshot of query results and performance from the on-premise system before migration, then re-running the same validation queries against the migrated OAC instance to confirm functional and performance parity before cutting users over — this is the kind of concrete, process-oriented detail that signals real migration experience rather than theoretical familiarity.

Baseline Validation Tool (BVT)

Organizationally, migrations are also a natural inflection point to decide what to modernize versus lift-and-shift as-is: some teams use the migration as an opportunity to also introduce DV self-service datasets alongside the migrated RPD content, rather than just replicating the old environment exactly inside a new cloud shell.

decide what to modernize versus lift-and-shift as-is