Deploy reports, migrate to Power BI Report Server, in one tool.

Report rollout, done by hand, doesn't scale.

Uploading reports one at a time through the SSRS portal is slow and error-prone, and moving an estate onto Power BI Report Server means re-uploading everything anyway — with every connection string pointing at the old server.

Without it	With SSRS Deployment Tool
Upload each report through the portal, one file at a time	A file scanner with checkboxes — deploy a whole folder in one click
Data source connections get overwritten and have to be re-entered	Existing data source connections are preserved automatically
Moving to PBIRS means starting from scratch	A built-in export → remap → redeploy migration workflow
Self-signed or internal certificates break upload scripts	TLS 1.2 explicitly enabled, works with internal CAs
Missing RDL namespace declarations fail silently on upload	Auto-detected and fixed before upload, without touching the source file

What it needs.

PowerShell	5.1 or later, on Windows (it's a WinForms application)
Target server	SSRS or Power BI Report Server exposing REST API v2.0 (SSRS 16.x-compatible — tested on SQL Server 2019, 2022, and 2025)
Rights	Content Manager role on the target folders you deploy into
Dependencies	None — no dbatools, no external modules. Uses only built-in .NET/PowerShell (WinForms, Invoke-RestMethod, and a SOAP proxy to ReportService2010.asmx for folder creation and data-source rebinding)

The launcher, Start-SSRSDeployment.cmd, copies the tool to %ProgramData%\SSRSDeployment and relaunches it elevated via UAC — needed because a mapped network share used to start the tool is no longer reachable once the process elevates.

Every file type behaves differently on purpose.

File type	Behavior
.rdl — Reports	Always overwritten
.rds / .rsds — Data sources	Existing connections are preserved; new ones are created
.rsd — Shared datasets	Always overwritten
.pbix — Power BI reports	Power BI Report Server only; deleted and recreated on redeploy

On connect, the tool queries the target's /api/v2.0/System endpoint and checks the reported product name. If it's Power BI Report Server, .pbix deployment is enabled; on plain SSRS, those controls stay visible but disabled — no separate build or configuration needed for either target.

Point it at a folder, review, deploy.

1. ConnectEnter the server URL and connect with Windows authentication, or check the box to supply a username and password manually. The tool auto-detects http vs. https and SSRS vs. PBIRS.
2. Choose a source folderBrowse to the local folder containing your .rdl/.rds/.rsds/.rsd/.pbix files.
3. Pick or create a target folderThe server's folder tree loads on the left; right-click to create a new folder without leaving the tool.
4. Review the scanned filesA checklist shows every file found, with type, size, and last-modified date — select or deselect individually, or use Select All/None.
5. DeployA progress bar tracks the run; the log pane reports CREATED/UPDATED/SKIP/ERROR per file, and can be cleared or saved.

SSRS to Power BI Report Server, without a scratch rebuild.

The Migration tab connects to a source and a target server side by side, each with its own folder tree. Migration always runs in two phases through a local staging directory — never directly server to server — so the exported content can be inspected, or the run aborted, before anything reaches the target.

Step	What happens
1. Connect both servers	Source and target each get their own URL, credentials, and folder tree
2. Choose an export directory	A local staging folder where the source content is written
3. Export	Folders, reports, data sources, and shared datasets are pulled from the source server, preserving the folder structure
4. Map connection strings (optional)	A grid of old-value/new-value pairs rewrites data source connection strings during export — e.g. pointing a data source at the new PBIRS host
5. Deploy to the target	The exported, remapped content is redeployed onto the target server, following the same overwrite rules as a normal deploy

Windows auth by default, manual credentials when you need them.

Windows authentication	Default — no configuration, works for on-premise SSRS or PBIRS in the current domain
Manual credentials	A checkbox reveals username/password fields, for accounts outside the current domain

Why it's built this way.

Two APIs, deliberately

Report, data source, dataset, and Power BI report uploads go through the SSRS REST API v2.0. Folder creation and rebinding a folder of reports onto a shared data source use a SOAP proxy against ReportService2010.asmx instead — the REST API doesn't expose an equivalent for that operation cleanly, so both are used where each is the right tool.

RDL namespace fix

Some older .rdl files are missing the xmlns:df namespace declaration that current SSRS expects, which otherwise fails silently on upload. The tool detects and adds it in memory before the upload — the original file on disk is never modified.

Certificates

TLS 1.2 is explicitly enabled at the process level, so the tool works against self-signed or internally-issued certificates that a default PowerShell session would otherwise reject.

Bilingual interface

The entire GUI, including live log messages, switches between English and German from a single button — useful in mixed-language teams without maintaining two builds.

Free to use.

SSRS Deployment Tool is released under the MIT License — no trial, no activation. Same posture as ReportServerCheck; unlike SSIS Analyzer, this one isn't a licensed product.

Deploy the diagnostics next.

Once a report server is reachable, this is the tool that gets content onto it — including the diagnostic report pack documented elsewhere on this site.