SQL Server 2025 Has No SSRS Release. Here’s What That Means for Your Migration

TLDR: SQL Server 2025 ships without a new version of SQL Server Reporting Services (SSRS). Microsoft's on-premises reporting roadmap ends at SSRS 2022 — Power BI Report Server (PBIRS) is now the default on-prem reporting platform. If your environment depends on SSRS and you're planning a SQL Server 2025 upgrade, you need two separate migration tracks: one for the database engine, one for reporting. Skip the reporting track and you'll find out the hard way.

The Client Who Wanted the Latest

A client came to us recently with a straightforward ask: migrate their environment to SQL Server 2025. We pushed back once — were they sure they didn’t want 2022? Stability, familiarity, a shorter validation list. They were sure. They wanted the latest.

No problem. So we did what we always do first: validate feature dependencies.

One dependency surfaced immediately: there is no new SSRS release for SQL Server 2025.

Their reporting stack relied on SSRS. That single fact changed the migration plan from one track to two. More testing. More moving parts. More time — but no surprises on go-live.

If you’re planning a SQL Server 2025 upgrade and SSRS is in your environment, this is the article to read before you commit to a timeline.

What Microsoft Actually Decided

Microsoft’s own documentation is unambiguous. Starting with SQL Server 2025, on-premises reporting services is consolidated under Power BI Report Server. No new version of SSRS ships with SQL Server 2025. No new SSRS versions will be released at all.

This is not a deprecation in the traditional sense. SSRS 2022 stays supported with security updates until January 11, 2033 — you have years of runway. But the development roadmap is closed. SSRS is frozen at the 2022 line.

The reasoning Microsoft gives: SSRS is a subset of PBIRS. Power BI Report Server handles everything SSRS does (paginated RDL reports, row-level security) and adds Power BI reports (.pbix), data modeling, custom visuals, and interactive reporting.

PBIRS ships under Microsoft’s Modern Lifecycle Policy with updates three times per year (January, May, September). SSRS does not.

For practical planning, the distinction matters: “no new SSRS” is not the same as “SSRS stops working.”

What it means is that any new capabilities, security posture improvements, and platform direction are flowing into PBIRS, not SSRS.

SSRS 2022 vs Power BI Report Server: What Actually Changes

The migration planning implication: if you only run paginated, pixel-perfect reports and have no need for interactive BI on-prem, SSRS 2022 covers your workload and will continue to do so until 2033. If you want PBIX reports on-prem, a richer self-service layer, or Microsoft’s “default” path for SQL Server 2025, PBIRS is where you’re going.

The Two-Track Migration Model

A SQL Server 2025 upgrade that includes SSRS should always run two parallel workstreams. Treating them as one is how teams discover problems late — after the engine is upgraded and the reporting tier is broken in a way that isn’t visible in database tests.

Track A: SQL Server Database Engine

• In-place upgrade or side-by-side migration to SQL Server 2025
• Breaking changes, compatibility levels, driver updates, HA/DR

Track B: Report Server Tier

•  Option 1: Keep SSRS 2022 (supported to 2033; validate it still works post-engine upgrade)
•  Option 2: Migrate to PBIRS (no in-place upgrade; requires full migration workflow)

Why the tracks must be separate: Track B has its own acceptance criteria. Subscription schedules, encryption keys, stored credentials, custom extensions, URL reservations, and portal configurations are all report server state — none of it is visible in database engine tests.

You can validate every query, index, and stored procedure and still have SSRS fail silently on cutover because an encryption key wasn’t migrated or a linked server dependency hit SQL Server 2025’s new encryption defaults.

SQL Server 2025 Breaking Changes That Hit Reporting

Even if you stay on SSRS 2022, SQL Server 2025 introduces platform-level changes that can affect the reporting tier.

TDS 8.0 and strict encryption defaults. SQL Server 2025 enforces TDS 8.0, which moves the TLS handshake before TDS messages. Older client drivers that can’t negotiate TLS 1.3 or don’t handle strict encryption will fail — including some SSRS data source connections if drivers haven’t been updated.

Linked server breaking changes. Many reporting environments use linked servers or distributed queries underneath report datasets, even when the report definition doesn’t reference them directly.

SQL Server 2025 introduces encryption-related breaking changes for linked servers (example: OLE DB Driver 19 configurations may fail post-upgrade if certificates aren’t in place).

This is one of the most common “it worked yesterday” failures in SQL Server 2025 upgrades.

Compatibility level 170. SQL Server 2025 defaults to compatibility level 170, which includes optimizer changes and new Parameter Sensitive Plan behaviors. Reporting workloads — wide queries, parameter-heavy reports — are often the most sensitive to plan changes. Test your heaviest reports explicitly under level 170 before cutting over production.

Pre-Migration Audit Checklist

Before upgrading the SQL Server engine, document everything the reporting tier depends on. If SSRS has to be rebuilt from scratch, this list is what you need.

Catalog databases. Identify where ReportServer and ReportServerTempDB live — server, instance, backup policy, HA/DR status. These are the databases you’ll restore if the tier is rebuilt.

Encryption key. Confirm you can back up and restore the SSRS encryption key using Report Server Configuration Manager or rskeymgmt. This key protects stored credentials and connection strings. Lose it and you’ll re-enter credentials for every data source. Test the restore in a non-production environment before you need it in production.

Service accounts and permissions. Document the SSRS service account. If the ReportServer catalog is on a different SQL Server instance than the SSRS service, note this — Microsoft documents specific “connection rights” failures when using a virtual service account in cross-server configurations. The fix is switching to Network Service or a domain account.

Report inventory. Count RDLs, shared data sources, shared datasets, and any reports that use linked servers or cross-database queries. The linked server count matters specifically for SQL Server 2025 due to the encryption breaking changes above.

Subscriptions and schedules. List all standard and data-driven subscriptions, including delivery methods (email, file share). These are often the last-mile blockers on cutover when credentials or share paths change.

Custom extensions. Custom authentication, rendering, delivery, or data processing extensions run inside the report server runtime and are version-sensitive. These are the most likely items to break silently after a migration.

URL reservations and TLS bindings. Document default URL reservations (/reports, /reportserver), port configuration, and any TLS certificates attached. Validate these after migration — the portal URL is often the first thing end users notice is broken.

Migrating SSRS 2022 to Power BI Report Server

If you decide this upgrade is the right time to move to PBIRS, go in knowing one thing: there is no in-place upgrade path from SSRS to PBIRS. Microsoft’s documentation is explicit. A migration is required.

For migrations from SSRS 2022 (or later), you need Power BI Report Server (May 2025) or later.

Microsoft’s recommended steps for native mode migration:

1. Back up the SSRS encryption key.
2. Back up ReportServer and ReportServerTempDB databases.
3. Restore/clone both databases to the target SQL Server instance.
4. Install Power BI Report Server.
5. In Report Server Configuration Manager, connect PBIRS to the cloned ReportServer database.

The configuration reconnects PBIRS to the existing catalog, which means your reports, subscriptions, and security assignments migrate with it. The encryption key backup is what protects stored credentials and connection strings through the move.

The rsconfig command-line utility handles report server connection string updates if you’re moving the catalog database or renaming servers. For large or complex migrations, rs.exe scripts can automate content copying between report servers.

Commands You’ll Actually Use

These are the tools Microsoft’s own documentation calls out for SSRS/PBIRS operations. Know them before the migration, not during.

• rskeymgmt — backs up and restores the SSRS encryption key from the command line. Use this alongside the Report Server Configuration Manager GUI option; the command-line route is better for scripted/automated backups.
• rsconfig — modifies the report server’s stored connection information to its ReportServer catalog database. Useful when the catalog moves to a different server or the server is renamed post-migration.
• rs.exe — scripting utility for copying report server content between instances. Relevant in complex migrations and SharePoint-integrated scenarios where you’re moving reports programmatically rather than through a straight database restore.

Post-Upgrade Testing Checklist

After the SQL Server engine upgrade, treat SSRS as its own application tier to validate — not just a set of queries to run.

Connectivity test. Validate representative data sources against the upgraded SQL Server 2025 instance, including at least one connection that uses the updated drivers. SSRS supports SQL Server 2012 and later as data sources, but driver and encryption changes can silently break connections that worked before.

Credential test. Run reports that rely on stored credentials specifically. Stored credentials are protected by the SSRS encryption key — if anything went wrong with key migration, this is where it shows. A connection string failure here is not a data source problem; it’s a key problem.

Execution test. Run your heaviest, most parameter-sensitive reports under a realistic load. If you moved to compatibility level 170, explicitly A/B test before and after — Microsoft documents optimizer behavior changes at 170, and wide reporting queries are more susceptible to plan regressions than OLTP workloads.

Dependency test. Validate any report that routes through a linked server or distributed query. SQL Server 2025’s encryption defaults are the most common source of post-upgrade linked server failures. These break silently at the data source level, not at the report engine level.

Portal and URL test. Validate /reports and /reportserver URLs, TLS bindings, and any bookmarked or embedded report links. URL reservation changes don’t surface in query tests. End users will notice before your monitoring does.

Licensing: What Changed With SQL Server 2025

The licensing question catches a lot of teams off guard, because the rules changed with SQL Server 2025.

• Before SQL Server 2025: Power BI Report Server usage rights required SQL Server Enterprise with active Software Assurance. Standard customers were excluded.
• With SQL Server 2025: PBIRS usage rights are included with both SQL Server 2025 Enterprise and Standard — even without Software Assurance. The SQL Server 2025 product key also activates PBIRS.

In practice, this removes the licensing friction that previously made PBIRS a harder sell for Standard edition shops. If you’re on SQL Server 2025 Standard, you can run PBIRS as part of your existing license.

One nuance: Power BI Pro is required to publish Power BI reports (.pbix) to PBIRS, but Pro is not required to view or interact with those reports. For organizations deploying PBIRS as a viewer platform, that distinction matters in user licensing calculations.

When to Stay on SSRS 2022

Staying on SSRS 2022 through your SQL Server 2025 upgrade is defensible when:

• Your reporting workload is dominated by paginated, pixel-perfect reports (RDL). SSRS does this well and will continue to do so until 2033.
• You want to minimize platform change risk during the engine upgrade. Two migrations (engine + reporting) is more risk than one. Staging them reduces the blast radius of any single failure.
• Your SSRS 2022 estate is already healthy: encryption keys backed up, catalog backups tested, limited custom extensions, no complex linked server dependencies.

What you still need to validate even if you stay on SSRS 2022:

• Data source connectivity to the upgraded SQL Server 2025 instance (driver updates, TLS compatibility)
• Linked server dependencies against SQL Server 2025’s new encryption defaults
• Report execution under compatibility level 170 for parameter-sensitive reports

SSRS 2022 can be used with later SQL Server Database Engine versions to host the reporting catalog. The system requirement is SQL Server 2014 SP3 or later for the catalog databases — SQL Server 2025 qualifies.

When to Move to PBIRS During the Upgrade

Moving to PBIRS in the same upgrade cycle makes sense when:

• You need on-premises hosting for Power BI (.pbix) reports or interactive self-service analytics alongside your paginated reports.
• You’re already on SQL Server 2025 Standard or Enterprise and want to take advantage of the expanded licensing rights that didn’t exist before 2025.
• Your SSRS environment has minimal custom extensions and clean, tested encryption key backups — making the migration lower risk.
• Your organization wants to be on Microsoft’s recommended on-prem reporting path and avoid a second migration window later.

What About Moving to Power BI Service (Cloud) Instead?

PBIRS is the on-premises path. If your organization is already evaluating cloud moves, the alternative is Power BI Service — Microsoft’s fully managed cloud BI platform.

The distinction matters for planning because PBIRS and Power BI Service are not the same product. PBIRS does not support dashboards, Q&A, real-time streaming, in-browser report creation, or app distribution — those are cloud-only features.

PBIRS releases three times per year; Power BI Service ships monthly. PBIRS is on-prem (or VM-hosted); the cloud service is fully managed.

If your organization is on a path toward cloud migration, PBIRS is explicitly positioned as a bridge — Microsoft describes it as providing “a seamless path to the cloud.”

Moving from SSRS to PBIRS during the SQL Server 2025 upgrade does not lock you into on-prem reporting forever.

It puts you on the platform that connects forward to the cloud when you’re ready.

What People Get Wrong

“Upgrading SQL Server upgrades SSRS.”

This misconception has been on Stack Overflow since SQL Server 2017, when SSRS was moved out of the main SQL Server installer.

As Microsoft engineer David Browne explained at the time: “It was moved out of the SQL Installer, but is still licensed as part of SQL Server.”

SQL Server 2025 makes this worse — Microsoft isn’t just shipping SSRS separately; it is not releasing a new SSRS version at all. SSRS is a separate install. It does not update with the database engine.

“SSRS to PBIRS is just an in-place upgrade.”

It is not. Practitioners on SQLServerCentral have described hitting dead ends in Microsoft instructions when trying to restore ReportServer databases onto newer SQL versions, specifically because the official migration documentation doesn’t clearly address the “newer SQL Server as destination” scenario.

DBA Stack Exchange threads show the same uncertainty — one answer noted that docs support hosting the SSRS catalog on lower SQL versions, but lack explicit support language for higher versions. Teams that assume it’s a simple upgrade and discover mid-project it’s actually a migration will have their timeline changed for them.

“We tested the database. Reporting is fine.”

Database engine tests do not cover the report server application tier. Encryption keys, stored credentials, subscription jobs, URL reservations, custom extensions — none of these appear in query or index validation. Microsoft Q&A includes reports of encryption key restore failures and rendering issues after SSRS version updates, particularly in environments with strict version dependencies. The report server has to be tested as its own application after the engine upgrade.

How Much Extra Time Does Two-Track Add?

The honest answer: it depends entirely on your environment.

What is unambiguous is why time increases structurally: SQL Server engine upgrades support in-place paths. SSRS to PBIRS cannot be in-place — Microsoft requires explicit backup, restore, and key migration steps. That’s a separate project workstream with its own acceptance criteria, regardless of report count.

Base your estimate on inventory: RDL count, shared data sources, subscriptions, custom extensions. That number scopes the work. Treat validation as its own deliverable — not a footnote in the engine upgrade plan.

PBIRS covers the same core reporting workload as SSRS, ships more frequently, and is now included in SQL Server 2025 licensing. The platform is there. What teams get wrong is treating the reporting decision as someone else’s problem to figure out after the engine goes live.

Bottom Line

SQL Server 2025 is a strong upgrade — AI features, native JSON, real performance gains. But it creates a reporting decision that doesn’t exist in SQL Server 2022 upgrades: there’s no “SSRS 2025” to land on.

Your options are clear: stay on SSRS 2022 (supported to 2033, fully compatible with the SQL Server 2025 engine) or move to Power BI Report Server (Microsoft’s default, included in SQL Server 2025 licensing, better long-term direction).

Neither choice is wrong. Running the upgrade without planning for the choice is.

Map your reporting dependencies — encryption keys, catalog databases, subscriptions, custom extensions, linked server exposure — before you commit to a timeline. That map is what separates a smooth two-track migration from a fire drill on go-live day.

If you’re planning a SQL Server 2025 upgrade with SSRS in the stack, we’ve run this migration enough times to know where it breaks.