Publishing .rdl Files to Power BI - What Actually Works and What Still Bites

Most Australian enterprises I work with still have SQL Server Reporting Services running somewhere. Often it's hidden behind a "legacy reporting" label on the architecture diagram, with a note saying "to be retired". And it's been there for five years. Nobody wants to touch it because the .rdl files are doing actual business work, and the team that built them has moved on.

For a long time, the answer was "rebuild everything in Power BI from scratch". Then Microsoft quietly added the ability to publish .rdl files directly to the Power BI service. Suddenly you can move a paginated report from SSRS to the cloud without rewriting it. That changes the migration story. So this post is what I tell clients when they ask whether to bother. What works, what's still rough, and where I've seen it fall over on real projects.

The short version

You can publish .rdl files (paginated reports) to the Power BI service into a workspace backed by Premium capacity, a Fabric capacity, or a Premium Per User licence. Once published, the .rdl runs through the Power BI paginated reports engine, which is essentially the SSRS engine wearing a different jacket. Most reports work. Some don't. The ones that don't are usually broken in ways you can fix, if you know where to look.

You can do this from Power BI Report Builder (File > Publish), or from SQL Server Data Tools by changing the deployment target, or by uploading the .rdl through the Power BI service UI directly. The recommended path is Report Builder. It's the same tool you'd use to author paginated reports natively, and it understands the Power BI service as a deployment target out of the box.

Why bother in the first place

Three reasons keep coming up in client conversations.

First, on-prem SSRS is an operational burden that nobody wants to wear anymore. Patching, certificates, scaling. The list goes on. Moving the runtime to the Power BI service means somebody else handles all of that.

Second, your audience is moving. If your business has invested in Power BI for interactive analytics, end users are spending their time in the Power BI service. They don't want to keep a separate SSRS portal open to access invoice runs or compliance reports. Pulling everything into one home reduces the cognitive load.

Third, you can mix paginated and interactive. Once an .rdl is in the same workspace as your Power BI dashboards, you can add it to a Power BI App, set up subscriptions through the same UI, and let users drill from an interactive Power BI page through to a paginated detail report. That last pattern - high-level dashboard for browsing, paginated report for the printable detail - is genuinely useful, and you can't really do it cleanly if the paginated reports are stuck on SSRS.

We do a lot of work like this in our Microsoft Fabric and Power BI consulting, and the pattern of "land paginated reports into the service first, then modernise the data layer underneath" has become my default migration play.

What translates cleanly

Most of the standard paginated report features translate without trouble. Tables, matrices, lists, basic charts, expressions, parameters, page headers and footers, page breaks, drill-down within the report, and exports to Excel, PDF and Word all work. If your .rdl was built using the standard SSRS toolbox, you're probably going to have a quiet life.

Shared data sources need to be reconfigured to point at gateway-bound connections (or at cloud data sources directly), but that's not really a translation issue, just a connectivity setup. The actual report logic doesn't change.

What doesn't translate

This is the part you need to know before you commit.

Custom assemblies. If your .rdl files reference custom .NET assemblies (which a lot of older SSRS shops did to share business logic across reports), those don't work in the paginated reports service. You need to rewrite that logic as report-embedded code, or push it back into the data source layer (a view, a stored procedure, a tabular model measure). I've seen organisations where this kills the migration plan stone dead, because the custom assemblies have grown into a small framework over the years and nobody wants to unwind them. If you're in that boat, plan for real engineering work.

Document maps and some less-used SSRS features. Some niche layout features either don't render or render differently. Document maps are the one I hit most often.

Data source flexibility. SSRS lets you connect to almost anything, including some odd file-based or custom OLE DB providers. The paginated reports service supports a narrower list. Check the supported data source list before you commit to a migration. If your report sources data from a legacy provider that isn't supported, you'll need to land that data in a supported source first (Azure SQL, Synapse, Fabric Warehouse, Snowflake, etc.).

Subreports. Subreports work, but with some restrictions on data source sharing between the main report and the subreport. If your reports lean heavily on subreports, test them properly before declaring victory.

Performance for very large reports. I've seen paginated reports that rendered 5,000 pages on SSRS suddenly take much longer in the service. The render engine is similar but the resource boundaries on Premium are different. If you have an .rdl that produces a giant document, run it end to end on a representative dataset before committing to the cut-over.

A practical migration approach

The plan I tend to recommend, after watching a few of these go badly, looks like this.

Start with an inventory. Pull the list of all .rdl files in production. Tag each one with three things: who actually uses it (often nobody, by the way), what data source it hits, and whether it uses any custom assemblies. You will be surprised by how many reports nobody opens. We did this at a large Australian client last year and found that 60 percent of their .rdl estate hadn't been opened in 12 months. Those weren't migration candidates. They were deletion candidates.

Then pick the noisy ones. The reports run frequently, with high business value. Move those first. Validate that the rendered output matches the SSRS version, including page breaks, exported formats, and parameter behaviour. The reason to start with the noisy reports is that you build skill on the most important assets first, and the migration starts paying back almost immediately.

Then deal with the long tail. The infrequently used reports can be batched and migrated more cheaply, because by then you have a tested pattern. Anything that uses a custom assembly goes into a separate bucket that gets engineered properly.

Finally, decommission SSRS. Most organisations leave the SSRS server running far too long. Make a hard cut. If a report didn't make it across, that's a decision, not an accident.

Authentication and gateways

The on-prem data gateway is the bridge between the Power BI service and your on-prem data sources. If your .rdl files connect to an on-prem SQL Server or another internal system, you'll need a gateway configured for paginated reports. Most enterprise installs already have one for Power BI datasets, but it has to be enabled for paginated report data sources as well. That's a tickbox in the gateway settings. Tick it. We forget and then spend half a day wondering why a report works in Report Builder on the dev machine but fails in the service.

Authentication is mostly the same as you remember from SSRS, but with Azure AD on the front. If your reports use stored credentials for unattended runs (which most do), you'll set those up on the gateway. If your reports use single sign-on through Kerberos delegation, that still works on the gateway but requires a properly configured Kerberos setup. This is one of those areas where the documentation makes it sound easier than it actually is. Budget time.

Premium capacity and cost

You need Premium capacity, Fabric capacity, or PPU to run paginated reports in the service. PPU is the cheapest entry point for small teams, but it's a per-user licence and only covers users with PPU assigned. Premium and Fabric capacity is the typical enterprise path.

The right capacity SKU depends on volume. Paginated report rendering eats CPU. A single huge report rendering can spike a small capacity. We've sized for clients where the paginated workload turned out to be the dominant cost driver, even though the Power BI dataset workload looked bigger on paper. The fix is usually a separate capacity for paginated reports, or scaling up at peak times if it's predictable. Plan for this in your sizing model.

If you're already running Fabric, paginated reports are first-class citizens in the Fabric workspace model, which makes capacity assignment simpler than the old Premium per Workspace pattern. We do quite a bit of Fabric architecture work for Australian clients, and the paginated reports story has become more coherent with Fabric than it ever was on Premium alone.

My honest take

If you have an SSRS investment, this is a feature worth using. The translation isn't perfect, but the alternative (rewriting every paginated report as a Power BI report) is much more expensive and frankly the wrong tool for the job. Paginated reports exist because pixel-perfect printable reports are a real need. Power BI reports are not a substitute. So land your .rdl files in the service, and you can keep using them for what they were good at, while moving the runtime off your on-prem servers.

Just plan for the migration work properly. Don't promise leadership that you'll be off SSRS in three weeks. Inventory first, fix the data sources, deal with custom assemblies, validate output. The Microsoft documentation on publishing .rdl files to the Power BI service is a good starting point for the mechanics.

If you're staring down an SSRS retirement project and want a second pair of eyes on the plan, that's the kind of work our Microsoft consulting team does most weeks. Get in touch. The first conversation is always free, and most of the time we end up giving you a smaller plan than the one you were about to commit to.