SSRS to Power BI Report Server Migration: What Happens to Your Reports, Schedules, and Permissions?
The report opens on the new server. The totals look right. Then Monday morning arrives, and the scheduled PDF never reaches accounting.
An SSRS to Power BI Report Server migration has to account for more than the reports people open in a browser. A full report server database migration can preserve RDL reports, folders, subscriptions, schedules, and stored permissions. Getting them to work on the new server also depends on credentials, service accounts, SQL Server Agent, delivery settings, and the systems those reports connect to.
The migration method matters. Restoring the report server databases carries far more of the existing environment than uploading a collection of report files. Neither approach automatically reproduces every setting on the old machine.
Why move from SSRS to Power BI Report Server?
Starting with SQL Server 2025, Microsoft consolidated its on-premises reporting direction under Power BI Report Server, with no new versions of SQL Server Reporting Services planned. That makes migration a practical planning question for organizations maintaining an SSRS estate. It does not mean every existing installation must be switched off immediately.
Power BI Report Server, often shortened to PBIRS, runs in an environment your organization manages. It can host paginated RDL reports as well as Power BI reports. It is a different destination from the cloud Power BI service, which has its own sharing, security, and migration considerations.
Moving an SSRS report to PBIRS does not turn it into an interactive Power BI report. An invoice, statement, or operational listing can remain a paginated report. Building a new analytical report is a separate decision. Our Power BI vs. custom dashboard guide looks at that wider reporting choice.
What happens to reports, schedules, and permissions?
This overview assumes an SSRS native mode environment and a supported migration of its report server databases. A SharePoint-integrated installation needs a separate plan. If the proposal is to export and upload individual files, ask which settings and dependencies will be recreated alongside them.
| Part of your SSRS environment | What happens | What to check |
|---|---|---|
| RDL reports and folders | The catalog carries report definitions and folder structure. | Data connections, parameters, subreports, exports, and printed output. |
| Shared data sources and datasets | Definitions can move with the catalog. | Restored encryption key, credentials, drivers, and access to the source systems. |
| Subscriptions and schedules | Definitions can be preserved through the database migration. | SQL Server Agent, subscription owners, timing, email delivery, and file shares. |
| Report and folder permissions | Stored role assignments can be preserved. | Whether users and groups still resolve, inherited access, and system permissions. |
| Report history and snapshots | A database migration can retain stored history and snapshots. | Retention requirements and whether scheduled snapshots still update. |
| Server configuration and custom components | The catalog alone does not reproduce the server environment. | URLs, certificates, email settings, service accounts, extensions, and assemblies. |
Uploading RDL files is not a full SSRS migration
An RDL file contains a report definition. It is not a backup of the report server.
Uploading that file can be useful when moving a small, selected group of reports to a clean environment. But subscriptions, shared schedules, folder security, and report history do not arrive just because the report definition does. Shared data sources, shared datasets, and other dependencies also need deliberate handling.
For a fuller native mode migration, the usual starting point is a backup of the report server databases, commonly named ReportServer and ReportServerTempDB, plus the matching encryption key. PBIRS is installed and configured against restored copies of those databases. Microsoft documents this as a migration rather than an in-place upgrade from SSRS.
Check the source and destination releases before building the plan. In particular, migrating from SSRS 2022 requires Power BI Report Server May 2025 or later. The SQL Server instance that hosts the catalog, the operating system, and the report server release also need a supported combination.
If preserving the current reporting setup is the goal, get the migration scope down to individual items. "Move the reports" leaves too much open to interpretation. Our data migration service covers the mapping, validation, and cutover work that needs to sit around the transfer itself.
Your existing reports can stay RDL reports
You do not need to rebuild every SSRS report in Power BI Desktop to use Power BI Report Server. Existing paginated reports can continue to serve the jobs they were designed for, subject to compatibility testing.
Start with a report people depend on, using the same parameters and a stable set of source data on both servers. Compare totals, row counts, grouping, sorting, and drillthrough behavior. Then test the formats people actually use. A report that looks correct in the browser can still produce an extra blank PDF page, a different page break, or an Excel file that disrupts someone's monthly process.
Look beyond the RDL, too. A report may depend on a subreport, an external image, a particular font, a database driver, or a custom assembly. Those dependencies need to be available and compatible on the destination. Custom rendering, delivery, data processing, or security extensions need their own review and deployment.
Old report URLs deserve a place in the inventory. Staff bookmarks, application links, and automated downloads may point to a hostname and report path that change during migration. Test those entry points, including parameters passed through the URL.
For a hypothetical maintenance company, that might mean checking both a manager's weekly labor summary and the detailed PDF attached to a customer invoice. The summary needs the right figures. The invoice attachment also needs the right customer, date range, layout, and delivery destination. Honor Tech's reporting and dashboard service covers SSRS and Report Builder work alongside custom reporting applications.
Schedules and subscriptions need a delivery test
Schedule definitions and subscriptions can survive a database migration. Their presence in the portal does not prove they will run.
SSRS scheduled processing normally uses SQL Server Agent to trigger events, which the report server then processes. When report server databases move to a different SQL Server instance, the report server recreates the corresponding Agent jobs. Manually copying those jobs is not a substitute for configuring and checking the migrated report server.
Test the complete subscription. Can it retrieve data without an interactive user supplying credentials? Does its owner still have the required access? Can the new server use the mail relay or write to the destination share? Are its parameter values and output format still correct?
With a data-driven subscription, check the query that supplies recipients and parameter values as well. A successful report run does not prove that each recipient will receive the intended version. Confirm that the destination edition supports the subscription features you use.
Timing needs attention, especially when server locations or time zones change. Record the intended business time and any dependency on an overnight import. A report sent at 6 a.m. is little use if the data it needs will not finish loading until 6:15.
Keep test deliveries away from production recipients and shared folders until they are approved. During the switch, control which server is allowed to deliver subscriptions. Two working servers can otherwise send duplicate emails or overwrite the same file. Also decide how to handle any delivery missed during the maintenance window; do not assume it will be replayed automatically.
Permissions can move while access still breaks
A catalog migration can preserve report server role assignments. Those assignments still need to make sense in the destination environment.
Review access at the system, folder, and report levels. Check inherited permissions and any report that breaks inheritance. Then verify the users and groups behind those assignments. A domain group may still be valid, while an account or local group tied to the old machine needs attention.
There are several separate access checks in a working report. A person needs permission to open it. The report's configured identity needs permission to read its data. A subscription may need a further identity to write a file to a network share. Preserving the first permission does not establish the others.
Service account changes can also affect Windows authentication, Kerberos configuration, and access to remote systems. Review those connections with whoever manages the domain and databases. Avoid solving a connection problem by giving everyone broader access.
Run acceptance checks as an ordinary report reader and as a report author, as well as an administrator. Include an account that should be refused access. Seeing the right folders as an administrator tells you very little about whether the migrated security works for everyone else.
The encryption key belongs in the migration plan
The report server encryption key protects sensitive catalog information such as stored credentials and connection information. A database backup alone does not give the new installation everything it needs to read that information.
Back up the matching key through Report Server Configuration Manager, protect it with a password, and keep it securely apart from the database backups. Test that it can be restored during the rehearsal. Discovering at cutover that nobody knows the password is an avoidable delay.
Restoring the key does not renew an expired password or grant the destination access through a firewall. It allows the new installation to use the encrypted information you preserved. The accounts and connections still need to work.
If the key is unavailable, identify which credentials and settings must be entered again before committing to a migration window. Treat that recovery work as part of the scope.
A practical SSRS to Power BI Report Server migration checklist
1. Inventory what the business uses
Record reports, shared dependencies, subscriptions, owners, access groups, custom components, and application links. Ask who relies on each output and when. Include month-end and occasional reports that a week's activity would miss. Agree on which unused items can be retired.
2. Rehearse against restored copies
Build the destination, restore the database copies and encryption key, and work through the required configuration. Keep outbound deliveries controlled. Record each manual change so the final migration can be repeated. A software discovery phase can establish those dependencies and acceptance criteria before a date is promised.
3. Get business owners to check the output
Have the people who use the reports compare representative results, exports, subscriptions, and access. Keep the comparison data consistent. Otherwise, a new transaction entered between test runs can look like a migration error. Include the largest and most awkward reports, not just the easiest ones to open.
4. Define the final switch
Set a freeze for report, security, and subscription changes. Plan the final backups, restoration, URL changes, and delivery handoff. Name the person who can approve the switch and the conditions that would delay it. Go-live support should cover the first important reporting cycle as well as the maintenance window.
5. Make rollback possible
Retain the original environment and verified backups until the new one is accepted. Connecting a newer report server can upgrade the restored catalog schema; an older server cannot simply use that upgraded database. Rollback needs the appropriate original backups and configuration, plus a decision about any changes made after the switch.
6. Check what happens after launch
Confirm that scheduled reports reach the right people with the right data. Watch failed subscriptions, slow reports, authentication errors, and file deliveries. Include the next month-end or other critical reporting date in the support plan. If the wider system also needs updating, our guide to modernizing legacy business software explains how to stage that work around daily operations.
What affects migration cost and downtime?
Report count is only part of an estimate. A folder of straightforward reports sharing one data source can take less investigation than a handful using custom code, old drivers, several authentication methods, and critical overnight deliveries.
Scope depends on the source version, database size, custom components, number of subscriptions, identity changes, test coverage, and available maintenance window. Separating a report server migration from a database platform move or a report redesign can make the work easier to validate, when the supported versions allow it.
Confirm PBIRS licensing against the SQL Server version, edition, and licensing agreement you actually hold. Authoring and viewing requirements also deserve a check. Do not base the budget on an old comparison of SSRS and Power BI licensing.
Ask for an estimate that includes the rehearsal, final cutover, rollback preparation, and support through the agreed reporting cycles. Our business data migration cost guide explains why testing and the final switch account for work that a simple transfer estimate misses.
Questions worth settling before you book the migration
Will our SSRS reports become Power BI dashboards?
No. RDL reports remain paginated reports. You can decide separately whether selected reports should be redesigned for interactive analysis.
Do we have to recreate every subscription and permission?
A full catalog migration can preserve their definitions. A file-only move requires separate work to recreate them. In both cases, verify owners, identities, credentials, delivery, and effective access on the destination.
Can users keep the same report address?
Often, but preserving a hostname requires planned DNS, certificate, URL, and authentication configuration. Test browser access, embedded links, and automated callers before treating the address as interchangeable.
Plan around the reports your team cannot miss
Before setting a date, pick the reports that would cause a problem if they failed tomorrow. Identify their owners, data sources, delivery times, recipients, and access rules. That gives the migration a concrete acceptance test.
Honor Tech can review your SSRS environment and help scope the reports, dependencies, testing, and cutover through a workflow and integration assessment. Tell us which SSRS version you run and which reporting deadlines you need to protect.