SSRS Is Being Replaced by Power BI Report Server: What It Means

What Microsoft Actually Changed

SQL Server 2022 is the last release that includes SQL Server Reporting Services (SSRS) as its own product. SQL Server 2025 ships without it, and no further SSRS versions are planned. The on-premises successor is Power BI Report Server (PBIRS). It hosts the same paginated reports (RDL) and adds on-premises hosting of Power BI reports (.pbix).

This is a consolidation, not a move to the cloud. PBIRS runs on your own Windows servers and keeps the familiar ReportServer and ReportServerTempDB databases. What changes is the product name, the release model, the licensing path, and a handful of operational details.

What Does Not Change Right Now

SSRS 2022 keeps running. It stays supported for as long as SQL Server 2022 itself, with the end of extended support in January 2033. Nobody has to migrate this week.
SSRS 2022 works against a SQL Server 2025 database engine. Moving the engine to 2025 does not force the reporting tier to move at the same time.
Your RDL files stay valid. Paginated reports, shared data sources, shared datasets and the REST API v2.0 carry over.

What Does Change

Area	Consequence
Upgrade path to SQL Server 2025	There is no SSRS 2025. The only Microsoft path is PBIRS, or staying on SSRS 2022 for now.
Licensing	For SQL Server 2025, PBIRS can be installed with the product key of a paid Standard or Enterprise edition. For SQL Server 2022 and earlier, PBIRS rights still depend on Enterprise with Software Assurance. Express no longer includes reporting. Check each environment individually.
Migration	No in-place upgrade. You restore the report server database onto a new PBIRS instance and restore the encryption key. Microsoft requires a recent PBIRS build (May 2025 or later) for databases coming from SSRS 2022.
Release cadence	PBIRS ships several releases per year, not one major version per SQL Server generation. Patch management has to follow that rhythm.
Service and instance names	The Windows service, install path and default instance name differ from SSRS. Monitoring, scripts and permission processes with hard-coded names will break.
Features	Sources disagree on how complete the replacement is, particularly around subscriptions, delivery and export types. Verify every feature you rely on before committing.

Step 1: Know What You Actually Run

Before anyone discusses a target version, inventory the report server. The catalog tells you what is in use and what is dead weight. This query is read-only and cheap, because it only touches the catalog tables:

-- Items by type (1 Folder, 2 Report, 4 Linked report, 5 Data source, 8 Shared dataset)
SELECT [Type], COUNT(*) AS Items
FROM ReportServer.dbo.[Catalog]
GROUP BY [Type]
ORDER BY [Type];

-- Subscriptions by delivery extension (email, file share, ...)
SELECT DeliveryExtension, COUNT(*) AS Subscriptions
FROM ReportServer.dbo.Subscriptions
GROUP BY DeliveryExtension;

-- Data source kinds actually used
SELECT Extension, COUNT(*) AS DataSources
FROM ReportServer.dbo.DataSource
GROUP BY Extension;

Reports that nobody has run for a year are candidates for retirement, not migration. The ExecutionLog3 view shows the last execution per report.

Step 2: Back Up the Two Things You Cannot Recreate

A migration to PBIRS is a database restore plus a key restore. Without the encryption key, stored credentials in data sources and subscriptions are lost and have to be re-entered by hand. Back both up on the source server and test the restore somewhere that is not production:

# Report server databases
Backup-DbaDatabase -SqlInstance SRV01 -Database ReportServer, ReportServerTempDB `
    -Path D:\Backup -Type Full

# Encryption key: use Report Server Configuration Manager (Encryption Keys > Backup),
# or rskeymgmt on older builds. Store the key file and its password separately.

Treat the encryption key like a certificate private key. A key file without its password is useless, and a key file stored next to the database backup defeats its purpose. Keep both under change control.

Step 3: Build the Target and Rehearse

Install PBIRS (current build) on a separate server or VM.
Restore ReportServer and ReportServerTempDB as copies, point PBIRS at them in Report Server Configuration Manager, then restore the encryption key.
Re-check the URL reservations, the service account, SSL bindings and the SPNs. These are the settings that differ most from the old server.
Run a sample of reports with real parameters, plus every subscription type from your inventory.
Compare execution times against the old server. A slower report after migration is much easier to find on a rehearsal than in production.

Step 4: Check Everything Around the Report Server

The report server itself is rarely the problem. The trouble sits in the things that talk to it:

Deployment scripts that find the server by service name, WMI namespace or registry path.
Monitoring that checks for the SSRS Windows service by name.
Availability Group setups where the report databases sit in an AG. The scale-out and failover design needs a fresh look. See SSRS with AlwaysOn Availability Groups.
Developer workstations with Report Builder or the Visual Studio report projects. Both stay supported, but the target URL changes.
Certificates for the new endpoint. See SSL certificate errors with shared datasets for the usual trust-store trap.

What We Found When Testing Our Own Tooling

We installed Power BI Report Server 15.0 next to an SSRS 2022 instance in a lab and ran our own automation against both. Copying content over the REST API v2.0 worked for all seven test items (data source, shared dataset, reports, linked reports, image), and all 22 diagnostic RDL reports we maintain rendered against the new catalog. The surprises were in the configuration scripts and in how stored passwords are handled:

WMI instance names. The two products live in different namespaces, RS_SSRS and RS_PBIRS. A script with a hard-coded instance name fails on the other product. Detect the instance instead, and refuse to guess when both are present.
WMI methods are instance methods. Calling them with Invoke-CimMethod -ClassName returns "general failure" or "invalid method parameters". Fetch the configuration instance first and pass it with -InputObject. This is not specific to PBIRS, it also broke the same calls against SSRS 2022.
URL reservation. ReserveURL wants only http://+:8081. The path (ReportServer, Reports) is a separate virtual directory set with SetVirtualDirectory.
Missing folders. The SOAP call GetItemType returns Unknown for a missing item instead of throwing, so a try/catch around it never creates the folder. Compare the return value.
Stored passwords. A stored data source password cannot be read from the source server. PBIRS refused to create such a data source without one (HTTP 500, "Expected parameter 'Password for Server' is missing"), so the credential has to be supplied during migration.

None of these are PBIRS bugs. They are assumptions in our own scripts that happened to work on one product and one configuration. A test installation next to the old server finds them in an afternoon.

Decision Guide

Situation	Recommendation
SQL Server 2022 with SSRS, no 2025 plans	Stay. Inventory now, plan the move for the next engine upgrade.
Engine upgrade to 2025 planned	Upgrade the engine first, keep SSRS 2022 running, migrate the reporting tier as a separate project.
New reporting platform on-premises	Install PBIRS directly. Do not build anything new on SSRS 2022.
Express edition with reports	Reporting rights are gone in 2025. Plan an alternative or licensed edition.
Cloud-first strategy	Paginated reports in Power BI or Fabric are the other route, with a gateway for on-premises data. Not an option where data must stay on-site.

Checklist

Confirm the licensing path per environment before any technical work
Inventory reports, subscriptions and data source types from the catalog
Retire unused reports instead of migrating them
Back up both report databases and the encryption key, and test the restore
Rehearse on a separate PBIRS instance with a recent build
Check scripts, monitoring and permission processes for hard-coded SSRS names
Re-verify certificates, SPNs and URL reservations on the target
Plan the cutover as its own project, separate from the engine upgrade

The Bottom Line

The end of SSRS is a licensing and lifecycle event, not an emergency. Existing report servers run for years. The risk is not the report server itself but everything built around its names, paths and service accounts. The cheapest preparation is an honest inventory today and a rehearsal on a copy of the database before anybody sets a date.

Sources

← Back to Blog