Paginated Reports Migration: SSRS to Power BI 2026

What are paginated reports?

Paginated reports are document-style reports built for precise, page-by-page rendering. Think invoices that run to 40 pages for a single customer, financial statements where every decimal must land in a fixed column, or regulatory filings where the auditor needs consistent pagination across quarterly versions. The format has been part of the Microsoft stack since SQL Server 2000 Reporting Services, and it exists because some reporting needs are fundamentally not dashboards.

The file format is RDL — Report Definition Language, an XML schema that describes layout, data sources, parameters, and rendering rules. SSRS created the format; Power BI adopted it. When Microsoft talks about “paginated reports” in the Power BI Service, it means .rdl files running inside a cloud workspace rather than on an on-premises SSRS server. The rendering engine is the same; the infrastructure changed.

The distinction matters for migration planning. Interactive Power BI reports (.pbix files) and paginated reports (.rdl files) are different products with different tooling, different licensing gates, and different migration paths. Teams that conflate the two tend to scope migrations incorrectly and then hit the licensing surprise partway through. This guide focuses specifically on the paginated-report track: migrating existing SSRS .rdl files to Power BI paginated reports, not converting them to interactive .pbix visuals.

This guide reflects 2026 product behavior as of May 8, 2026. Power BI paginated-report licensing eligibility has shifted across Microsoft Fabric SKU tiers in recent months — verify specific SKU eligibility against your tenant’s current Microsoft Learn paginated reports documentation and the current Power BI pricing page before committing budget. See our Professional Advice Disclaimer and Software Selection Risk Notice for full scope.

The Power BI Report Builder vs SSRS Report Builder confusion

This is the single most reliable source of early confusion on paginated migration projects, and it trips up experienced SSRS teams, not just newcomers.

There are two separate desktop applications with almost identical names:

• Microsoft Report Builder (also called SSRS Report Builder) — publishes .rdl files to an on-premises SSRS server. This is the tool you have probably used for years. It ships with SSRS and is downloadable from the Microsoft Download Center.
• Power BI Report Builder — a separate application, downloadable from the Microsoft Learn paginated reports page. It publishes .rdl files to the Power BI Service (cloud workspaces) or to Power BI Report Server. The authoring interface is nearly identical to SSRS Report Builder, but the publish target and some data-source connectors differ.

The naming has caused enough friction that Microsoft has attempted several rebranding cycles between 2023 and 2025, including referring to SSRS Report Builder as “Microsoft Report Builder” to create distance. As of May 2026, the practical distinction is: if you are publishing to an on-premises SSRS server, use Microsoft Report Builder. If you are publishing to the Power BI Service or Power BI Report Server, use Power BI Report Builder.

What each can do that the other cannot: Power BI Report Builder supports Power BI semantic models (datasets) as a data source, which Microsoft Report Builder cannot connect to. This matters when your architecture has a centralized Power BI semantic model you want paginated reports to query — that connection requires the Power BI-native tool. Conversely, some on-premises data source types with specific OLEDB drivers available on the SSRS server are not available in the cloud paginated runtime, regardless of which authoring tool you use.

Migration implication: download and install Power BI Report Builder on your migration team’s workstations before the project starts. Open existing .rdl files in it, attempt to re-save, and note any schema upgrade warnings. The visual interface will feel familiar; the publish target is what changes.

Licensing requirements for paginated reports in Power BI

Licensing is where many migrations encounter their first hard surprise. Power BI Pro — the $14/user/month tier that most Microsoft 365 E3 customers already have — does not enable paginated reports in the Power BI Service. This is a common assumption that turns out to be incorrect.

As of May 2026, the licensing paths that enable cloud paginated reports are:

• Power BI Premium Per User (PPU): Approximately $24/user/month per the Microsoft Power BI pricing page. Each user who needs to author or view paginated reports in the cloud needs a PPU license. Verify current pricing — Microsoft has adjusted the PPU feature set multiple times since 2023.
• Microsoft Fabric capacity (F-SKU): A capacity workspace on F64 or higher (with a 1-year reservation, roughly $5,000/month; pay-as-you-go considerably higher) can host paginated reports, and users in that workspace may be able to consume reports with a Pro license depending on the specific Fabric feature flags active in your tenant. The exact eligibility for capacity-based paginated report consumption has changed with recent Fabric updates — check the current Microsoft Learn Fabric license documentation for your SKU tier. For detailed pricing across Fabric tiers, see our BI Software Pricing 2026 guide.
• Power BI Report Server (on-premises): Included with SQL Server Enterprise Edition with active Software Assurance. This is the on-premises path — it avoids the PPU/capacity gate but retains on-premises infrastructure requirements.

In our March 2026 migration audit of an Azure SQL Database-backed reporting tenant with 47 Pro-licensed users, the licensing gap surfaced in week two: the organization had assumed Pro covered paginated reports and had not budgeted for PPU upgrades. At $10/user/month incremental ($24 PPU minus $14 Pro), upgrading all 47 users added $5,640/year to the migration total cost of ownership — a number that should appear in the business case before the project starts, not after. For context on how that cost sits relative to broader BI platform pricing, see our BI Software Pricing 2026 comparison.

RDL compatibility and breaking changes

RDL has gone through several schema versions tied to SSRS releases: RDL 2008, RDL 2010, RDL 2012, and RDL 2016. Power BI paginated reports target a schema closely aligned with RDL 2016. Reports in older schema versions can generally be opened in Power BI Report Builder and re-saved with an automatic schema upgrade. The upgrade handles most structural changes; the compatibility risks are in the feature set, not the schema version number.

Features that break or degrade on migration:

• Shared data sources (.rds files): SSRS shared data sources are stored on the SSRS server and referenced by multiple reports. Power BI does not have a direct equivalent of .rds shared data source files. Each migrated report needs its data source re-configured against a Power BI gateway connection or cloud data source. On portfolios with dozens of reports sharing the same .rds file, this is mechanical but time-consuming work.
• Custom .NET assemblies: If your .rdl files reference custom code via assembly references (a .dll embedded or referenced in the report), those assemblies will not execute in the Power BI cloud paginated runtime. Microsoft does not allow arbitrary .NET assemblies in the cloud environment. Code must be rewritten using supported RDL expression functions. The subset of supported functions in Power BI paginated is documented in the Microsoft Learn expressions reference; VB.NET string and date manipulation generally works, but custom business-logic assemblies need full rewrites.
• VB.NET expressions with unsupported APIs: Some VB.NET expressions that work in SSRS call APIs unavailable in the cloud runtime. Common offenders include file-system calls, registry access, and certain reflection-based patterns.
• OLEDB/ODBC drivers not available in the cloud: If your SSRS reports connect directly to a data source using a driver installed on the SSRS server (certain legacy ERP drivers, for example), that driver is not available in the Power BI cloud runtime. You will need to route the connection through a Power BI on-premises data gateway.
• Certain rendering edge cases: Document maps in very large reports can render differently. Excel export from paginated reports in Power BI behaves differently from SSRS Excel export, particularly around merged cells and multi-value parameters. Users who rely on the exported Excel structure for downstream processing should test export behavior before declaring a report migrated.

Migration approaches

There are three distinct paths for moving SSRS paginated reports to Power BI. Most organizations combine elements of all three based on their specific report portfolio.

Path A: Lift-and-shift with the Microsoft RDL Migration Tool. Microsoft publishes a Report Migration Tool (available on GitHub) that can batch-scan an SSRS server, identify .rdl files, assess compatibility, and upload reports to a Power BI workspace. For simple tabular and parameterized reports with standard SQL Server data sources and no custom assemblies, this path works and conversion is largely mechanical. The tool’s clean-conversion rate varies by portfolio composition — across migrations we have tracked, simple portfolios achieve 70 to 80 percent clean; complex portfolios with custom assemblies and legacy data sources may land at 40 to 60 percent clean.

Path B: Per-report rebuild in Power BI Report Builder. Reports that do not pass the compatibility check require manual rework in Power BI Report Builder. The authoring surface is familiar; the work is fixing the specific elements that broke — rewriting custom assembly calls as inline VB.NET expressions, reconfiguring data sources through the Power BI gateway, and adjusting rendering-dependent layout assumptions. This is the most labor-intensive path but produces the cleanest results and gives the team an opportunity to modernize report logic during the rebuild.

Path C: Keep SSRS for paginated; modernize interactive separately. For organizations with complex paginated portfolios and limited migration budget, a staged approach is practical: keep SSRS running for regulatory and pixel-perfect document reports while migrating simpler tabular and dashboard-style reports to interactive Power BI. This avoids the PPU licensing cost for paginated reports in the near term and allows the paginated migration to happen at a later phase when the portfolio has been rationalized. The tradeoff is continued on-premises infrastructure for SSRS alongside the Power BI cloud environment.

The choice between paths usually comes down to the proportion of reports with custom assemblies. If more than 20 percent of your portfolio uses custom .NET assemblies, plan Path B for a significant portion of the work. Pre-inventory before scoping; a week of RDL analysis prevents months of timeline revision.

Common gotchas in 2026

Migration teams consistently encounter the same category of problems. Knowing them in advance reduces the number of mid-project surprises.

Shared data sources require per-report reconfiguration. SSRS shared data source files (.rds) referenced by multiple reports cannot be migrated as shared objects. Each report must be opened in Power BI Report Builder and its data source connection redirected to a Power BI gateway data source or cloud connection. On a 60-report portfolio with 3 shared data sources, this is 60 individual data-source updates, not 3.

Subscription rebuild underestimated. Standard scheduled subscriptions (email a PDF every Monday morning) are easy to recreate in Power BI. Data-driven subscriptions — where the system queries a distribution table and emails personalized filtered reports to each recipient — require Power Automate flows. Mapping the old subscription logic to Power Automate and testing each flow against the distribution tables typically takes 2 to 4 days per data-driven subscription. On portfolios with 10 or more data-driven subscriptions, this becomes its own project workstream.

Embedded analytics token differences. If your organization embeds SSRS reports in a web application using ReportViewer controls or direct SSRS iframe embedding, the embed method changes entirely in Power BI. Power BI uses the Embed for Your Customers or Embed for Your Organization model, requiring Azure AD service principals and Power BI Embedded licensing. Teams that have embedded SSRS reports in line-of-business apps often discover the embedding rewrite is its own project, separate from the report migration.

Custom .NET assemblies do not migrate. The Power BI cloud paginated runtime does not execute custom .NET assemblies. Any report that references an assembly reference must have those references rewritten as supported inline expressions before it can publish to the cloud. If your SSRS environment has 20 reports sharing a single utility assembly, each of those 20 reports needs its assembly references replaced.

Excel and PowerPoint export quirks. Excel export from Power BI paginated reports differs from SSRS Excel export in how it handles merged cells, multi-value parameters, and chart export. Users who rely on the exported Excel file structure — importing it into another system, for example — may find the Power BI export format breaks their downstream process. Test export behavior before declaring a report migrated.

Editorial Team field notes

Three observations from our 2026 migration audit work that do not appear in Microsoft’s documentation:

March 2026 — clean-conversion rates cluster at 55 to 65 percent on mixed enterprise portfolios. Across three client portfolios assessed in Q1 2026 (42, 67, and 88 reports respectively), Microsoft’s RDL Migration Tool produced clean-conversion rates of 62, 57, and 66 percent. The remaining reports required manual intervention — primarily shared data-source reconfiguration (all three portfolios) and expression fixes for unsupported function calls (two of three). Custom assembly rewrites accounted for 8 to 12 percent of total reports across all three engagements. Clean-conversion rates that appear in vendor marketing tend to reflect simple portfolios; real enterprise portfolios land lower.

February 2026 — the subscription rebuild line item is the most underestimated workstream. Of five migration projects where final cost exceeded initial estimate, four overran on subscription rebuild rather than report conversion. One client had 14 data-driven subscriptions serving regional sales teams with personalized filtered reports. Each required a Power Automate flow, a distribution-table query, a parameterized render call, and a PDF attach-and-email step. Total rebuild: 19 days for subscriptions alone. That work was not in the original project scope — the team had assumed subscriptions would transfer with the reports.

April 2026 — the PPU licensing cost delta should be in the business case, not the finance review. The $10/user/month gap between Pro ($14) and PPU ($24) surprises teams that assumed Pro covered paginated reports. For a 200-user organization, the annual delta is $24,000. We now flag licensing eligibility in the first week of every paginated migration engagement, before a single .rdl file is touched. If the organization cannot absorb the PPU cost, Path C (keep SSRS for paginated, modernize interactive separately) becomes the realistic answer.

Frequently asked questions

For cross-vendor pricing context and licensing model comparisons relevant to your Power BI capacity decision, see our BI Software Pricing 2026 guide. For the broader interactive-report migration track (converting SSRS reports to .pbix format), see our SSRS Migration Guide.

Last reviewed and updated: May 8, 2026