Let me be direct about something: if you're planning an OAC to Power BI migration and thinking you'll do it manually, you should sit with that decision for a moment before committing.
We've seen organizations underestimate this project more times than I'd like to count. Not because their teams aren't capable — they are — but because the combination of asset volume, semantic layer complexity, and manual visual translation creates a workload that consistently exceeds initial estimates by 3x or more.
At KPI Partners, we've run this migration enough times to build a purpose-designed utility around it. This is a detailed walkthrough of how that utility works, what it automates, where it still requires human judgment, and what the end state looks like architecturally. If you're a data engineer or BI architect evaluating how to approach this migration, this should give you a realistic picture of what you're dealing with.
Why OAC to Power BI Migration Is Harder Than It Looks
The obvious challenge is volume. A mature OAC environment typically holds somewhere between 35 and 50 subject areas, 250 to 400 or more individual analyses, 60 to 100 or more dashboards, and a set of .BAR files containing years of accumulated business logic that nobody has fully documented. If you scope that manually — even with a structured spreadsheet approach — you're looking at weeks of inventory work before you've written a single line of Power BI code.
But the volume is honestly the easier problem. The harder problem is semantic translation.
OAC's RPD encodes a significant amount of business logic: metric definitions, aggregation rules, hierarchy structures, row-level security filters, presentation variables. None of this has a direct equivalent in Power BI's tabular model. It needs to be translated — not just copied — and that translation requires someone who understands both platforms deeply.
When that translation is done manually, it's slow, inconsistent, and error-prone. When a calculated metric in OAC uses a non-standard aggregation pattern that a Power BI developer misinterprets, you end up with a migrated report that shows the wrong numbers. In a large environment, you might not catch that until well into QA — which means rework cycles that blow your timeline.
This is precisely the problem we built our utility to solve.
How the KPI OAC to Power BI Migration Utility Works
The utility runs in three stages: Extract, Convert, and Publish. Each stage is designed to handle a specific category of migration work systematically so that human effort is concentrated where it genuinely adds value.
Stage 1: Extract — Full Asset Discovery
The extraction phase is a full, non-destructive read of your OAC environment. It doesn't modify anything in OAC, and it can run against live environments without any downtime or disruption.
What gets captured: all dashboard and page definitions including layout, tab structure, and prompt filters; all analyses including column selections, filter expressions, sort definitions, view configurations, and calculated columns; presentation layer metadata including subject area names, table and column labels, and folder hierarchies; and the full contents of your .BAR files — Physical layer connections, Business Model mappings, calculated metrics, aggregation rules, level-based measures, hierarchy definitions, and row-level security filters.
The output is a structured asset catalog tagged by type and complexity. This catalog drives two things: the free migration assessment report and the input to the conversion engine in Stage 2.
Worth calling out specifically: the free migration assessment stops after extraction and returns a total asset count by type, a complexity distribution across simple, medium, and complex categories, estimated migration hours, and a cost and timeline range. No commitment required. This alone is worth requesting — manual scoping of the same environment typically takes weeks.
Stage 2: Convert — Systematic Translation
This is the core of the utility and where the most meaningful work happens.
For visuals, the conversion engine maps every OAC view type to its Power BI equivalent. Table views become Power BI tables. Pivot table views become matrix visuals with row, column, and value mappings preserved. Bar and line charts translate directly. Gauge charts become KPI card or gauge visuals. Narrative views become text boxes. Heat matrices become matrix visuals with conditional formatting rules applied. Dashboard prompts become slicers, with single-select or multi-select behavior preserved based on the original configuration.
For the semantic layer, OAC logical metrics are translated into DAX measures using pattern matching. Simple aggregations like SUM, AVG, COUNT, MAX, and MIN translate directly into equivalent DAX measures. Conditional aggregations using CASE WHEN logic become CALCULATE with filter arguments in DAX. Period-over-period functions like OAC's AGO function translate to DAX time intelligence functions like SAMEPERIODLASTYEAR and DATEADD. Running totals using RSUM become CALCULATE with ALL and date filter patterns. Ranking functions translate to RANKX with the appropriate partition and sort arguments.
Non-standard expressions that don't match known patterns are added to a flagged review queue with the original OAC expression alongside a suggested DAX translation. A Power BI developer reviews each one and approves or adjusts. In a typical engagement, roughly 85 to 90 percent of metrics are converted automatically. The remaining 10 to 15 percent require review.
For filters and prompts: dashboard prompts become report-level slicers, page-level prompts become page-level filters, column filters translate to visual or page-level filter pane entries, presentation variables become Power BI parameters or DAX variables, and row-level security filters translate to Power BI RLS role definitions.
For hierarchies: dimension hierarchies from the RPD Presentation layer are recreated as Power BI hierarchies in the tabular model. Drill paths become drill-through configuration or embedded hierarchy navigation in matrix visuals.
Stage 3: Publish — Deployment and Validation
Once conversion is complete, the utility packages all migrated assets and deploys them to your target Power BI workspace or Microsoft Fabric environment.
Workspace structure mirrors the original OAC dashboard hierarchy so users can navigate to familiar locations in the new platform. Dataset connections are updated to point to target data sources. Report pages are deployed with converted visuals and filter configurations in place. OAC group roles are mapped to Power BI workspace roles and RLS definitions.
Post-publish validation is where KPI Partners' engineers add the most hands-on value. We run side-by-side comparison — OAC source report next to migrated Power BI report — checking data values, visual rendering, filter behavior, and edge case handling. Discrepancies are logged, root-caused, and resolved before production sign-off. Nothing goes near production until both sides of the comparison check out.
What the Utility Doesn't Automate
I want to be straight about this, because over-promising on automation is a real problem in migration tooling.
Highly customized RPD expressions that don't match standard patterns still require a Power BI developer to review and reimplement. Pixel-level visual formatting requirements from original OAC reports may need manual adjustment. Content built on custom OAC plugins or extensions doesn't have automatic Power BI equivalents. Data source authentication setup — connection strings, OAuth configuration, service accounts — requires hands-on work. Business rule validation, meaning confirming that a converted metric calculates correctly and not just that it runs without errors, requires human judgment. And user acceptance testing requires your team and your users to be actively involved.
The utility's job is to eliminate the systematic, repetitive work so your team's time goes to the 10 to 15 percent that actually requires expertise. That's where the 85 percent efficiency gain comes from.
Post-Migration: What Power BI and Fabric Actually Give You
After migration, your BI layer sits on Power BI inside Microsoft Fabric. Here's what that means in practical terms.
DAX is a richer, more expressive language than OAC's Logical SQL, and the developer ecosystem around it is significantly larger. VS Code extensions, Tabular Editor, DAX Studio for query profiling and optimization — the tooling is mature and well-supported. Debugging and optimizing measures is dramatically more accessible than working in the RPD.
Power BI supports Import mode for performance, DirectQuery for real-time freshness, and Composite mode for mixed requirements — all within a single semantic model. OAC's architecture doesn't offer this level of flexibility.
Power BI Desktop projects support native Git integration, which means version control, branching, pull requests, and CI/CD pipelines for your BI layer. This is a significant operational improvement over OAC's development workflow, where version control was largely an afterthought.
If your data engineering team is moving to a Lakehouse architecture on Microsoft Fabric, your Power BI semantic models sit natively on top of OneLake without additional connectors or transformation layers. The data and analytics platforms share storage from day one.
Power BI Copilot — AI-powered natural language Q&A, report summarization, and automated insight detection — is live today, built on Azure OpenAI. It's improving every release cycle. OAC has no equivalent roadmap investment.
And Power BI's REST API enables programmatic workspace management, dataset refresh automation, report embedding, and CI/CD pipeline integration at a level that OAC's integration surface simply doesn't support.
When to Use This Approach vs. Manual Migration
Use the KPI migration utility approach when you have 50 or more reports to migrate, when you need a defensible cost and timeline estimate before project approval, when you want to minimize key-person risk on the migration, when your OAC environment has years of accumulated configuration with limited documentation, when you have a hard deadline such as a licensing renewal or decommission date, or when your organization is already on Microsoft 365 or Azure.
Manual migration may still make sense if you have fewer than 20 reports and most of them are simple table or chart layouts, if you're redesigning your entire data model in the migration so source-to-target mapping is changing fundamentally anyway, or if the OAC environment is so heavily customized that automated pattern matching would flag everything for review regardless.
Step-by-Step: How the Engagement Works
Here's the practical path from where you are today to a migrated Power BI environment.
First, request the free migration assessment. We run extraction on your OAC environment and return a complete inventory with a migration estimate. No commitment required at this stage.
Second, review the assessment output with your team and leadership. Use it to get project approval with a real scope and budget, not a rough estimate.
Third, kick off the migration engagement. We run the conversion pipeline, manage the exception review queue, and keep your team informed throughout. You're not left to manage a complex technical project alone.
Fourth, participate in validation. Your team and end users run UAT against the migrated Power BI reports. Discrepancies get resolved before anything is signed off.
Fifth, production deployment into Microsoft Fabric. OAC decommission planning begins on a timeline that works for your organization.
The whole process moves significantly faster than conventional estimates because the heavy lifting is automated. We're typically talking weeks, not months, for environments that manual migration would stretch to 12 to 18 months.
Get the Free Assessment
No cost. No commitment. Just a clear, accurate picture of what your OAC to Power BI migration involves — scope, complexity breakdown, and a concrete timeline and cost estimate.
KPI Partners OAC to Power BI Migration Utility
Drop us a line at info@kpipartners.com if you'd prefer to talk through your environment before taking any formal steps.
Top comments (0)