Leaving Oracle BI Enterprise Edition
We read the repository before we draw a chart: the business model layer becomes a star-schema semantic model, logical hierarchies and level-based measures become DAX, session variables become row-level security, and every rebuilt number is reconciled against its Answers original.
Representative dashboard — sample data
Where the work really is
An Oracle BI estate is rarely retired because people dislike Answers. It is retired because the governed layer underneath it has become a specialism: one repository file, one person who still opens the Administration Tool confidently, initialization blocks nobody wants to touch, and a change queue measured in weeks. Meanwhile the business already pays for Microsoft 365 and wants the same governed numbers somewhere it can filter them.
So an OBIEE to Power BI migration is a semantic-layer project wearing a reporting project's clothes. The interesting decisions live in the business model and mapping layer — what each logical table really represents, at what grain, which joins the BI Server was resolving for you at query time, and which hierarchies genuinely earn their keep. Get that into a star schema and the analyses follow quickly. Copy the catalog first and you inherit the same ambiguity in a new tool, with none of the run-time rescue Oracle was quietly providing.
What the rebuild covers
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. Documenting one subject area and the analyses that depend on it makes a good first task: it tells you the real size of the job before you commit a budget to it.
How we approach it
The Oracle BI Server does a lot of work at query time that Power BI expects you to have settled in the model. Naming those behaviours early is what keeps the rebuild predictable instead of surprising you at month-end.
We walk the repository through its physical, business model and mapping, and presentation layers — connection pools, aliases, logical tables and their sources, joins, hierarchies, variables and data filters — before any visual is drawn.
A presentation-layer subject area is already a departmental boundary someone agreed to years ago. We use it as the migration unit, so the first phase has a fixed edge instead of stretching across the whole catalog.
Logical tables that stitch several physical sources together are resolved into fact and dimension tables at one grain each, with conformed dimensions where two facts are compared and bridge tables where a relationship is genuinely many-to-many.
Logical dimension hierarchies and level-based measures carry assumptions about grain and rollup. Each one becomes an explicit choice in the model: a hierarchy worth keeping, a DAX measure with its own filter, or a level nobody has used in years.
Initialization blocks that fetch a user's region, cost centre, or ledger at login are re-expressed as a security table plus a row-level security role, then tested user by user so the same people see the same rows after cutover.
Statutory packs, remittances, and bursted statements are not dashboards. Anything that came out of BI Publisher for printing or emailing is rebuilt as a paginated report so page breaks and every printed row land where the recipient expects them.
Oracle BI separates a governed metadata layer from the content that consumes it. The RPD holds the physical model, the business model and mapping layer where logical tables, joins, hierarchies and calculations live, and the presentation layer that exposes subject areas to report authors. The BI Server turns a user's request into SQL using that metadata. Power BI splits the same responsibility differently: a semantic model holds tables, relationships and DAX measures, and reports visualise it. The migration is therefore a model rebuild with a known map, not a file conversion.
The practical consequence is where ambiguity gets resolved. A logical table can be mapped to several logical table sources at different grains, and the BI Server picks one at query time; a tabular model has no equivalent rescue, so the grain has to be right in the table or the measure is wrong everywhere it is used. That is a relocation of the decision rather than a drawback, and it is the reason we read the repository before quoting the analyses.
Newer estates make this easier. Teams already running Oracle Analytics Server or Oracle Analytics Cloud have usually tidied the model on the way through an upgrade, so the logical layer is closer to a star schema and the translation is shorter. Older 11g-era repositories that grew by accretion need the extra step of deciding which logical table sources and hierarchies still earn their place.
This is the working map the plan is built from. It is deliberately unglamorous: the value of a migration map is that nothing surprising appears in week three, and that every line has an owner who agreed to it.
| OBIEE / Oracle Analytics | Power BI equivalent | What changes in practice |
|---|---|---|
| RPD physical layer and connection pools | Power Query queries, or views in the warehouse | Source definitions move into the model's queries; aliases usually become named views |
| Business model and mapping layer | The semantic model: tables, relationships, DAX measures | Governed logic leaves a binary repository file and becomes a shared, refreshable model |
| Presentation layer subject area | One published semantic model with display folders | The subject area boundary becomes the migration unit and the workspace boundary |
| Logical table with several logical table sources | One table at one grain, sourced by a single query | Source selection stops happening at query time and becomes a modelling decision |
| Aggregate navigation to summary tables | A base-grain fact, or user-defined aggregations in the model | The performance trick becomes explicit and testable instead of implicit |
| Logical dimension hierarchy and levels | Model hierarchy on a dimension table | Levels survive; the drill path is rebuilt on the visual rather than declared in metadata |
| Level-based measure | A DAX measure that sets its own filter context | Share-of-total and parent-level logic is written once, by name, and reused |
| Logical column calculation | DAX measure, or a Power Query / calculated column | Before-versus-after aggregation becomes the difference between a column and a measure |
| Repository variable | Model parameter, or a flag column on the date dimension | "Current period" logic becomes visible in the model instead of hidden in a block |
| Session variable from an initialization block | Row-level security filter keyed on the signed-in user | Login-time SQL becomes a security table plus a DAX role that can be tested |
| Data filter on an application role | Row-level security role on the semantic model | Row rules move onto the model and are verified with the View as role feature |
| Answers analysis (compound layout) | Report page with table, matrix, and chart visuals | Views stop carrying their own criteria and read from one governed definition |
| Dashboard with pages and prompts | Report with pages, slicers, and sync slicers | Users change the view themselves instead of re-running a prompted dashboard |
| Presentation variable driving a view | Field parameter or a what-if parameter | The pattern survives, but it is rebuilt rather than translated line for line |
| Selection steps and saved filters | Report filters, bookmarks, or a curated dimension attribute | Ad-hoc member lists usually become a maintained attribute so they stop drifting |
| BI Publisher fixed-layout report and bursting | Paginated report in Power BI Report Builder, plus subscriptions | Layout and per-recipient delivery are preserved rather than approximated |
| Agent (iBot) with conditional delivery | Scheduled refresh, subscriptions, and data alerts | Condition-then-deliver logic is re-planned; the trigger model is not identical |
| Web catalog folders and permissions | Workspace roles and app audiences | Who sees which content becomes a permissions question, not a modelling one |
| Usage Tracking | Workspace usage metrics | Adoption data keeps informing which reports survive the next phase |
Two lines in that table carry most of the risk, and both are modelling lines rather than reporting ones: logical tables with multiple sources, and hierarchies with level-based measures. Both are why we design against Microsoft's star schema guidance (opens in new tab) rather than importing the logical layer as-is. The measure work that follows is the data modeling and DAX half of the job, and Microsoft's own Power BI migration guidance (opens in new tab) follows the same sequence: assess and prioritise the estate before rebuilding any of it.
This question deserves a straight answer, because it is the one option a Cognos or Qlik estate never has. Third-party ODBC connectors — BI Connector is the best known — let Power BI query your existing subject areas directly, so the repository stays the governed layer, the security rules keep applying, and nothing is re-modelled. For a team that wants Power BI visuals next quarter and has no appetite to touch the RPD, that is a legitimate route rather than a compromise.
What it does not do is retire anything. You keep the Oracle stack, its licensing, and its support model, and your Power BI reports inherit the BI Server's query envelope instead of a tabular model's in-memory one. Import mode, incremental refresh, aggregations, and composite models all sit on the other side of an actual migration, and so does the ability to blend the subject area with data that never lived in Oracle.
| Consideration | Migrate the subject area | Connect via ODBC connector |
|---|---|---|
| What happens to the RPD | Rebuilt as a Power BI semantic model, then retired subject area by subject area | Stays in place as the governed layer, unchanged |
| Where measures live | Named DAX measures you can read, version, and extend | Logical columns in the repository, edited in the Administration Tool |
| Oracle licensing and infrastructure | Can be decommissioned once the last subject area moves | Still required, plus the connector itself |
| Query behaviour | Import or DirectQuery against your own model, with aggregations available | Passed through to the BI Server; performance follows its plan, not yours |
| Blending non-Oracle data | Straightforward — other sources join the same model | Limited to what the subject area exposes |
| Effort profile | Front-loaded modelling work, then cheap per report | Fast to stand up, ongoing dependency on two platforms |
| Best fit | Departments committed to leaving Oracle BI | A bridge during a parallel run, or a department that is not moving yet |
In practice the two are complementary. Connecting first is a reasonable way to let a department feel Power BI on real numbers while the model rebuild happens behind it — provided everyone agrees the connector is a bridge with an end date, not the destination. What goes wrong is leaving it undecided: two governed layers, two sets of measure definitions, and an argument every month-end about which one is right.
Start by classifying, not rebuilding. An Answers catalog accumulates: the same analysis saved by four people, a dashboard page nobody has opened in a year, and a handful of views that month-end genuinely depends on. Usage Tracking and the catalog's own metadata make that call evidence-based rather than political, and it routinely removes more work than the rebuild adds.
Surviving content splits cleanly. Anything a person explores becomes an interactive report on the shared model, with dashboard prompts rebuilt as slicers and sync slicers so the filtering habits survive. Anything a person prints, files, or sends to a customer — the BI Publisher side of the estate — becomes a paginated report (opens in new tab) in Power BI Report Builder, which gives exact page-layout control and prints every row across as many pages as it takes. Paginated reports depend on the capacity your workspace runs on, so confirm the licensing against Microsoft's current documentation before committing to a design.
Agents are the piece that needs a decision rather than a translation. Condition-then-deliver behaviour maps onto scheduled refresh, subscriptions, and alerts, but not one-for-one, so we agree the delivery design with the recipients early instead of discovering it at cutover.
Oracle BI usually enforces two different things that get discussed as one. Data filters on application roles, often driven by session variables from an initialization block, restrict which rows a user sees; catalog and presentation-layer permissions restrict which objects they can open at all. Those separate cleanly in Power BI, and keeping them separate is what makes the rebuild testable.
Row rules become row-level security (opens in new tab) roles on the semantic model. In most estates the initialization block's query becomes a security table — user, then the cost centres, regions, or ledgers they may see — and the DAX filter matches the signed-in user against it, which keeps the rule in data rather than in code. Object visibility becomes workspace roles and app audiences. We document the mapping from your existing application roles so the security review at cutover is a comparison, not an investigation.
We scope the first phase as a departmental slice: one subject area and the 15 to 40 analyses that depend on it. That is small enough to quote as a fixed fee at the Growth ($4,600) or Power ($8,000) block price point depending on how much modelling the subject area needs, and large enough to prove the model, the security rules, and the numbers on real month-end data. Work after the pilot runs on prepaid Flex hours that never expire — Starter ($2,500), Growth ($4,600), or Power ($8,000), with hourly work from $100/hour — so the next subject area is a scoped task, not a new negotiation.
Cost tracks the shape of the model far more than the number of analyses. A single-fact subject area feeding thirty list-style analyses is a much smaller job than three facts, a set of level-based measures, and a data filter per business unit. You get an estimate in hours per deliverable, approve only what you want built, and unused hours stay banked. See Flex pricing.
Individual reports typically ship within 3–5 business days of approval once the model is standing, and a phased migration is a sequence of those tasks rather than one project ending in a big-bang cutover. The model is the front-loaded piece: it is worth building and reconciling before the report queue starts, because every analysis after it gets cheaper.
Running Oracle BI alongside Power BI for one full reporting cycle is worth the overlap. Users compare both outputs on live data, differences get explained rather than argued about, and the subject area is switched off only once its replacement has been through a real month-end.
Finance, operations, and IT teams carrying an Oracle BI estate they can no longer maintain comfortably: a repository only one person understands, a support or upgrade decision that has stopped looking like value, prompt-driven dashboards nobody can self-serve, or a knowledge gap left by whoever built the model. It is a poor fit for anyone wanting a like-for-like screen copy with no modelling decisions made — that buys a more expensive version of the problem you already have.
subject area per phase
analyses in the pilot
own everything
Start with one department, not the catalog. Comparing routes off different legacy platforms? The migration to Power BI hub covers them side by side, and the Cognos to Power BI migration page covers the closest equivalent estate.
How it works
We document the subject area you nominate — logical tables and their sources, joins, hierarchies, level-based measures, variables, initialization blocks and data filters — and inventory the analyses and dashboards that use it, with owners and run frequency. You approve the list and the fixed fee behind it before work starts.
The business model becomes a star schema with conformed dimensions, explicit hierarchies and named DAX measures. Surviving analyses are rebuilt on top of it highest-value first, dashboard prompts become slicers, and anything that has to print becomes a paginated report.
Each rebuilt report runs beside its Answers original on the same prompts and period, differences are explained, then we publish, set refresh, row-level security and permissions, walk your users through it, and stay available on the hours you have left for the next subject area.
Representative perspective
The thing we underestimated was the repository. Once someone wrote down what each logical table actually meant, half the arguments about which number was right answered themselves.Finance systems manager, mid-market manufacturer
Representative perspective
Doing one subject area first was the part that made it fundable. We proved the security rules on a department before anyone had to defend a whole-estate budget.IT director, multi-entity services group
Tell us which subject area matters most and roughly how many analyses hang off it. We'll scope the repository read and the rebuild as a fixed fee, so you can see the real project before committing to it.
FAQ
No. The RPD describes logical tables, logical table sources, hierarchies and aggregate navigation that the Oracle BI Server resolves into SQL at query time, and there is no import path into a tabular model. What is systematic is reading the business model and mapping layer object by object and rebuilding it as a documented star schema with named DAX measures.
Session initialization blocks usually exist to populate a variable that filters rows for the signed-in user. In Power BI that becomes row-level security: a security table mapping users to the values they may see, plus a DAX role filter keyed on USERPRINCIPALNAME. Repository variables holding a current period or rate become model parameters or a dated dimension column.
Sometimes. A third-party ODBC connector such as BI Connector lets Power BI query your existing subject areas, so the RPD stays the governed layer and nothing is re-modelled. It is a reasonable bridge during a parallel run, but you keep the Oracle stack and its licensing, and you inherit the BI Server's query envelope rather than a Power BI model's.
Fixed-layout output moves to paginated reports authored in Power BI Report Builder, which control page breaks, repeating headers and printing every row. Agent and BI Publisher bursting is re-expressed as subscriptions or a per-recipient delivery process. Confirm capacity licensing for paginated reports against Microsoft's current documentation before committing to that design.
One subject area and the 15 to 40 analyses that depend on it — a departmental slice rather than the whole catalog. That is small enough to quote as a fixed fee, big enough to prove the model, the security rules and the numbers, and it leaves the rest of the estate on Oracle until the department has been through a real month-end.
This page covers the Oracle path specifically. Where the RPD sits on top of JD Edwards, the source-system half of the job — reading F0911 and F4211 from the EnterpriseOne or World database, converting Julian dates and decoding UDCs — is described on our JD Edwards Power BI dashboard page, and the two are often one engagement. If your estate spans several tools, the broader migration to Power BI service handles the Excel and SSRS routes on the same prepaid model, and the closest neighbouring rebuilds are Cognos to Power BI migration, where a Framework Manager package plays the part the RPD plays here, and MicroStrategy to Power BI migration, where the project schema, its Level Metrics and its lookup-table snowflake set the scope instead. A Pentaho estate follows the same method with a Mondrian schema in the RPD's place, so the Pentaho to Power BI migration page starts from the schema XML and the Kettle jobs. The rebuild itself is data modeling and DAX work, and teams standing up their first workspace usually pair it with Power BI consulting for the licensing and governance decisions a rollout brings. Every task is scoped before work begins from your prepaid block of senior-led hours, and hours are deducted only for work you approve.
Book a free demo
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.