SSRS to Power BI Migration: A Decision Framework

Quick Summary:

This guide explains how to run an SSRS to Power BI migration when a report host is being retired. Instead of a blanket SSRS vs Power BI verdict, it shows how to score every report on usage and pixel-perfect need, then sort each one into migrate, convert, or retire – turning a months-long platform debate into a weeks-long sorting exercise.

What an SSRS to Power BI Migration Really Involves

When an SSRS to Power BI migration becomes necessary because an SSRS host is nearing retirement, leadership often asks whether to move every report to the cloud. The honest answer is usually “not everything.” That was the exact situation a manufacturing client brought to our team: roughly 200 SSRS reports on an aging Windows Server host with a fixed decommission date, and no agreement on what should happen to them.

Some were pixel-perfect financial statements; others were operational summaries nobody had opened in months. Leadership wanted a single verdict – migrate all, modernize some, or replace with dashboards – but no one answer could fit an estate this mixed. An SSRS to Power BI migration has to reckon with reports that differ from each other more than the two platforms do.

Power BI Paginated Reports is the cloud-hosted equivalent of SSRS, embedded inside the Power BI service and built on the same Report Definition Language (.rdl) format. Because the format is shared, migration for many reports means publish-and-test rather than rebuild. But that only holds for the reports that genuinely need a paginated surface – and most estates contain far fewer of those than teams assume.

SSRS vs Power BI: Why Migrating Every Report Is the Wrong Default

The generic SSRS vs Power BI debate treats the choice as one tool replacing the other, but a real estate contains reports that belong on different surfaces. Our inventory and consumer audit of the full estate surfaced four constraints that reshaped the plan.

Around sixty reports had not been opened in six months. These were retirement candidates, not migration work. About forty were complex pixel-perfect financial statements, where SSRS or Power BI Paginated Reports were the only viable surfaces. The remaining hundred or so were simpler reports that mapped naturally to interactive Power BI dashboards. And the client already held a Premium Per User (PPU) license, so paginated reports in the cloud carried no incremental licensing cost.

Together, those constraints kill the “migrate everything” instinct. Reports nobody opens are reporting’s version of technical debt, and lifting the whole estate wastes effort on them, while leaving the dashboard candidates trapped in a static format that hides half their value. The estate had to be split three ways in proportion – not routed to one destination.

Cloud or On-Premises? Choosing Your Power BI Migration Target

Before sorting individual reports, decide where they are going, because SSRS migrates to two different destinations and the mechanics differ. This client chose the cloud path on the strength of its existing PPU license, but the framework works for either target.

For a cloud target, standard .rdl files become Power BI Paginated Reports in your tenant. You can publish them with the built-in Publish .rdl files feature in the Power BI portal, or – for older SSRS versions and bulk moves – use Microsoft’s open-source RDL Migration Tool, published on GitHub, to assess reports for unsupported features and publish them in bulk. The feature-level gaps to plan for – shared datasets, subscriptions, security mapping – are covered further below.

For an on-premises target, when compliance or data-residency rules out the cloud, the destination is Power BI Report Server (PBIRS) – the platform Microsoft is consolidating on-premises reporting into from SQL Server 2025 onward. The report server migration is essentially a database move: back up the SSRS encryption keys in Report Server Configuration Manager, back up the ReportServer and ReportServerTempDB databases in SQL Server Management Studio, restore both onto the target instance, then install PBIRS and point its configuration manager at the restored databases.

Choosing the target first prevents wasted work, because a report assessed for the cloud path is checked against different feature limits than one bound for PBIRS.

Which SSRS Reports Should You Migrate, Convert, or Retire?

The sorting logic is a two-axis grid. We score every report on two criteria: usage (last-opened date and monthly view count) and pixel-perfect requirements, such as complex headers or footers, exact pagination, or government-form layouts. Those two axes produce four quadrants and one clear action per report.

When to Use Paginated Reports vs Power BI Dashboards

Use Power BI Paginated Reports when a report must be pixel-perfect – invoices, statutory filings, or financial statements where exact layout and pagination are the point. Use interactive Power BI dashboards when the value is in exploration – slicing, cross-filtering, and following a question wherever it leads. The grid below turns that rule into a per-report action.

Before committing, we weighed three whole-estate strategies so the trade-offs were explicit rather than assumed.

The hybrid path matched effort to value, which is why it won.

Why this works: the grid forces a decision per report against evidence you already have – a view count and a layout requirement – so no report gets migrated on sentiment, and the estate shrinks before any build work starts.

How Do You Migrate Pixel-Perfect SSRS Reports to Paginated Reports?

For the pixel-perfect reports, we published the existing .rdl files directly to Power BI Paginated Reports using Power BI Report Builder. Because SSRS and Paginated Reports share the .rdl format, stored-procedure data sources, parameters, and expressions transferred largely unchanged.

Why this works: the .rdl definition is portable across both engines, so a migrated report keeps its query, parameter bindings, grouping, and pagination logic intact. The work becomes test-and-fix – verify data sources and reconcile output – rather than a rewrite.

How Do You Convert an SSRS Report into a Power BI Dashboard?

For the dashboard candidates, we rebuilt each in Power BI Desktop as an interactive report with slicers, cross-filtering, and on-canvas exploration the static SSRS originals could never offer. There is no file conversion here: a .rdl does not become a .pbix. The report is redesigned from scratch against a new semantic model. This was the slowest track but delivered the biggest visible gain, because an interactive surface answers questions a static page cannot.

Why this works:the same business logic that lived in an SSRS expression becomes a reusable DAX measure, so conversion preserves the number while unlocking slicing, cross-filtering, and ad-hoc exploration against a shared model.

The third track needed no build work at all. The unused reports retired behind a 30-day archival window, with stakeholder sign-off before anything was removed.

How Do You Rebuild SSRS Queries as a Power BI Data Model?

This is the step teams most often skip, and it is why converted dashboards underperform. SSRS pushes the work down into the database: a stored procedure returns a flat, pre-shaped result set, and the report simply prints it. Power BI expects the opposite. It wants a star schema – dimension tables for filtering and grouping, fact tables for summarizing – because every visual generates a query against that model.

Rebuilding therefore runs in three moves. First, the flat result set is decomposed into facts and dimensions. Second, the shaping logic that lived in T-SQL moves into Power Query, which is how a semantic model imports and transforms its source data. Third, any calculation the stored procedure performed inline – running totals, variances, prior-period comparisons – is rewritten as an explicit DAX measure, evaluated at query time rather than baked into the result.

Security follows the same pattern. SSRS restricts access by folder; Power BI resolves it inside the model, with row-level security rules written as DAX expressions that filter rows per user. Once the model is right, distribution is straightforward: publish to a workspace, then package the reports into a Power BI app for the people who only need to consume them.

If your SSRS estate is mixed and a host retirement is approaching, our team inventories, scores, migrates, and validates your reports, helping you build a defensible migration plan in weeks. You can start that conversation at scriptshub.net/contact-us.

What Migrates Cleanly from SSRS to Power BI – and What Doesn’t?

Most .rdl reports publish to Power BI Paginated Reports unchanged. Knowing the exceptions before you start is what prevents mid-migration surprises.

What doesn’t carry over. Power BI does not support shared data sources or shared datasets, so you must recreate SSRS-style .rds and .rsd files as embedded data sources or use a Power BI semantic model instead. Power BI also does not support custom code assemblies, so you must rewrite their logic as embedded code. Document maps stop rendering in the service, although they still appear on export. Data-driven subscriptions are unavailable, so recipient-specific delivery moves to Power Automate flows.

What survives intact. Subreports carry over when the parent and every subreport publish to the same workspace, nesting up to twenty levels deep. Drillthrough between paginated reports survives under the same workspace rule, with one catch: those links stop being selectable once a report is exported to PDF. Stored procedures with parameters transfer through the on-premises data gateway, and embedded expressions run unchanged.

Security is the one item that translates rather than transfers. Folder- and item-level SSRS permissions map to Power BI workspace roles – Admin, Member, Contributor, and Viewer – and row-level security (RLS) handles per-user filtering inside a report.

Why this matters: these gaps fail in two different ways. Unsupported features fail loudly – the service rejects the upload with an error, so you find them the moment you publish. Others fail quietly at render time, the way a document map simply stops appearing while the report still looks fine. Catalog both during inventory, not after cutover. On this engagement, fewer than a quarter of the pixel-perfect reports touched one of these features, and every one was flagged before publishing.

How Do You Validate an SSRS to Power BI Migration?

Trust comes from reconciliation against the legacy output, so we validated three things per report. Functional parity – every parameter, expression, and group on a migrated paginated report matched the SSRS original. User acceptance – stakeholders confirmed each converted dashboard answered the same questions. Distribution continuity -subscriptions, scheduled email exports, and Excel exports kept working without intervention.

We also tested two failure modes. Publishing one Paginated Report against the wrong data source made row counts diverge. The parity check caught the issue within hours. Disabling scheduled subscriptions on a handful of reports confirmed the client noticed within one business day. The monitoring was live, not theoretical.

What Results Did the Migration Framework Deliver?

The SSRS host retired on schedule. Every pixel-perfect report moved to Power BI Paginated Reports with full parity. Users opened roughly a third of the converted dashboards more frequently than their SSRS originals because the interactive surface unlocked new questions. The unused reports retired, freeing an estimated fourteen hours per month of previously hidden maintenance. Paginated reports ran under the existing PPU licenses at no incremental fee.

The engagement ran about two months across a small analyst-and-developer team. Our team has since applied the same framework to similar reporting estates across multiple client engagements.

The SSRS to Power BI Migration Workflow

This is the repeatable workflow our team runs on every evaluation.

Step 1 – Inventory every report. Pull a complete list with last-opened date, monthly view count, and consumer list, and flag near-duplicate reports that differ only by a hardcoded parameter. The inventory is the only honest input to the decision.

Step 2 – Score usage, pixel-perfect need, and complexity. The first two scores place each report into one of the four quadrants. The third – custom code assemblies, deeply nested expressions, long subreport chains – sets the real effort estimate.

Step 3 – Retire dead reports first. Reports unused in six months retire behind a 30-day archive window. This single step often removes 25-40% of the estate before any migration work begins.

Step 4 – Migrate pixel-perfect reports as Paginated. Publish .rdl files directly to Power BI Paginated Reports. The work is test-and-fix, not rebuild.

Step 5 – Convert dashboard candidates to interactive Power BI. Rebuild in Power BI Desktop against a star-schema semantic model, moving shaping logic into Power Query and calculations into DAX measures. This is a redesign, not a conversion.

Step 6 – Preserve subscriptions and exports. Migrate scheduled deliveries alongside reports so stakeholders never feel the platform change in their inbox.

Step 7 – Validate parity per report. Every migrated paginated report reconciles against its SSRS original; every converted dashboard gets stakeholder sign-off before cutover.

Step 8 – Retire SSRS after a quiet week. Keep the host running but unrouted for at least seven days post-cutover, then decommission once no complaint arrives.

The Power BI Paginated Reports documentation and Microsoft’s plan to migrate .rdl reports guidance shaped the migration mechanics throughout.

Bottom Line

An SSRS to Power BI migration is rarely a binary choice. Pixel-perfect reports belong on Paginated. Interactive candidates belong on Power BI dashboards. Unused reports belong in an archive. Score the estate report by report and the decision resolves in weeks rather than months – with a plan you can defend to leadership.

If your SSRS estate is mixed and a host retirement is approaching, our team helps run these evaluations and execute the migration end to end. Talk to ScriptsHub Technologies at scriptshub.net/contact-us or follow our work on LinkedIn.

Frequently Asked Questions (FAQ)

Q1: How do you approach an SSRS to Power BI migration?

Start with a full inventory, then score every report on usage and pixel-perfect need. Migrate pixel-perfect reports as Paginated, convert the rest to interactive Power BI, and retire whatever nobody opens.

Q2: Does Power BI replace SSRS?

No, not entirely. Power BI Paginated Reports covers pixel-perfect needs while interactive dashboards replace exploratory reports. Most estates run a hybrid, moving each report to whichever surface fits it best.

Q3: Can I migrate SSRS reports without rewriting them?

Yes, for pixel-perfect reports. The .rdl format publishes to Power BI Paginated Reports with minimal change, and stored-procedure data sources, parameters, and expressions usually transfer unchanged.

Q4: What licensing does Power BI Paginated Reports need?

Use a Power BI Pro or Premium Per User license. A Power BI Pro license includes paginated reports, so you don’t need Premium capacity. A free license publishes only to My Workspace, and viewers need Pro or PPU outside F64 capacity.

Q5: How long does an SSRS to Power BI migration take?

Because effort scales with dashboard conversions, a mid-sized estate of 150 to 250 reports typically takes eight to twelve weeks. Paginated-only migrations are faster; estates with many dashboard candidates take longer since conversion is not mechanical.