Trusted Digital Transformation Partner
In short: Migrating from OBIEE to Oracle Analytics Cloud is not a lift-and-shift — the RPD semantic model, dashboards and BI Publisher reports all need to be assessed individually, because some convert cleanly with Oracle's migration utilities and some do not. Knowing which is which before committing to a timeline is what separates a predictable project from one that discovers the hard parts during UAT.
The RPD (repository) — the semantic model defining subject areas, table joins, calculations and security — is the core of an OBIEE estate, and Oracle provides utilities to migrate it into OAC's semantic model format. Straightforward joins, calculations and hierarchies generally convert well. What does not convert cleanly: custom Java plugins and extensions, which have no equivalent in OAC's architecture and need to be re-implemented or replaced with a native OAC feature if one exists; heavily formatted BI Publisher templates with complex conditional layout logic, which often need manual rework rather than automated conversion; and any RPD elements built around on-premises-specific integrations (direct database links to systems that will not be reachable from a cloud OAC instance without additional network configuration).
Most OBIEE estates that have been in production for years accumulate dashboards nobody actively uses — built for a project that ended, a stakeholder who left, or a question that was only asked once. Migrating everything, including that accumulated cruft, both wastes migration effort and carries forward technical debt into the new platform. A usage audit — which dashboards and analyses have actually been opened in, say, the last six to twelve months — before migration planning starts is consistently where the most time gets saved, because it turns "migrate the whole RPD" into "migrate the 30% that people actually use, and rebuild the rest only if someone asks for it."
OBIEE's security model (application roles, data-level security embedded in the RPD) has an OAC equivalent, but it is not always a one-to-one mapping — OAC's cloud identity integration (with Oracle Identity Cloud Service or another IdP) is a different mechanism from OBIEE's typical on-premises LDAP/database authentication, and data-level security rules defined deep in the RPD need to be verified, not assumed, to carry across correctly. Getting this wrong is a silent risk — a security-filtering rule that quietly stops applying is worse than one that visibly breaks, because nobody notices until sensitive data appears somewhere it shouldn't.
The migrations that go smoothly generally run in this order: an RPD and content audit (what exists, what's actually used, what customisations exist) before any conversion work starts; a technical proof-of-concept migrating a representative slice of the RPD and a handful of real dashboards to validate the conversion utilities against this specific estate's patterns, not a generic assumption; then a phased migration of the confirmed-in-use content, with the unused dashboards left behind deliberately rather than carried forward by default; and a security-model verification pass before go-live, testing that data-level filters produce the same results in OAC that they did in OBIEE for a representative set of users.
A focused migration for a mid-sized estate — a few hundred dashboards, a moderately complex RPD, standard security requirements — is commonly measured in a small number of months once the audit is complete, not weeks. Estates with heavy custom Java plugin usage or complex BI Publisher formatting take longer, because that is genuinely rebuild work, not conversion. The audit phase is what turns a rough guess into a real timeline.
Most Oracle performance problems do not start inside Oracle. We tune the whole ecosystem — SGA and PGA sizing, kernel parameters, storage and SQL.
See our Oracle EBS practiceTalk to our certified experts — free consultation, no commitment.
Powered by AI · Typically replies instantly