Guide
SQL Server 2025 ships without SSRS. How to replace subscriptions that only email a CSV or Excel file, without moving to Power BI Report Server.
Most SQL Server shops have a Reporting Services instance that nobody chose on purpose. It was installed years ago for one paginated report, and since then it has quietly become the place where scheduled emails live: the Monday orders extract for finance, the nightly list of failed payments for support, the stock report a warehouse manager opens in Excel every morning. None of those are really reports. They are a query, a schedule and a mailbox, and SSRS happened to be the tool on the server that could do all three.
SQL Server 2025 changes the default answer. It ships without SSRS, and Microsoft points customers who need on-premises reporting to Power BI Report Server instead, which comes with the paid editions. SSRS 2022 keeps working and stays supported until January 2033, so nothing breaks tomorrow. What changes is that the next server upgrade forces a decision about every subscription on the old instance.
Open the subscription list on the report server, or query ReportServer.dbo.Subscriptions joined to Catalog if the list is long, and put every subscription into one of two buckets.
The first bucket holds real reports. They have a layout that matters, page headers, grouping, a logo, a PDF that goes to a customer or an auditor. Those need a reporting engine, and Power BI Report Server reads the same RDL files, which makes it the shortest path for them.
The second bucket is usually bigger. It holds subscriptions whose render format is CSV or Excel, whose report is a single table bound to a single dataset, and whose recipients immediately sort, filter or paste the rows into something else. For these, the RDL file is packaging around one SELECT statement. Migrating them to another reporting server keeps the packaging and the maintenance that comes with it.
A quick test for the second bucket: if the person receiving the file would be equally happy with the raw query result, the report layer is not doing any work.
Database Mail and SQL Server Agent. msdb.dbo.sp_send_dbmail can run a query and attach the result as a file, and an Agent job can call it on a schedule. It costs nothing and runs where the data already is. The catch is the output format: the attachment is plain text with a separator, without proper CSV quoting, with a dashed line under the header unless you work around it, and with a default attachment size limit of 1 MB. The step by step version covers the parameters and the workarounds. It also does not exist on SQL Server Express or on Azure SQL Database, which rules it out for a fair number of the servers that ran SSRS in the first place.
PowerShell or SSIS on a scheduler. Invoke-Sqlcmd piped into Export-Csv, or a small SSIS package, produces a correct file and can mail it through whatever relay the company uses. It works well for one engineer and becomes a folder of scripts with credentials in them when the engineer moves on.
Power BI Report Server. It keeps paginated reports alive and supports email subscriptions. For the CSV bucket it is the heaviest option on the list, and its licensing follows the SQL Server edition and Software Assurance rules, which deserve a check before anyone plans on it.
A scheduled SQL export tool. This is the category Taavik's scheduled exports belong to: save the query once, pick a schedule and a time zone, choose CSV or Excel, and deliver to an email list or a Slack channel.
A small agent runs on a machine inside the network that can reach the SQL Server instance, and it only makes outbound connections to the workspace. The query from the SSRS dataset goes into the shared query library, keeping its parameters as {{variables}} with default values. The schedule takes the place of the subscription: daily, weekly, monthly, every few hours, or a cron expression on the Pro plan, each in its own time zone. Delivery rules cover the common subscription settings, including sending only when the query returned rows, which is how most exception reports were meant to work.
There is one behaviour that differs from SSRS and is worth stating plainly. The email does not carry the file as an attachment. The agent encrypts the export before it leaves the network, the message carries a download link, and the recipient opens it with a passphrase that was shown once when the schedule was created. For extracts with customer or payroll data, that is usually the reason to move. For a recipient who expects the spreadsheet in the inbox, it is one extra step, and it is better to say so before the first Monday.
Each run leaves a record with its status, duration and row count, which answers the question SSRS administrators get asked most often: did the report go out this morning, and if not, why.
Paginated layouts, drill-through, charts and pixel-precise PDFs stay in the first bucket. Data-driven subscriptions that send a different file to each recipient based on a lookup table also have no direct equivalent here. The schedule sends the same result to the same list, so the closest substitute is one schedule per audience with a filtered query.
Start with the subscriptions that fail most often, because their owners will notice the improvement. Move the query, run the schedule in parallel with the SSRS subscription for a week, compare the files, then disable the subscription rather than deleting it. When the last CSV subscription is gone, what remains on the report server is the honest size of the reporting problem, and the decision about Power BI Report Server becomes much smaller.
For the rest of the move, the SQL Server 2025 upgrade checklist covers the schema side: what to capture before, and what to compare after.