The report files are copied, but subscriptions and saved credentials do not follow by magic. Moving SSRS reports needs the report server database and encryption key treated as a matched pair.
Inventory the Whole Report Server
List report folders, shared data sources, shared datasets, subscriptions, schedules, security assignments, custom extensions, and configuration. A report definition is only one part of the service. The ReportServer database holds the catalog and much of the operating state. The temporary database has a separate role in execution.
I ask which reports send email or write to file shares. Those subscriptions can fail after a move because service identities, permissions, or destinations change. Include delivery paths in the inventory and choose a few representative reports for rehearsal.
Record the current version and target version. Follow the supported migration path for that pairing. Do not restore a newer report server database to an older service and expect it to work. An inventory makes the version and feature questions visible before moving SSRS reports.
SELECT Name, Type, Path, CreationDate, ModifiedDate
FROM ReportServer.dbo.Catalog
ORDER BY Path;Back Up the Databases and Encryption Key
Back up the ReportServer database, ReportServerTempDB as required by the migration plan, and the report server encryption key. Store the key backup and its password securely and separately from the database backup. The key protects sensitive values such as stored credentials in the report server database.
A new computer cannot simply use the old machine’s protected key material. Restore the backed up encryption key through Report Server Configuration Manager or the supported utility after connecting the new service to the migrated database. Without it, encrypted settings can be unreadable.
I verify the key backup before the move, while the old server is still available. Discovering that it is missing after cutover turns a planned migration into credential recovery work. The key file deserves the same attention as the database backup.
SELECT name, state_desc, recovery_model_desc
FROM sys.databases
WHERE name IN (N'ReportServer', N'ReportServerTempDB');Build the New Service Before Moving SSRS Reports
Install the supported SSRS release and configure its service account, URLs, database connection, and encryption key. Confirm that the target can reach report data sources and SMTP or file share destinations. A successful portal page proves the service is running, not that reports can retrieve data.
Use a nonproduction rehearsal when possible. Restore a copy of the databases, restore the matching key, and test representative reports. Keep rehearsal subscriptions disabled or redirected so they do not send duplicate messages. The goal is to exercise migration mechanics without surprising recipients.
I check service identity permissions on both the report server database and external data sources. An account change can reveal a permission that was implicit on the old machine. Record each needed grant rather than broadening access until the error disappears.
Move Catalog State With a Supported Path
For a native mode migration, follow Microsoft’s documented database backup and restore procedure and then configure the new report server to use the restored database. Keep database names and version compatibility in view. Do not edit ReportServer catalog tables directly to fix a report. Internal schema is owned by SSRS.
Some teams choose a content migration tool rather than moving the entire report server database. That path needs a separate inventory of subscriptions, security, data sources, and settings. Choose deliberately based on what must be retained. A folder copy is not equivalent to service migration.
I document the cutover order: stop or pause old scheduled work, take final backups, restore, connect, restore the key, validate, then switch user entry points. A written sequence reduces the chance that both servers deliver the same scheduled report.
Test Data Sources and Credentials
Run reports that use each credential pattern: stored account, integrated security, and any approved custom method. Confirm shared data sources and embedded data sources separately. A report can render using a cached result while its live data source is broken, so force a fresh execution during testing.
Check connection strings for old server names. Replace them through supported report management, then test the underlying database permissions. Avoid a blind string replacement across report definitions. The target name can appear in a parameter default or expression with a different meaning.
I prefer to validate one report from each data source family. That gives better coverage than opening ten reports that all use the same shared connection. Record the result and the exact identity used.
SELECT Path, Name, Type
FROM ReportServer.dbo.Catalog
WHERE Type IN (2, 5)
ORDER BY Path;Rehearse Subscriptions When Moving SSRS Reports
Subscriptions depend on schedules, credentials, extensions, and destination access. Compare the inventory with what appears on the new server. Test email and file share delivery to controlled recipients or paths before enabling the normal schedule. Check that parameter values and delivery settings survived.
Prevent double delivery during cutover. Pause the old service’s schedules before the new service begins running them. Keep a rollback plan that says which service will own the next scheduled execution if validation fails. Ambiguous ownership can send the same report twice.
I inspect the first scheduled execution after cutover, not only the manual test. Unattended execution can use a different account and expose a hidden permission issue. A subscription marked enabled is not evidence that a message arrived.
SELECT TOP (50) ItemPath, UserName, RequestType,
Format, TimeStart, Status
FROM ReportServer.dbo.ExecutionLog3
ORDER BY TimeStart DESC;Validate Moving SSRS Reports With a Rollback Window
Compare folder counts, representative permissions, reports, subscriptions, and execution results with the inventory. Test a report with parameters, one with a shared data source, and one scheduled delivery. Check portal URLs and bookmarks if users depend on them. The new host should serve the same work, not merely display the same folder tree.
Keep the old server available but inactive during the rollback window. Do not allow both to write to the same report server database unless the deployment is intentionally configured for that supported topology. Preserve final backups and the encryption key until the new service is accepted.
A migration is complete when readers can open reports and scheduled deliveries reach their destinations under the intended identities. The database and key make that possible. The validation proves it happened.
Can the new server run one scheduled subscription and one fresh report under the intended service identity?
Related reading on this blog: The Report Server Cannot Open a Connection to the Report Server Database. (rsReportServerDatabaseLogonFailed) and Event ID 107- Report Server Windows Service (MSSQLSERVER) cannot connect to the report server database..
Moving reports is not copying report files, it is moving an operating service with its keys and schedules.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
