Before you can pick a migration path, or decide whether to move at all, you need to know what you actually have. Most SSRS estates have never been fully counted. Reports accumulate over a decade, ownership changes hands, and the report server catalog grows quietly in the background. This is the inventory that precedes every other decision, including the one covered in which T-SQL constructs will need attention.
What to Count
Six things, and the report count alone is not enough:
- Reports. The obvious starting point, and usually the number everyone already has a rough guess for.
- Datasets. One report can hold several, each with its own query. Effort scales with datasets more closely than with reports, a twelve-dataset report is not the same size of job as a one-dataset report, even though both count as "one report."
- Shared data sources. Connections referenced by name across many reports. A single shared data source pointing at a decommissioned server quietly breaks every report that uses it.
- Subscriptions. Standard and data-driven, each configured separately per report. This is consistently the most undercounted item, because subscriptions live in the report server catalog, not in any RDL file you can just open and read.
- Subreports. Reports that embed other reports. Each one is a separate RDL file and a separate dependency to migrate and re-link, and missing one breaks the parent report silently until someone runs it.
- Parameters. Every parameter is a piece of UI, a validation rule, and often a cascading dependency on another parameter's dataset. Parameter-heavy reports take longer to migrate than their dataset count alone would suggest.
Where the Bodies Are Buried
Four things a simple report count will never surface, and each one has derailed a migration before:
- Duplicate names. The same report name appearing in more than one folder, often a copy made for a one-off request that was never cleaned up. Bulk tooling that keys off report name rather than a stable identifier silently merges or overwrites these.
- Broken references. A shared dataset pointing at a data source that no longer exists, a subreport reference to a report that was renamed or deleted. These sit invisible until the report is opened, and in a stale estate, some reports have not been opened in years.
- Dynamic SQL. Query text assembled and executed from a string at runtime cannot be read statically by any scanner. Each instance has to be counted as a signal and priced for a human to read, not assumed convertible.
- A 60-day execution log. SSRS's execution log, the record of who ran what and when, defaults to 60 days of retention. An annual report or a statutory filing that runs once a year will show zero executions in that window and look dead when it is not. Usage data needs that caveat attached every time it is used to decide what to retire.
How to Actually Run the Count
Two ways to get a real inventory from your .rdl files, both reading the files only, neither touching your database or your report data:
- The free scan, in your browser. Point the free assessment at your .rdl files and it runs entirely on your own machine. Nothing uploads. You get report and dataset counts, complexity tiers, and the known-hard T-SQL constructs present, in about a minute.
- The offline scanner, for the security-conscious. Download rdl-scan.mjs and run it locally with Node. It opens no network sockets and produces the identical classification the browser tool does, for teams that would rather not point a browser at report definitions at all.
Both cover what lives in the RDL files themselves: reports, datasets, shared data sources referenced by name, subreports, parameters, and every T-SQL construct in the query text. Neither can see what only lives in the report server catalog: real subscription counts, execution history, or the security model. That is the gap a professional assessment closes, with a dependency map covering shared data sources, shared datasets, subreports, and broken references, and a blocker register that counts custom assemblies, dynamic SQL, linked servers, cross-database queries, and multi-value parameters by name.
What a Complete Inventory Actually Gets You
An inventory is not the deliverable, it is the input to every decision that follows: which migration path fits, what order to move reports in, which ones to retire before you migrate at all, and whether to act now or wait. Skipping it does not remove the work, it just moves the surprises to the middle of the project instead of the start.
Steve Harlow is the founder of ReportBridge. He inventoried and migrated nearly 200 paginated reports for a multi-jurisdictional regulatory program, duplicate names, broken references, and all. Questions? steve@report-bridge.com