Every few years someone announces that SQL Server Reporting Services is finished. Then the month-end close arrives, finance needs 4,000 customer statements as PDFs by 7 a.m., an auditor asks for the exact report that was sent to the regulator in March, and the interactive dashboard is nowhere to be found. Paginated reporting is a different job from interactive analysis, and the organizations that get this right run both.
Two products, two jobs
SQL Server Reporting Services (SSRS) is the on-premises platform for creating, deploying and managing paginated reports through a web portal, with mobile reports and a programmable API alongside [1]. Power BI paginated reports are the same report definition language (RDL) authored in Power BI Report Builder and published to the Power BI service, where they are described as “pixel perfect” reports designed for printing and sharing that show all the data in a table across as many pages as needed [2]. The authoring model is the same; the hosting, licensing and distribution are what differ.
Interactive Power BI reports are for exploration: slicing, drilling, asking the next question. Paginated reports are for documents: output whose layout, pagination and totals are fixed and have to match exactly, every time, on paper or in a PDF.
Where paginated still wins
| Requirement | Paginated (SSRS / Report Builder) | Interactive Power BI |
|---|---|---|
| Invoices, statements, packing lists, bills of lading | Designed for it: page headers and footers, group breaks, running totals, barcodes. | Awkward; export truncates, layout drifts. |
| Regulatory and statutory filings | Fixed layout, reproducible output, archived as PDF. | Visual state depends on slicers; hard to prove what was sent. |
| Large tabular exports (100k+ rows) | Renders the full dataset to Excel, CSV, PDF or Word. | Visual export caps rows; the service limits exports. |
| Scheduled distribution to many recipients | Subscriptions with parameter values per recipient; file-share and email delivery on SSRS. | Subscriptions send snapshots of a page, not per-recipient parameterized output. |
| Printing | Page size, margins and breaks are first-class. | Designed for screens. |
| Ad-hoc exploration, what-if, drill-down | Limited; parameters only. | This is the job it was built for. |
| Alerts, AI narratives, natural-language Q&A | Not available. | Native. |
The pattern is consistent: if the output is a document that someone will file, print, mail or audit, build it as a paginated report. If the output is a question that will lead to another question, build it as an interactive report. The mistake is forcing one tool to do the other job.
Why organizations keep SSRS on-premises
- Data residency and network isolation. SSRS runs inside the datacenter, next to the SQL Server it reports from, with no cloud dependency. For some regulated workloads that is the whole requirement.
- Licensing. SSRS is included with SQL Server. Paginated reports in the Power BI service require a Pro or Premium Per User license for the author and, for shared capacity, licenses for consumers, or a Fabric/Premium capacity [2].
- Delivery options. SSRS subscriptions can write files to a network share and run data-driven subscriptions, which the Power BI service does not replicate one-for-one.
- Hundreds of existing RDLs. A report estate built over 15 years is a liability only if nobody owns it. Owned and inventoried, it is an asset.
A migration path that does not break month-end
When the decision is to consolidate on the Power BI service, the RDL format carries over, but the environment around it does not. The sequence that has worked for me:
- Inventory and triage. Query the ReportServer catalog for every report, its last execution and its subscriptions. In most estates a third of the reports have not run in a year; retire them first, with a written owner sign-off.
- Classify by job. Documents stay paginated. Reports that are really dashboards (a chart with a parameter) become interactive Power BI reports on a shared semantic model; this is where the modeling work from the advanced modeling article pays off.
- Re-point data sources. Paginated reports in the service connect through the on-premises data gateway to SQL Server, or directly to a Power BI semantic model. Connecting to the semantic model is the governance win: one definition of revenue for both the dashboard and the statement.
- Rebuild subscriptions deliberately. Map each SSRS subscription to a service subscription, a Power Automate flow, or a scheduled export, and test the parameterized cases (one statement per customer) explicitly.
- Run both for one close. Publish the new report, keep the old one running, and reconcile the outputs line by line for one month-end before cutting over.
Design rules for paginated reports that survive audits
- Put the data source, parameter values, execution time and report version in the footer of every page. When the auditor asks “which version produced this,” the answer is on the paper.
- Compute totals in the query or the semantic model, not in the report’s expressions, so the dashboard and the statement cannot disagree.
- Use shared datasets and shared data sources; a report estate with 300 embedded connection strings is a security finding waiting to happen.
- Archive the rendered PDF, not just the RDL. The report definition can change; the document that was sent cannot.
The honest conclusion
Interactive analytics got the attention and the budget, and deserved most of it. But the regulated, high-volume, document-driven work that SSRS was built for has not gone away, and Microsoft kept the paginated engine alive inside Power BI for that reason. A BI estate that pretends dashboards replaced documents will find the gap at the worst possible moment. Run both, govern both from one semantic model, and let each do its job.
References
- Microsoft Learn, “What is SQL Server Reporting Services?” learn.microsoft.com/en-us/sql/reporting-services/create-deploy-and-manage-mobile-and-paginated-reports (accessed 9 Oct 2026).
- Microsoft Learn, “What are paginated reports in Power BI?” learn.microsoft.com/en-us/power-bi/paginated-reports/paginated-reports-report-builder-power-bi (accessed 9 Oct 2026).
- Microsoft Learn, “Power BI implementation planning,” learn.microsoft.com/en-us/power-bi/guidance/powerbi-implementation-planning-introduction (accessed 9 Oct 2026).
