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.
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 SSRS 2022 ends in 2028, which means no more feature updates, performance improvements, or non-security bug fixes after that date. Extended support — security patches only — runs until January 11, 2033. After that, your SSRS instance is unsupported software running against a SQL Server engine that has moved on without it. Every organization still running SSRS today has, at most, seven years to migrate. In practice, the real deadline is closer to two or three years, because running business-critical reporting on a platform receiving only security patches is a risk most IT governance frameworks will not tolerate.
The technical problem is not that migration is impossible. It is that migration is not a simple lift-and-shift. SSRS reports are defined in Report Definition Language (RDL), an XML-based format that describes layout, data sources, parameters, expressions, and rendering instructions. Power BI's native report format (.pbix) is a completely different architecture — it uses a tabular data model with DAX expressions, a drag-and-drop visual canvas, and an in-memory analytics engine (VertiPaq) that has nothing in common with the SQL-query-per-report execution model that SSRS uses. You cannot convert an RDL file into a .pbix file. They are fundamentally different paradigms. The migration path Microsoft provides is to upload RDL files as paginated reports in the Power BI service or Power BI Report Server. This preserves pixel-perfect layout and SQL-based data retrieval, but it does not give you any of the interactive, self-service analytics capabilities that are the entire point of moving to Power BI. Your reports look the same and work the same — they are just running on a different server.
For organizations with 50 to 500+ SSRS reports, the real migration challenge is triage. Some reports should stay as paginated RDL reports because they serve operational purposes that require exact-pixel formatting — invoices, packing slips, regulatory filings, print-ready documents. Some reports should be rebuilt as interactive Power BI reports because the business value comes from exploration, filtering, drill-through, and self-service access. Some reports should be retired entirely because they were built five years ago for a stakeholder who left the company and nobody uses them anymore. And some reports need to be consolidated — the 15 regional sales reports that are identical except for a parameter filter should become one report with a slicer. Without a systematic inventory and classification, migration projects either convert everything one-to-one (wasting money on reports nobody uses) or miss critical reports that someone in finance needs on the 15th of every month without fail.
The licensing complexity makes it worse. Paginated reports in the Power BI cloud service require Power BI Premium Per User ($24/user/month), a Fabric capacity SKU (F64 or higher, starting around $5,000/month for full Premium parity), or the legacy P1 Premium capacity ($4,995/month). Power BI Pro licenses at $14/user/month do not support paginated reports at all. If you have 200 users who currently access SSRS reports through a web browser at zero marginal cost (SSRS is included with your SQL Server license), your migration just introduced a recurring licensing expense that did not exist before. Power BI Report Server — the on-premises replacement — is included with SQL Server Enterprise Edition with Software Assurance, or with Power BI Premium. Either way, you need to model the licensing cost before you start migrating, because the architecture you choose (cloud, on-premises, or hybrid) is driven as much by licensing economics as by technical requirements.
SSRS 2022 is the final release — mainstream support ends 2028, extended support ends January 11, 2033, no future versions
SQL Server 2025 ships without SSRS — Power BI Report Server is now the only on-premises reporting option
RDL-to-PBIX conversion does not exist — reports must be either uploaded as paginated reports or rebuilt from scratch as interactive Power BI reports
No inventory discipline: organizations with 200–500+ SSRS reports have no systematic way to classify which reports to migrate, rebuild, consolidate, or retire
Licensing sticker shock: SSRS reports were 'free' under SQL Server licensing — Power BI paginated reports require Premium Per User ($24/user/mo) or Fabric capacity (F64+, ~$5K/mo)
Shared data sources and shared datasets are not natively supported when publishing RDL files to the Power BI service — each report needs embedded connections
Custom code and assemblies in RDL reports (VB.NET expressions, external DLLs) are blocked in the Power BI service for security reasons
SSRS subscriptions (email delivery, file share drops, SharePoint integration) do not have direct equivalents in Power BI and must be rebuilt using Power Automate or other tooling
Our engineers have built this exact solution for other businesses. Let's discuss your requirements.
FreedomDev has migrated SSRS estates ranging from 40 reports on a single report server to 800+ reports across multiple SSRS instances serving different business units. The methodology is the same regardless of scale: inventory every report, classify its migration path, execute the conversion or rebuild, validate output accuracy against the original, and cut over with zero disruption to report consumers. We work with IT Directors and BI teams who understand their business requirements but need a partner with deep SSRS and Power BI technical expertise to execute the migration without breaking the reporting workflows that the business depends on every day.
The core of our approach is a four-path classification model. Every SSRS report gets assigned to one of four migration paths based on its characteristics and business value. Path 1 is Paginated Lift — reports that need pixel-perfect layout for printing, export, or regulatory compliance are uploaded as paginated reports (.rdl) to Power BI Report Server or the Power BI service. These reports continue to use their existing SQL queries and stored procedures with minimal modification. The RDL format is fully compatible with both Power BI Report Server and paginated reports in the Power BI service (Premium required for cloud). Path 2 is Interactive Rebuild — reports whose primary value is data exploration, trend analysis, or self-service access are rebuilt as native Power BI .pbix reports with proper data models, DAX measures, and interactive visuals. This is the most labor-intensive path but delivers the most value, because interactive Power BI reports are dramatically more useful than static SSRS tables. Path 3 is Consolidation — clusters of reports that serve the same purpose with different parameters (regional variants, department-specific views, monthly vs. quarterly versions) are consolidated into single Power BI reports with slicers, bookmarks, and row-level security. Path 4 is Retirement — reports with no active consumers, no scheduled subscriptions, and no regulatory retention requirement are documented and archived. Across our migration projects, 15–25% of SSRS reports qualify for immediate retirement, which directly reduces migration scope and licensing costs.
For the paginated lift path, we handle the technical issues that Microsoft's documentation glosses over. Shared data sources must be converted to embedded data sources because the Power BI service does not support shared data source definitions. Shared datasets face the same limitation. Custom VB.NET code embedded in RDL expressions may need to be rewritten — the Power BI service restricts custom code execution for security. External assembly references (custom DLLs registered on the SSRS server) are not supported at all in the Power BI service and must be replaced with alternative logic or moved to a stored procedure. Report parameters that use cascading dropdowns populated by database queries work in Power BI Report Server but have nuances in the cloud service around default value handling and available value lists. Subreports work in paginated reports but add rendering overhead. Drillthrough reports need URL parameter mapping that differs from SSRS. None of these are dealbreakers, but every one of them is a potential migration failure point if you are not testing systematically.
We extract the full report catalog from your SSRS ReportServer database — every report, folder, data source, subscription, execution log entry, and cached snapshot. The ExecutionLog3 view gives us hard data on which reports are actually used, how often, by whom, with what parameters, and how long they take to render. Reports with zero executions in the last 12 months are immediate retirement candidates. Reports running on a daily subscription that nobody opens get flagged for review. This data-driven inventory eliminates the guesswork that causes migration projects to waste budget converting reports that should have been deleted.
For reports that must retain exact-pixel layout — invoices, packing slips, regulatory forms, print-ready documents — we migrate the RDL files to Power BI Report Server or the Power BI service as paginated reports. We handle shared-to-embedded data source conversion, parameter remapping, subreport dependency resolution, custom code replacement, and expression compatibility testing. Every migrated paginated report is validated against the original SSRS output using automated screenshot comparison and data-level assertions on key figures.
Reports whose value lies in data exploration — sales dashboards, KPI scorecards, trend analyses, pipeline views — are rebuilt as native Power BI .pbix reports. We do not simply recreate the same table layout in Power BI. We design proper star-schema data models in Power Query, write DAX measures for calculations that SSRS handled with SQL expressions, implement row-level security to replace SSRS role-based access, and build interactive visuals with drill-through, cross-filtering, and bookmarked views. The result is a report that does what the SSRS version could never do: let users answer their own follow-up questions.
The licensing decision determines your migration architecture. We model four scenarios for every client: (1) Power BI Report Server on-premises with SQL Server Enterprise SA — zero cloud cost, full RDL compatibility, limited interactive features. (2) Power BI Premium Per User at $24/user/month — per-user cost model, paginated reports included, suitable for under 300 users. (3) Fabric capacity (F64+) — flat-rate cost regardless of user count, full Premium feature set, AI and Copilot capabilities, scales to thousands of users. (4) Hybrid — Power BI Report Server for paginated/operational reports, Power BI service for interactive analytics. We present the 3-year TCO for each scenario against your user count and report mix.
SSRS subscriptions — email delivery of rendered reports, file share drops, SharePoint library publishing — do not have a one-to-one equivalent in Power BI. We replace SSRS subscriptions with Power BI subscription schedules (for Pro and Premium users), Power Automate flows for complex delivery logic (conditional sends, dynamic recipient lists, file share drops), and paginated report export APIs for programmatic PDF or Excel generation. Data-driven subscriptions that vary parameters per recipient are rebuilt using Power Automate with parameterized paginated report URLs.
For organizations that need to keep reports on-premises — data sovereignty requirements, air-gapped networks, or licensing economics that favor Software Assurance over cloud subscriptions — we deploy and configure Power BI Report Server as the SSRS replacement. Power BI Report Server runs both paginated RDL reports and interactive .pbix reports on your own infrastructure. We handle server sizing, Windows authentication configuration, SSL certificate binding, folder structure migration, role and permission mapping from SSRS, and integration with your existing SQL Server instances.
We had 340 SSRS reports across three report servers, and nobody knew which ones were still being used. FreedomDev's inventory audit identified 80 reports for immediate retirement, consolidated another 60 into 15 interactive Power BI dashboards, and migrated the remaining 200 as paginated reports — all in 16 weeks. Our finance team went from waiting 12 seconds for a report to render to getting instant drill-through in Power BI. The licensing model they recommended saved us $40,000 per year compared to the architecture our Microsoft partner originally proposed.
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.
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.
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).
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.
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.
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.
| Metric | With FreedomDev | Without |
|---|---|---|
| RDL Compatibility | Full — paginated lift, rebuild, or hybrid per report | DIY: bulk upload with no triage, custom code breaks silently |
| Report Inventory & Usage Audit | ExecutionLog3 analysis with data-driven path assignment | Manual spreadsheet, tribal knowledge, missed reports |
| Interactive Rebuild Quality | Star-schema models, DAX measures, RLS, drill-through | DIY: flat query dumps pasted into Power BI tables |
| Licensing Strategy | 3-year TCO model: PBIRS vs PPU vs Fabric vs hybrid | Discover costs after migration when invoices arrive |
| Subscription Replacement | Power Automate flows with parameterized delivery logic | Manual rebuild, data-driven subs often dropped entirely |
| Custom Code Handling | VB.NET expressions rewritten, assembly refs moved to stored procs | Reports with custom code flagged as 'unsupported' and abandoned |
| Parallel Validation Period | Automated comparison: screenshots + data assertions for every report | Spot-check a few reports, hope for the best |
| Timeline (200+ reports) | 12–20 weeks phased migration with zero downtime | 6–12 months of reactive troubleshooting |
Schedule a direct technical consultation with our senior architects.
Make your software work for you. Let's build a sensible solution.