SSRS Alternative: Reporting Services Has Had Its Last Release
Microsoft has confirmed no new versions of SQL Server Reporting Services will ever ship. The replacement needs a SQL Server 2025 licence or active Software Assurance, and pulls you toward per-user Power BI licensing. DataPallas is the modern, open-source, self-hosted, fairly priced option — licensed for the people who build reports, not per reader.
Microsoft Has Said It Plainly
From Microsoft's own Reporting Services consolidation FAQ:
"No new versions of SQL Server Reporting Services (SSRS) will be released."
Starting with SQL Server 2025, on-premises reporting is consolidated under Power BI Report Server. SSRS 2022 was the last one there will ever be. It receives some security updates, and then nothing else. No new features. No new versions. Ever.
The product line is finished. Every year you keep building on it is a year invested in something Microsoft has stopped developing, and every report you add in the meantime is one more thing to move later.
The Bigger Problem: The Free Reporting Server Is Over
This is the part that decides it for most organisations, and it is in the licensing paragraph rather than the announcement.
Power BI Report Server is available to customers running SQL Server 2025 Enterprise and Standard editions. For SQL Server 2022 and earlier, PBIRS usage rights apply only to Enterprise edition core licences with active Software Assurance, and that right expires when your SA coverage expires. Installing it requires a key from SQL Server 2025 or later.
For twenty years, SSRS was the reporting server that came in the box with SQL Server. The replacement comes with a version upgrade and an edition requirement. If you run SQL Server Standard without Software Assurance — which is a great many organisations — your path to the successor is a SQL Server 2025 purchase.
Work out what that actually costs. Enterprise edition is sold in two-core packs at about $15,123 each, and Microsoft will not licence a server for fewer than eight cores — which puts the floor for one machine past $60,000, and doubles it the moment you want a standby node or a test environment. Standard edition is considerably cheaper and does now carry PBIRS rights, so it is the sensible route for most.
Either way, notice what has happened. To carry on doing something you were already doing, you are now buying a database licence you did not previously need. Reporting used to be a line item that did not exist. That is the change, and it is bigger than any single price.
And past that, the gravity of the product line pulls one direction: Power BI, then Fabric. Per-user licensing, cloud-first by design. That may be exactly where you want to go. If it is not, this is the moment to notice, because the decision gets harder to reverse the further in you go.
And Paginated Reporting Was Always the Awkward Child
Ask anyone who has tried to move an SSRS estate forward inside the Microsoft stack and the same frustrations come back.
Report Builder is a downgrade if you came from Visual Studio. Developers who built reports in SSDT find it limiting, and the Power BI Report Builder story still does not carry across everything SSRS could do.
Power BI Desktop is the wrong shape for paginated work. If your report is pages of rows and columns — a statement, an invoice run, a regulatory return — Power BI Desktop handles it badly and printing is a recurring problem. Paginated reporting inside Power BI exists, but it has never been the part Microsoft is excited about.
Data-driven subscriptions are Enterprise-only. This is the one that has cost most teams the most time. The subscriptions that actually burst a report per recipient from a query have always required Enterprise edition. Standard-edition shops worked around it with a scheduled job, a PowerShell script, and an SMTP call — and that script is now load-bearing infrastructure that one person understands and nobody wants to touch.
And SSRS has looked and felt the same for well over a decade. Report Manager is a folder tree. The rendering is dated. None of that was going to improve even before Microsoft confirmed it never would.
What DataPallas Does Instead
The whole chain lives in one product — you look at the data, build the report, get it to the people who need it, give them somewhere to collect it, and put interactive charts wherever they belong. Open source, self-hosted on your own servers, reaching any database over JDBC, and as comfortable on Linux as on Windows or macOS.
No edition tiers. No Software Assurance. No per-user analytics licence. No Fabric capacity. DataPallas is open source with fair commercial pricing, sized by the people who build and administer the reports rather than by the people who read them. Readers are not a licensed tier, so no edition of anything has to be bought in order to let somebody see a number.
Bursting Is the Product, Not an Edition Feature
Here, bursting is the whole point of the product rather than a line on a feature matrix. Give it a report and a column to divide on — employee, customer, branch, cost centre — and each resulting document goes out by email, FTP/SFTP, cloud storage, HTTP/WebDAV, or into a portal. It runs unattended, retries what fails, and checks every file before it is sent.
Everything data-driven subscriptions did, without needing Enterprise edition — and the PowerShell can be retired on a Friday afternoon.
A Portal, Not Report Manager
The Document Portal is per-recipient: each employee finds their payslips, each customer their invoices, nobody sees anybody else's — with notifications, your branding, and online payments. Report Manager is a folder tree with permissions on it. Different thing entirely.
Reports, Including the Pixel-Perfect Ones
Generation from SQL, Groovy, CSV, TSV, fixed-width, Excel, XML, Google Sheets, and Office 365 into PDF, XLSX, DOCX, HTML, or any text format.
You design layouts in HTML and CSS: proper page breaks, headers and footers that repeat, elements exactly where you place them, web fonts, and a preview that refreshes as you save rather than the old deploy-then-look-at-it routine. XSL-FO is available when the typography has to be exact. Excel files come out of HTML templates with formulas intact, and Word files out of DOCX templates with merge fields.
Pages of rows and columns are a first-class case here, not the awkward one Power BI Desktop makes of them. And there is no Report Builder to be disappointed by — the template is markup your web developers already read.
Dashboards and Embedded Analytics, Without Per-User Licensing
Interactive dashboards, plus data tables, charts, and pivot tables embedded into your own applications with a script tag. This is the interactive half PBIRS adds via PBIX — and reaching it does not mean buying a seat for every person who opens the page.
When reporting load would otherwise hit production, OLTP-to-OLAP sync via CDC with DuckDB and ClickHouse sits underneath.
A Semantic Layer, If You Had SSAS
If your estate pairs SSRS with Analysis Services — or if shared datasets grew into an informal model nobody owns — Cubes are the counterpart: dimensions, measures, joins, segments, and hierarchies declared once in a text DSL that diffs in Git, drafted by AI against your live schema, and read identically by reports, dashboards, AI chat, and embedded components. No Visual Studio project, no processing window.
Any Database, Not Just SQL Server
SQL Server, PostgreSQL, MySQL, Oracle, and anything else with a JDBC driver — which matters more than it used to, since very few estates are single-vendor any more.
The Rebuild Is Mostly Reviewing
Hand Hey AI, Help Me... the query from an existing RDL and a description of the layout, and it writes the template. See AI-powered reporting and the template gallery. Around that, the AI crew picks up the adjacent jobs, and Chat2DB answers ordinary questions in SQL.
And the configuration itself behaves like source code. You set reports up through a UI — data source, template, parameters, schedule — with AI available beside any field that wants code and quiet otherwise. Everything that UI saves is plain text on disk.
RDL is XML, so this is familiar ground in principle. The difference is where it lives: your SSRS reports are published into the ReportServer catalog, a database you back up rather than a repository you branch. Here the definitions stay as files, so a report change is a commit, a review, and a revert if it turns out badly.
The Honest Bit: RDL Does Not Run Here
DataPallas does not execute .rdl files. Moving a report means rebuilding it, AI-assisted.
Worth weighing that against what you get, and against what the Microsoft route costs you for the same rebuild — a SQL Server 2025 licence or active Software Assurance, plus the migration work, plus wherever per-user licensing takes you afterwards. Either way there is a licence to buy; the question is whether it keeps growing with your audience.
Phase One: Migrate Subscriptions, in Week One
The first phase lands before you rebuild a single RDL, and it targets the part that actually hurts.
DataPallas takes a report from any source and bursts it. SSRS keeps rendering to PDF on its existing schedule; DataPallas takes over the splitting, the recipient routing, and the delivery — everything your data-driven subscriptions did, or everything the PowerShell around them was doing instead.
That is a real workload migrated in week one, with no RDL touched and nothing to roll back. Most of the scripting goes away immediately, and you have proof on your own data before anyone approves a bigger phase.
Phase two is the reports themselves, AI writing the templates, on a timetable you choose.
Where to Start
- Confirm your SQL Server edition and Software Assurance status. That determines what the Microsoft path costs you.
- Separate "rendering reports" from "delivering reports." SSRS only ever did the first one well.
- Point DataPallas at the output your SSRS subscriptions already produce, and burst one report to email or portal.
- Rebuild one RDL, AI-assisted, and see what it really takes.
- Decide the rest with real numbers — on your own timetable, not a deadline.