10 Sep 2026

What Actually Moves in a Power BI Report Migration

Q: Can legacy report files be directly converted to .pbix?

Not with a simple file conversion. Report layouts, formulas, and data connections must be remapped, and the source semantic layer must be remodeled into Power BI's Tabular structure. Automated tooling can accelerate structural conversion, but no one-to-one automatic import exists.

Q: Can source formulas be automatically converted to DAX?

Not reliably. Crystal syntax, Cognos expressions, Jaspersoft expressions, and Alteryx tool logic need to be analyzed by business intent and rewritten for DAX. Automation can assist with report structure and standard assets, while calculation logic still requires expert translation and validation.

Q: Should reports become interactive dashboards or paginated reports?

It depends on the report. Fixed-layout and print-ready reports generally map best to Power BI paginated reports built with Power BI Report Builder, while exploratory, analytical, and summary reports are better rebuilt as interactive Power BI reports.

Q: What happens to subreports during migration?

Subreports are typically redesigned as Power BI drill-through pages, navigation patterns, buttons, bookmarks, or related report pages because Power BI does not provide a direct nested-subreport equivalent.

Q: Does migrating disrupt our current reporting?

A phased migration can run in parallel with the existing reporting environment, allowing users to continue using current reports until the Power BI reports are validated and ready for production. Source licenses can then be decommissioned in phases.

Q: Is this the same as migrating Power BI between tenants?

No. Tenant-to-tenant migration moves existing Power BI workspaces, datasets, reports, and related assets between Microsoft tenants. This guide focuses on migrating into Power BI from another reporting or analytics platform.

Q: Is Power BI still in demand in 2026?

Yes. Power BI continues to be Microsoft's actively developed business intelligence platform, with ongoing investment in Microsoft Fabric integration, Copilot-assisted analytics, semantic models, and modern data connectivity.

Enterprises running legacy reporting keep hitting the same wall: rising licensing costs, shrinking specialist talent, looming end-of-life deadlines, and business users who want self-service analytics instead of IT-gated reports. Power BI report migration, backed by Microsoft Fabric and Copilot-driven AI, has become the default path.

Quick Summary

Power BI report migration means rebuilding reports, data models, formulas, and security across four layers, not converting a file. The modeling layer carries the most risk, and DAX/formula conversion is consistently the biggest effort driver; no reliable automated converter exists for that layer. This guide covers what moves, the step-by-step process, and where automation genuinely helps versus where expert review is unavoidable, across Crystal Reports, SSRS, Cognos, Jaspersoft, and Alteryx.

A note on scope: this guide covers migrating into Power BI from another reporting platform. If you're looking to move existing Power BI content between tenants or workspaces (a "tenant-to-tenant" migration), that's a different process; Microsoft's own Power BI migration overview covers that scenario specifically.

At a Glance

It's a rebuild, not a file conversion. Legacy report files (.rpt, RDL, JRXML, Cognos specifications, Alteryx workflows) can't be imported; you re-express report logic in DAX and Power Query (M), not copy it over.
The modeling layer carries the most risk. Most migrations fail when a source semantic model is force-fit into Power BI's Tabular engine instead of being redesigned around an explicit star schema first.
DAX / formula conversion is the biggest effort driver. Crystal formulas, Cognos RXL, Jaspersoft expressions, and Alteryx tool logic each need manual re-derivation into DAX; no reliable automated converter exists for this layer.
Two target formats. Interactive .pbix dashboards for exploration; Power BI Report Builder paginated reports (RDL) for pixel-perfect, print-precise output.
Start with report inventory and audit. In most enterprises, 30-50% of reports are duplicates, unused, or obsolete; not every report deserves a 1:1 rebuild.
Automation is the biggest lever. An XML-based conversion of standard, structural assets can cut manual effort by an estimated 30-70%.

What Is Power BI Report Migration?

Power BI report migration is the structured process of moving reporting assets, reports, dashboards, data models, business logic, security rules, and metadata from a legacy platform into Microsoft Power BI, while preserving calculations, layout intent, and governance. It is not a simple file conversion: source and target use fundamentally different metadata and calculation models, the same distinction Microsoft's own migration guidance draws between assessment, architecture, and execution phases.

Every migration spans four asset layers, each of which must be rebuilt natively in Power BI:

Layer	What Moves	Power BI Target
Reporting	Source lists, crosstabs, dashboards, and print-layout reports (.rpt, RDL, JRXML)	Interactive .pbix dashboards or paginated reports
Modeling	Source semantic layer, packages, domains, or report-level SQL	Power BI semantic model (Tabular)
Metadata	Formulas, calculations, joins, and business definitions	DAX measures + Power Query (M) expressions
Security	Namespaces, domain security, and section-access rules	Row-Level Security (RLS) roles

Because the source and target metadata models differ, most migration failures happen at the modeling layer, not the visualization layer, which is where scoping and expertise matter most.

Why Enterprises Are Migrating to Power BI

Total Cost of Ownership

Legacy BI is typically priced per named user with server and maintenance layered on top. Power BI's per-user and capacity-based pricing, especially bundled into an existing Microsoft 365 or E5 agreement, lowers the effective cost of BI at scale.

Vendor End-of-Life Pressure

Fixed retirement deadlines are accelerating report migrations. SAP Crystal Reports 2020 loses mainstream maintenance on December 31, 2026, and Crystal Reports 2025 follows on December 31, 2027, with no confirmed extended support beyond, after which reports keep running but stop receiving security patches and fixes- the same deadline pressure covered in our Crystal Reports to Power BI migration guide.

Scalability & Self-Service

Legacy authoring leans on centralized IT to build and maintain reports. Power BI shifts creation toward business users through Power Query, drag-and-drop visuals, and shared semantic models, cutting the report backlog common in legacy environments.

AI Readiness

Power BI's Copilot integration enables natural-language querying, auto-generated summaries, and AI-assisted DAX authoring, capabilities that pull analytics-forward enterprises toward the Microsoft stack.

Microsoft Fabric Alignment

Organizations already invested in Azure or Fabric get a unified data estate, lakehouse, warehouse, and BI layer when they consolidate onto Power BI instead of running legacy tools as a disconnected silo- the same consolidation logic covered in our Microsoft Fabric to Power BI migration guide.

Source Platforms & the Tricky Part

DataTerrain delivers every major report migration path onto Power BI. Each source platform has its own tricky part, the thing that quietly eats time and budget. Knowing it upfront is what makes scoping accurate.

Source	The Tricky Part	Why It Takes Effort
Crystal Reports	Pixel-perfect layouts, dense formulas & subreports	Custom formulas and reports-within-reports recreated one by one; .rpt reaches end-of-life by 2027
SSRS	Already Microsoft, the closest match	The easiest move; mostly re-pointing data and adjusting expressions, with RDL porting closely to Report Builder
Cognos / WebI	Business rules buried in Framework Manager or Universes	RXL or Universe logic must be dug out and translated, or results come out wrong
Jaspersoft	Rigid banded layouts with embedded SQL	Layout and baked-in queries are unpicked and rebuilt, and each report routed to a dashboard or a paginated report
Alteryx	Data-prep logic, not just reports	Every tool is re-created in Power Query / DAX; custom R and Python logic needs manual redesign

The takeaway: SSRS is the easiest (same Microsoft family), Cognos and WebI are among the hardest (deep model redesign), and the rest sit in between. The effort is almost always in the hidden calculations, not the charts you can see. Migrating from a different source platform entirely- Qlik, Tableau, MicroStrategy, OBIEE, or SAP BusinessObjects- follows the same underlying discipline; see our guides to Qlik to Power BI, Tableau to Power BI, MicroStrategy to Power BI, and OBIEE to Power BI for those specific paths.

Step-by-Step Migration Process

A disciplined, phased sequence keeps the rebuild accurate and auditable. Errors compound downstream, so the order matters.

Phase	What Happens
Inventory & Audit	Catalog every report, noting formula density, subreports, embedded SQL, and usage. Rationalize; 30-50% are typically duplicates, unused, or obsolete, and prioritize business-critical, high-usage reports first.
Mapping	Map each source asset to its Power BI equivalent and score by calculation depth, RLS use, and custom-visual dependencies. Decide dashboard (.pbix) vs paginated (Report Builder) per report to sequence the work and estimate effort.
Data Modeling	Design a star-schema semantic model. Report-level SQL, domains, and packages are rebuilt as Power Query (M) transformations and relationships, a reusable foundation instead of one-off queries per report.
Conversion	Rebuild calculations → visuals. DAX measures replace source formulas and expressions; subreports become drill-through pages or bookmarks; RLS replaces namespace/domain security; dashboards and paginated reports are built on the shared model.
Validation & Cutover	Run parallel testing against the source, row counts, calculation results, and visual parity, using a side-by-side matrix for every measure. Then roll out in phases by department or app group, decommissioning source licenses in waves after each is signed off.

Common Migration Challenges

Semantic Model Redesign

Source models built over years contain nested calculations and nonstandard joins with no clean Power BI equivalent. Cognos's relational/dimensional metadata and Jaspersoft's per-report domains don't map 1:1 to Power BI's Tabular engine, forcing the old structure in and producing reports that fight the platform. Redesign around an explicit star schema before rebuilding on top of it.

DAX / Formula Conversion

Every source expression must be manually reasoned through and rewritten in DAX, a different language with its own context and filtering logic. Crystal formulas, Cognos RXL, Jaspersoft expressions, and Alteryx tool logic each need re-derivation by business intent, not mechanical translation. Time-intelligence functions are especially prone to silent errors. This is consistently the single largest source of migration effort.

Pixel-Perfect & Paginated Layouts

Crystal Reports' and Jaspersoft's print-precise formatting doesn't translate directly to Power BI's canvas-based visuals. Power BI Report Builder's RDL-based paginated reports close most, but not all, of the gap, and deeply nested subreports usually need redesigning as drill-through rather than direct conversion.

Data Source & Power Query Re-Mapping

Report-level SQL, load scripts, and incremental-load patterns have to be re-implemented in Power Query's M language, which has a different syntax and execution model. Validate row counts at this layer first, before any calculation work begins.

Security Parity & Adoption

Namespace, domain, or section-access security must be remapped to RLS without creating access gaps; revalidate every rule against real user accounts, not admin logins. Business users trained on the legacy tool also need change-management support to adopt Power BI's self-service workflows.

Best Practices for a Smooth Migration

Complete a report inventory and audit first. Tier reports by complexity (simple, multi-source, formula-heavy) before converting anything, and retire unused reports instead of migrating them.
Migrate by business intent, not syntax. Document what each measure is meant to calculate before rewriting it in DAX.
Design the star schema properly first. Build DAX measures once against a shared semantic model rather than importing the source structure as-is.
Rebuild in strict order. Data → semantic model → calculations → visuals, so errors don't compound downstream.
Route reports to the right format. Send pixel-perfect, print-style reports to Power BI Report Builder (paginated); send exploratory and summary reports to interactive .pbix dashboards.
Validate before cutover, not after. Reconcile every converted report against its source with a side-by-side matrix.
Re-test every RLS rule against real user accounts. Not just admin logins.
Phase the rollout and train authors early. Roll out by department or app group, and invest in DAX and Power Query training alongside the technical migration, the same phased discipline covered in our key checklist for BI modernization.

Manual vs Automated Migration

Manual, report-by-report migration is the biggest driver of missed timelines and budget overruns. An automated, XML-based pipeline (source → intermediate XML → Power BI) does the heavy lifting on predictable, structural work, standard visuals, table and relationship structure, and data-source scaffolding, mapping across with little manual effort. The logic layer is where expert craft adds the most value: specialists translate and validate DAX measures, security rules, and interaction models to ensure accuracy.

Factor	Manual Migration	Automated Migration
Report analysis	Manual review of each report's layout and formulas	Automated parsing of report structure and formula fields
Formula conversion	Field-by-field, report by report	Bulk formula-to-DAX conversion via mapping rules, expert-validated
Consistency	Varies by developer	Uniform naming & calculation logic across the estate
Timeline (500+ reports)	Several months	Weeks to a couple of months
Auditability	Ad hoc	Traceable record of how every asset was converted

Automation scales with the source platform. The share of work automation can carry depends on the source platform and how logic-heavy the reports are. SSRS (same Microsoft family) has the highest automation coverage, while platforms that require deeper model redesign, such as Cognos, rely more on expert engineering. The more a report's value lives in calculations rather than layout, the greater the expert contribution, which is why the automation share is best measured per source during the discovery phase, giving each project an accurate, tailored estimate up front- the same validation discipline covered in our guide to BI automation for report migration.

Case Study: OBIEE to Power BI for a Community College

DataTerrain brings 17+ years of BI migration and automation, with 400+ customers and 27,000+ reports and dashboards delivered. Every migration starts with a free Proof of Concept, a representative sample of your actual reports converted to Power BI at no cost, so your team can evaluate the approach on your own data before committing.

A governed Power BI semantic model replacing a legacy OBIEE estate

Client background. A U.S. public community college relied on Oracle Business Intelligence (OBIEE) for enrollment, financial aid, and academic reporting across multiple campuses and online programs.

The challenge. Not a simple report conversion. The team had to recreate dynamic OBIEE prompts, action links, and drill-through behavior; the centralized RPD semantic layer; data- and object-level security; pixel-perfect operational analyses; and complex pivot and hierarchy interactions.

What DataTerrain did. Rebuilt the RPD business model as a governed Power BI semantic model; re-engineered dynamic prompts with field parameters and dynamic M query parameters; recreated drill behavior with drill-through pages, buttons, and bookmarks; translated security into row-level security; and reconciled every report against OBIEE output before cutover.

The results.

Functional parity preserved across in-scope reports and dashboards.
Validated before go-live with source-to-target reconciliation.
One governed semantic model replacing duplicated report logic.
Accelerated delivery through automated migration tooling.

For the full detail on this OBIEE-specific migration path, see our OBIEE to Power BI migration guide.

Every engagement starts with a free Proof of Concept: we convert a representative sample of your own reports to Power BI at no cost, so you can see the approach applied to your actual data and formulas before committing to anything.

Talk to our migration team

Frequently Asked Questions

How long does a Power BI report migration take?

It depends on report volume and metadata complexity. A rationalized environment of a few hundred reports can migrate in weeks; tens of thousands can take months without automation. A focused migration of business-critical assets typically runs eight to sixteen weeks.

Can legacy report files be directly converted to .pbix?

Not with a simple file conversion. You must remap layout, formulas, and data connections, and remodel the source semantic layer into Power BI's Tabular structure. Automated tooling can speed this up, but no 1:1 automatic import exists.

Can source formulas be automatically converted to DAX?

Not reliably. Each formula or expression- Crystal syntax, Cognos RXL, Jaspersoft expressions, Alteryx tool logic- must be manually reasoned through and rewritten in DAX. Automation handles structure and standard visuals; calculation logic still needs expert translation.

Should reports become interactive dashboards or paginated reports?

It depends on the report. Fixed-layout, print-ready reports map best to Power BI paginated reports (Power BI Report Builder), while exploratory or summary reports are better rebuilt as interactive .pbix dashboards.

What happens to subreports during migration?

Subreports are typically rebuilt as Power BI drill-through pages or bookmarks, since Power BI has no direct nested-subreport equivalent.

Does migrating disrupt our current reporting?

No. Migration runs in parallel with the existing environment, so teams keep using current reports until the new Power BI content is validated and ready. Source licenses are decommissioned in phases.

Is this the same as migrating Power BI between tenants?

No, and it's worth being clear about the distinction if you're researching this term broadly. Tenant-to-tenant migration moves existing Power BI workspaces, datasets, and reports from one Microsoft tenant to another, a different process covered in Microsoft's own Power BI migration overview. This guide covers migrating into Power BI from a different reporting platform entirely.

Is Power BI still in demand in 2026?

Yes. Power BI remains Microsoft's actively developed flagship BI platform, with continued investment in Direct Lake performance, Copilot-assisted analytics, and deep Microsoft Fabric integration, which is part of why legacy-platform organizations continue migrating toward it rather than away from it.

Contents