Can you publish SSRS .rdl reports directly to Power BI?
Yes. Microsoft added native support for publishing .rdl paginated reports directly to the Power BI service. This means most businesses can move SSRS reports to the cloud without rewriting them. The report runs through Power BI's paginated reports engine, which is built on the same core as SSRS.
Publishing requires a workspace backed by Premium capacity, Fabric capacity, or a Premium Per User licence. The recommended tool is Power BI Report Builder. Use File > Publish to deploy directly to the service. You can also upload the .rdl file through the Power BI service UI or deploy via SQL Server Data Tools by changing the deployment target.
Power BI Report Builder: The primary publishing tool. It targets the Power BI service natively and handles paginated report deployment without additional configuration.
Power BI service UI upload: Upload .rdl files directly through the browser into any Premium or Fabric-backed workspace.
SQL Server Data Tools: Change the deployment target from an SSRS server to the Power BI service to publish without leaving the existing SSRS authoring environment.
Why move SSRS reports into Power BI at all?
Running on-premises SSRS means your team owns patching, SSL certificates, server scaling, and uptime. Moving the runtime to the Power BI service shifts that operational burden entirely to Microsoft. For most mid-market businesses, that alone justifies the migration.
If your business has already invested in Power BI for interactive reporting, users are living in the Power BI service daily. Keeping a separate SSRS portal open for invoice runs and compliance reports creates unnecessary friction. Consolidating everything into a single Power BI App removes that split.
The most valuable pattern is combining paginated and interactive reports in the same workspace. Users browse high-level dashboards built in Power BI Desktop, then drill through to a paginated .rdl report for the printable, pixel-perfect detail. This pattern is not practical when paginated reports are isolated on SSRS.
What translates cleanly when publishing .rdl files to Power BI?
Standard paginated report has transfer without issues. Tables, matrices, lists, basic charts, expressions, parameters, page headers and footers, page breaks, drill-down, and exports to Excel, PDF, and Word all work as expected in the Power BI service.
Shared data sources need to be reconfigured to point at gateway-bound connections or supported cloud sources. This is a connectivity setup task, not a report logic problem. The actual expressions, calculations, and layout inside the .rdl file do not change.
Tables and matrices: Render correctly in the Power BI paginated reports engine with no modification required.
Parameters: Parameter prompts and cascading parameters work the same as in SSRS.
Export formats: Excel, PDF, and Word exports all function correctly, which is critical for finance and compliance teams who print or distribute reports.
Power BI App integration: Published .rdl reports can be added to a Power BI App alongside interactive dashboards, giving users a single access point for all reports.
What breaks or causes problems when migrating .rdl files to Power BI?
Custom .NET assemblies are the most common migration stopper. Many older SSRS environments referenced custom assemblies to share business logic across reports. The Power BI paginated reports service does not support external assemblies. That logic must be rewritten as embedded report code or pushed into the data layer as stored procedures, views, or tabular model measures. For organisations where custom assemblies have grown into a shared framework over years, this represents significant engineering work.
Data source compatibility is the second major constraint. SSRS connects to a wide range of sources including legacy OLE DB and file-based providers. The Power BI service supports a defined list: Azure SQL Database, Synapse Analytics, Microsoft Fabric Warehouse, Snowflake, and other approved cloud sources. If your .rdl pulls from an unsupported provider, that data must be landed into a supported source before the report can be migrated.
Performance on very large reports can degrade. An .rdl that rendered 5,000 pages quickly on SSRS may take significantly longer on Premium capacity due to different resource boundaries in the cloud environment. Run every large report end to end against a representative dataset before committing to the cut-over.
Custom .NET assemblies: Not supported in the Power BI paginated reports engine. Business logic must be moved into stored procedures, views, or DAX measures before migration.
Document maps: This navigation feature either does not render or renders differently in the service. Test any reports that rely on document maps before signing off on the migration.
Unsupported data sources: Legacy OLE DB or file-based providers are not supported. Data must be moved to Azure SQL, Fabric Warehouse, Snowflake, or another approved source first.
Subreports: Subreports work but have restrictions on data source sharing between the main report and the subreport. Test thoroughly before declaring these complete.
Very large reports: Reports producing hundreds or thousands of pages may experience longer render times due to different resource limits on Premium capacity compared to on-premises SSRS.
How should mid-market businesses structure an SSRS to Power BI migration?
Start with a full inventory of every .rdl file currently in production. Tag each report with three data points: how often it runs, who uses it, and whether it contains custom assemblies or unsupported data sources. This triage separates the straightforward migrations from the ones that need engineering work before any publishing begins.
Kernel Flow recommends a phased approach. Publish the clean reports first to establish the Power BI workspace structure, validate connectivity through the on-premises data gateway, and confirm that subscriptions and exports work correctly for end users. Once that baseline is stable, address the complex reports that need data source remediation or assembly logic rewrites.
The most effective migration pattern is to land paginated reports into the Power BI service first, then modernise the data layer underneath over time. This keeps business operations running without interruption while the team progressively moves data from legacy SQL Server sources into Azure SQL Database, Fabric Warehouse, or Synapse Analytics.
Inventory and triage: Catalogue all .rdl files in production and flag those with custom assemblies or unsupported data sources before beginning any migration work.
Gateway setup first: Configure the on-premises data gateway and validate all data source connections before publishing a single report. Connectivity failures are the most common cause of early migration delays.
Publish clean reports first: Move straightforward reports into the Power BI service to establish the workspace structure and validate the publishing pipeline before tackling complex reports.
Remediate complex reports: Rewrite custom assembly logic into stored procedures or DAX measures and migrate unsupported data sources to Azure SQL or Fabric Warehouse as a separate workstream.
Validate performance under load: Run large reports against full production datasets on Premium capacity before cutting over to confirm render times meet business requirements.