# SSRS to Power BI Migration: Report Server Migration Before 2033 EOL Microsoft made it official with SQL Server 2025: SQL Server Reporting Services is no longer a shipping component. SSRS 2022 is the last version that will ever be released. Mainstream support for SS... ## SSRS to Power BI Migration: Report Server Migration Before 2033 EOL SQL Server Reporting Services is dead. SSRS 2022 is the final release, extended support ends January 2033, and SQL Server 2025 already ships without it. If your organization runs hundreds of RDL reports on SSRS, the migration clock started the day Microsoft announced consolidation into Power BI Report Server. FreedomDev migrates enterprise SSRS estates — RDL conversion, data model refactoring, licensing strategy, and production cutover — for IT teams that cannot afford a failed migration or a surprise licensing bill. --- ## Our Process 1. **Report Estate Inventory & Usage Audit (1–2 Weeks)** — We connect to your SSRS ReportServer database and extract the complete report catalog: every RDL file, data source definition, shared dataset, subscription, execution history, and cache configuration. We query the ExecutionLog3 view to build a usage profile for every report — execution count, unique users, average render time, parameter patterns, and last accessed date. Reports are classified by usage frequency (daily, weekly, monthly, quarterly, dormant), output format (browser, PDF, Excel, CSV), consumer count, and business criticality. Deliverable: a full inventory spreadsheet with migration path recommendations (paginated lift, interactive rebuild, consolidation, or retirement) and a licensing cost model for your target architecture. 2. **Licensing & Architecture Decision (1 Week)** — Based on your report mix, user count, and infrastructure constraints, we present architecture options with 3-year total cost of ownership. We model Power BI Report Server on-premises (included with SQL Server Enterprise SA), Power BI Premium Per User ($24/user/month), Fabric capacity (F64 at approximately $5,000/month), and hybrid configurations. We factor in your current SQL Server licensing, Software Assurance status, existing Microsoft 365 subscriptions, and whether your organization has Azure credits or Enterprise Agreements that affect Fabric pricing. You choose the target architecture before we write a single line of migration code. 3. **Paginated Report Migration (2–6 Weeks)** — Reports assigned to the paginated lift path are migrated first because they require the least modification and serve the most time-sensitive business processes. We use Microsoft's RDL Migration Tool as a starting point, then handle the manual fixes it cannot automate: shared-to-embedded data source conversion, custom code replacement, assembly reference elimination, parameter default and available value adjustments, and subreport path remapping. Each migrated report is tested for visual accuracy (automated screenshot comparison against SSRS output), data accuracy (row-count and sum-total assertions on key columns), and parameter behavior (every parameter combination that appears in the execution logs). 4. **Interactive Report Rebuilds (4–12 Weeks)** — Reports assigned to the interactive rebuild path are redesigned as native Power BI .pbix files. This is not a cosmetic conversion — it is a data modeling exercise. We build Power Query datasets that replace the raw SQL queries SSRS reports relied on, design star-schema relationships that enable cross-filtering, write DAX measures for calculations that were previously done in SQL or RDL expressions, and implement row-level security to replace SSRS folder-based permissions. Each rebuild goes through stakeholder review to ensure the interactive version answers the same business questions as the original, plus the follow-up questions that SSRS could never handle. 5. **Subscription Replacement & Automation (1–3 Weeks)** — SSRS subscriptions are cataloged and rebuilt using Power BI native subscriptions, Power Automate flows, or scheduled paginated report exports via the Power BI REST API. Data-driven subscriptions that customize parameters per recipient are the most complex to replace — we build Power Automate flows that loop through a recipient table, generate parameterized paginated report URLs, render the report to PDF, and deliver via email or file share. Subscription testing validates that every original SSRS subscription recipient receives the same report, in the same format, on the same schedule, at the new destination. 6. **Parallel Running, Validation & Cutover (2–4 Weeks)** — Migrated reports run in parallel with the original SSRS reports for a validation period. Report consumers access both versions and confirm that data matches, formatting is acceptable, and interactive features work as designed. We run automated comparison scripts that pull key metrics from both the SSRS and Power BI versions of each report and flag discrepancies. Once validated, we execute a phased cutover — starting with low-risk reports and progressing to business-critical daily reports. SSRS is not decommissioned until every migrated report has been validated in production for at least two weeks with zero escalations. --- ## Frequently Asked Questions ### What is the actual SSRS end-of-life timeline, and how urgent is migration? SSRS 2022 is the final version Microsoft will ever release. Mainstream support for SSRS 2022 ends in 2028 — after that, no feature updates, performance fixes, or non-security patches. Extended support (security patches only) ends January 11, 2033. SQL Server 2025, released in late 2025, does not include SSRS at all — Power BI Report Server is the only on-premises reporting component. If you are running SSRS 2019, your timeline is shorter: mainstream support ended February 2025, and extended support ends in 2030. If you are running SSRS 2016 or 2017, you are already in extended support with end dates in 2026 and 2027 respectively. The practical urgency depends on your risk tolerance. Technically, SSRS 2022 will continue to function past 2033 — software does not stop working on its end-of-support date. But you will receive no security patches, your compliance auditors will flag it, your cyber insurance may not cover incidents on unsupported software, and Microsoft will not help you troubleshoot production issues. Most enterprises we work with target migration completion 12 to 24 months before their SSRS version's extended support end date. ### Can SSRS RDL reports be directly converted to Power BI .pbix reports? No. This is the single most misunderstood aspect of SSRS migration. RDL (Report Definition Language) and PBIX are fundamentally different architectures. RDL files define a paginated, pixel-perfect report layout with SQL queries that execute against a relational database at render time. PBIX files contain a compressed tabular data model (VertiPaq), DAX measures, and a visual canvas with interactive elements. There is no conversion tool that transforms one into the other because the underlying paradigm is different — not just the file format. What you can do is upload RDL files to the Power BI service or Power BI Report Server as paginated reports. Paginated reports in Power BI render RDL files using the same engine SSRS uses (the Report Viewer runtime). Your reports look the same, behave the same, and use the same SQL queries. This is a valid migration path for operational reports that need exact formatting — invoices, regulatory filings, print-ready documents. But if you want interactive dashboards with cross-filtering, drill-through, and self-service analytics, those reports must be rebuilt as .pbix files from scratch, with new data models and new DAX logic. Microsoft provides an RDL Migration Tool (open source on GitHub) that helps with the paginated upload path — it checks for unsupported features, converts shared data sources to embedded ones, and publishes RDL files to Power BI Premium workspaces. It does not convert RDL to PBIX. ### What Power BI licensing do we need for paginated reports? Paginated reports are not available on Power BI Pro licenses ($14/user/month). You have four licensing options for paginated reports. Option 1: Power BI Premium Per User (PPU) at $24/user/month — every user who views a paginated report needs a PPU license. This is cost-effective under roughly 250 to 300 users; above that, capacity licensing is cheaper. Option 2: Fabric capacity at F64 or above — F64 runs approximately $5,000/month and provides full Power BI Premium feature parity including paginated reports, with unlimited viewers (viewers still need a free Power BI account). F SKUs below F64 (F2 through F32) do not support paginated reports. Option 3: Legacy Power BI Premium P1 capacity at $4,995/month — provides the same capabilities as F64 but Microsoft is steering new customers toward Fabric SKUs instead. P-SKU retirement is underway. Option 4: Power BI Report Server on-premises — included at no additional cloud cost with SQL Server Enterprise Edition with active Software Assurance, or included with any Power BI Premium capacity subscription. This is the lowest-cost option for organizations that already have SQL Server Enterprise SA and do not need cloud-based report sharing. The right choice depends on your user count, your existing Microsoft licensing agreements, whether you need cloud access, and whether your organization has Azure Enterprise Agreement credits that reduce Fabric pricing. ### What is Power BI Report Server, and is it a real SSRS replacement? Power BI Report Server (PBIRS) is Microsoft's on-premises reporting platform that replaces SSRS starting with SQL Server 2025. It runs on your own Windows Server, connects to your own SQL Server databases, and serves reports through a web portal that is nearly identical to the SSRS Report Manager interface your users already know. PBIRS supports two report types: paginated reports (.rdl files — the same format SSRS uses) and interactive Power BI reports (.pbix files). Your existing SSRS RDL reports can be deployed directly to PBIRS with minimal to no modification. PBIRS is included with SQL Server Enterprise Edition with Software Assurance or with Power BI Premium capacity subscriptions. It is a real replacement in the sense that it runs the same RDL rendering engine, supports the same data source types, handles subscriptions and caching, and integrates with Windows Authentication. The limitations compared to the Power BI cloud service are: no AI or Copilot features, no real-time streaming datasets, no Fabric integration, no dataflows or datamarts, limited collaboration features (no commenting, no workspace sharing in the cloud sense), and update cadence is three releases per year versus continuous deployment in the cloud service. For organizations whose primary need is running existing SSRS reports on supported infrastructure with the option to gradually introduce interactive Power BI reports, PBIRS is the simplest and cheapest migration path. ### What happens to SSRS subscriptions when we migrate to Power BI? SSRS subscriptions — standard subscriptions that email a rendered report on a schedule, and data-driven subscriptions that dynamically determine recipients and parameters from a database query — do not migrate automatically to Power BI. They must be rebuilt. Power BI's native subscription feature supports email delivery of report snapshots to licensed users on a daily, weekly, or monthly schedule. It covers the most common SSRS subscription scenario but has limitations: recipients must have Power BI licenses, the subscription renders the report with default parameters (no per-recipient parameter variation), and file share delivery is not supported natively. For SSRS data-driven subscriptions that vary parameters per recipient — for example, emailing each regional manager their region-specific report — you need Power Automate. We build Power Automate flows that query your recipient table, call the Power BI paginated report export API with the appropriate parameters for each recipient, render the report to PDF or Excel, and deliver it via email or save it to SharePoint or a network file share. For SSRS subscriptions that drop files to a shared folder for downstream processing (ETL pickup, print queues, archival systems), we build scheduled Power Automate or Azure Logic App workflows that export paginated reports via the REST API and deposit files in the target location. The subscription rebuild is one of the most underestimated workstreams in SSRS migration — we typically allocate 1 to 3 weeks depending on subscription count and complexity. ### How do you handle SSRS reports with custom VB.NET code or external assemblies? SSRS supports two types of custom code that create migration challenges. Embedded VB.NET code (written directly in the report's Code section in Report Designer) and external assembly references (custom .NET DLLs registered on the SSRS server and called from RDL expressions). In the Power BI service, embedded custom code is restricted — Power BI paginated reports allow a subset of VB.NET expressions but block anything that accesses the file system, network, or external resources. External assembly references are not supported at all in the Power BI cloud service for security sandboxing reasons. Power BI Report Server (on-premises) has fewer restrictions and may support custom assemblies depending on configuration, but Microsoft discourages this for forward compatibility. Our approach to custom code migration depends on what the code actually does. Simple formatting functions (custom date formats, string manipulation, conditional formatting logic) are rewritten using built-in RDL expression functions or moved to SQL computed columns. Complex business logic (multi-step calculations, lookup tables, conditional aggregation) is moved into SQL Server stored procedures or views so the report consumes pre-calculated values instead of computing them at render time. Assembly references that call external services or perform file operations are replaced with pre-processing steps — a SQL Server Agent job or Power Automate flow that runs before the report renders and stages the data the report needs. In every case, we test the refactored report against the original SSRS output to verify that the numbers match exactly. ### How long does an SSRS migration take for an enterprise with 200 to 500 reports? A migration of 200 to 500 SSRS reports typically takes 12 to 20 weeks from kickoff to SSRS decommission, broken into overlapping phases. Weeks 1 to 2: inventory and usage audit — extract report catalog, analyze execution logs, classify every report into a migration path. Week 3: licensing and architecture decision — finalize target platform (PBIRS, Power BI service, or hybrid) and licensing model. Weeks 3 to 8: paginated report migration — convert and validate the reports staying in RDL format. This is the fastest workstream because the reports require the least modification. Weeks 4 to 16: interactive report rebuilds — redesign high-value reports as .pbix files with proper data models. This is the longest workstream and runs in parallel with paginated migration. Weeks 10 to 14: subscription replacement — rebuild SSRS subscriptions in Power BI and Power Automate. Weeks 14 to 20: parallel running and phased cutover — both systems run simultaneously, consumers validate, and SSRS is decommissioned only after all reports are confirmed in production. The biggest variable is the interactive rebuild count. If 80% of your reports are paginated lifts and only 20% need interactive rebuilds, the project compresses to 12 to 14 weeks. If 50% need interactive rebuilds with complex data model design, expect 18 to 20 weeks. Report complexity also matters — an SSRS report with 3 subreports, 8 parameters, custom code, and a 200-line stored procedure takes 3 to 5 days to rebuild as an interactive Power BI report. A simple tabular report takes half a day. ### What is the cost difference between staying on SSRS and migrating to Power BI? The cost of staying on SSRS through 2033 is deceptively low in direct spend but accumulates in hidden costs and risk. Your SQL Server license includes SSRS at no additional cost, and the software will continue to function past its support end date. However, the real costs of staying are: inability to hire or retain BI developers who want to work on a deprecated platform, zero new features or performance improvements after 2028, increasing incompatibility with newer SQL Server features and data sources, compliance and audit risk from running unsupported software, no Microsoft support for production issues, and the inevitability that you will eventually migrate anyway — but with more urgency, less institutional knowledge, and fewer available consultants who remember SSRS internals. Migration costs depend on report count, complexity, and target architecture. For a 200-report estate, expect $80,000 to $150,000 for a full migration (inventory, paginated lifts, interactive rebuilds, subscription replacement, validation, and cutover). For 500+ reports, $150,000 to $300,000. Ongoing Power BI licensing adds $24/user/month (PPU) or $5,000+/month (Fabric capacity) on top of migration costs. Against that, factor in the value of self-service analytics (reduced report request backlog for IT), faster report performance (seconds versus 8 to 15 second SSRS renders), a modern platform that attracts BI talent, and the elimination of technical debt on a dead platform. Most organizations we work with find that the break-even point on migration investment — factoring in IT labor savings from self-service adoption — is 18 to 24 months. --- **Canonical URL**: https://freedomdev.com/solutions/ssrs-to-power-bi-migration _Last updated: 2026-05-12_