Migrating .rdl Reports to Power BI - A Practical Guide for Australian Organisations

If you've been running SQL Server Reporting Services for any length of time, you probably have a library of .rdl reports that nobody wants to touch. Some of them are business-critical. Some haven't been opened in three years. And someone in leadership has just asked, "Can we move all this to Power BI?"

The answer is yes. But how you do it matters a lot more than whether you can.

Microsoft has published detailed guidance on migrating .rdl reports to Power BI, and it's genuinely useful. But documentation tends to describe the happy path. After working through several of these migrations with Australian organisations, I want to share what the process actually looks like when you're dealing with real report servers that have accumulated years of organic growth.

First Things First - What Are We Actually Moving?

When you migrate .rdl reports to Power BI, they become paginated reports. That naming matters because Power BI has two distinct report types. Standard Power BI reports are the interactive, visual ones most people think of. Paginated reports are the ones optimised for printing, PDF generation, and pixel-perfect formatting - invoices, compliance documents, regulatory filings, that sort of thing.

If your existing SSRS reports are mostly operational - things people print, export to PDF, or email on a schedule - paginated reports in Power BI are the right target. If the report is really an analytical dashboard that someone built in SSRS because that's all they had available, this migration might be a good opportunity to rebuild it as a proper interactive Power BI report instead.

We see organisations skip this assessment step and just bulk-migrate everything. That's a missed opportunity. Migration is the perfect time to ask whether each report should even exist in its current form.

The Four-Stage Approach

Microsoft breaks the migration into four stages, and honestly this structure works well. Here's how we approach each one.

Stage 1 - Before You Start

Licensing is the first gate. You need Power BI Pro or Premium Per User licences to publish paginated reports, and the reports themselves require Premium capacity or Premium Per User to render. This is a cost factor that catches organisations off guard. If you have 200 SSRS reports being consumed by 500 users who currently don't need Power BI licences, your licensing costs are about to change.

Get this sorted before you do anything else. We've seen migrations stall mid-way because nobody budgeted for the licensing change.

SSRS versions from 2012 through 2022 are all supported for migration, along with Power BI Report Server. If you're running something older than 2012, you've got bigger problems than migration and should probably talk to someone about your overall data platform strategy.

Stage 2 - Pre-Migration (Discover, Assess, Prepare)

This is where the real work happens, and it's the stage most organisations underinvest in.

Discovery means finding every report server instance in your environment. That sounds simple, but in large organisations, SSRS instances multiply. Someone in finance set one up five years ago. There's a test server that somehow became production. The merger brought in three more. Azure Migrate is a free tool that can scan your network and catalogue what's out there, and it's worth running even if you think you know your environment.

Assessment is about figuring out which reports can migrate cleanly and which ones will need work. The RDL Migration Tool automates a lot of this. It'll check for unsupported data sources, flag features that don't work in Power BI paginated reports yet, and convert shared data sources and datasets into embedded ones (since Power BI paginated reports need embedded data connections).

Here's what the tool won't tell you: whether the report is actually used. We regularly find that 30-50% of reports on an SSRS server haven't been opened in six months or more. Microsoft has a separate guide on finding and retiring unused reports, and I'd recommend running that process before you migrate anything. Why move dead reports to a new platform?

Some items genuinely can't migrate. KPIs, mobile reports, report models, and report parts are all either deprecated or have no Power BI equivalent. Resources like image files won't transfer either - you'll need to handle those manually. Linked reports do migrate, which is good, though they lose their "linked" nature and become standalone .rdl files.

Preparation means setting up the target environment. A few things we always address at this stage:

You'll need an on-premises data gateway if your reports connect to on-premises databases. Most SSRS environments connect to on-prem SQL Server, so this applies to nearly every migration we do. Get the gateway installed, configured, and tested before you start moving reports.

Security mapping takes time. SSRS has its own security model with role assignments at the folder and report level. Power BI uses workspaces, app audiences, and row-level security. These don't map one-to-one, and figuring out the right Power BI security model for your migrated reports requires thought about how your users actually access content.

Report scheduling and subscriptions need to be rebuilt. SSRS subscriptions are a whole system unto themselves - data-driven subscriptions, file share delivery, email delivery with specific rendering formats. Power BI has subscriptions too, but the feature set is different. Some organisations rely heavily on SSRS subscriptions to distribute PDFs via email on a schedule, and replicating that exactly in Power BI sometimes requires Power Automate flows to fill the gaps.

Stage 3 - Migration

For Power BI Report Server or SSRS 2017 and later, there's a built-in publish-to-Power-BI feature that handles the actual migration. For older versions, you'll use the RDL Migration Tool from GitHub.

The tool automates the mechanical work - converting shared resources to embedded ones and publishing the reports to a Power BI workspace. On completion, it gives you a summary of what succeeded and what failed. In our experience, the initial pass typically migrates 60-80% of reports successfully. The remaining ones need manual attention, usually because of unsupported data sources or custom code references.

Custom code DLLs are the biggest blocker we encounter. SSRS allows reports to reference custom .NET assemblies for complex calculations. Power BI paginated reports don't support this. If you have reports with custom code, you'll need to either rewrite that logic using built-in expressions, move it upstream into the database layer, or rebuild the report as a standard Power BI report where DAX can handle the calculations.

Font issues are the other common surprise. If your reports use fonts that don't include non-Latin character support, the PDF output can look different between SSRS and Power BI. Test the PDF rendering output on both platforms before you declare a report successfully migrated.

Stage 4 - Post-Migration

Don't decommission your SSRS servers the day after migration. Run both environments in parallel for a period - we typically recommend four to eight weeks. During this time, have report consumers compare output between the old and new versions. Paginated reports should produce identical results, but differences in rendering engines can cause subtle layout changes that matter when a report is used for compliance or financial purposes.

Set up a feedback channel so users can flag issues. You'll get reports like "the totals on page 3 are slightly different" and "the page break happens in a different spot." Most of these are cosmetic, but some will uncover legitimate data discrepancies that need fixing.

What We've Learned From Doing These Migrations

A few patterns from our Power BI consulting work that might save you time:

Migrate in batches, not all at once. Group reports by department or business function and migrate one group at a time. This keeps the scope manageable and lets you refine your process as you go. The first batch always takes longer than expected.

Involve report owners early. The people who actually use these reports know things the migration team doesn't - which reports are critical for month-end, which ones have quirky formatting requirements, which ones can be retired. Get them involved during assessment, not after migration.

Don't just lift and shift - evaluate and improve. Some reports that were built in SSRS because that was the only tool available would be much better served as interactive Power BI reports. A tabular report that users constantly filter and sort is begging to be rebuilt as an interactive dashboard. Use the migration as a chance to match each report to the right tool.

Plan for gateway maintenance. The on-premises data gateway becomes a critical piece of infrastructure once your paginated reports depend on it. Set up monitoring, configure high availability if the reports are business-critical, and make sure someone owns the gateway going forward. We've seen migrations succeed technically but create operational headaches because nobody thought about ongoing gateway management.

Is It Worth It?

For most organisations, yes. Running SSRS on-premises means maintaining servers, managing patches, handling backups, and dealing with an aging platform that Microsoft is clearly investing less in over time. Moving to Power BI puts your reports on a modern, cloud-managed platform with better sharing, better security integration, and a clearer product roadmap.

But don't underestimate the effort. A migration of 50+ reports is a genuine project that needs proper planning, testing, and change management. If your team doesn't have experience with this kind of migration, working with a consulting partner who knows both platforms can save you a lot of time and frustration.

If your organisation is also looking at broader data platform modernisation - moving to Microsoft Fabric, consolidating data warehouses, or building out self-service analytics - the SSRS migration often fits naturally as one workstream within that larger initiative. We help organisations plan and execute these kinds of programs through our data and analytics consulting services, and the SSRS migration is one of the most common starting points we see.

The reports aren't going to migrate themselves. But with decent planning and a realistic timeline, it's a very achievable project - and your users will thank you for it.