Sample Estate Report
This is the Estate Report deliverable, section for section, run against a real set of RDL files. It exists so you can see exactly what 11 reports of analysis looks like before you pay for 40 or more.
Read this before you read the numbers
This report was generated from the ReportBridge public demo estate: the same AdventureWorks sample reports the live demo serves. It is not a customer estate, and no customer files were used to build it.
The estate is 11 reports. That is small. A typical engagement runs from 40 reports into the hundreds, so every count on this page is smaller than the one you would receive, and the sections that depend on volume, such as the most expensive reports, are correspondingly thin. The structure is identical. The scale is not.
Every figure below is live output of the same analyzer behind the free scan, run over the 11 files listed at the foot of this page. Nothing is estimated, rounded, or illustrative. A test in our build re-runs the scan and fails if any number here stops matching.
Estate at a glance
11
Reports analyzed
18 / 18
Datasets / queries
9
Report parameters
12 / 4
Data regions / charts
2
Broken report references
2
Blocker classes with findings
Complexity tiers
- Simple9
- Moderate1
- Complex1
Tiers are scored against the same published rubric the free scan uses, so a number here means the same thing as a number there.
Estimated auto-conversion band
90 to 95 percent
1 report likely needs a human, costing 2 to 3 dev-days at rebuild rates. A full manual rebuild of all 11 would run 22 to 33 dev-days.
The band is deliberately wide because the sample is small. The rubric widens it by 4 points for every report short of 10, and caps the top at 95 percent because a static scan never justifies an absolute claim.
1. Full inventory with complexity tiers
Every report, scored and tiered. The outlook column is the analyzer’s own read: clean means no hard signals, review means exactly one, manual means a blocking construct or two or more hard signals.
| Report | Tier | Score | Datasets | Params | Regions | Charts | Actions | Outlook |
|---|---|---|---|---|---|---|---|---|
| Product Line Sales | Complex | 18 | 4 | 4 | 2 | 2 | 3 | Review |
| Employee Sales Summary | Moderate | 9 | 4 | 3 | 1 | 2 | 1 | Clean |
| Sales Order Summary | Simple | 2 | 1 | 2 | 1 | 0 | 0 | Clean |
| Employee Department History | Simple | 1 | 2 | 0 | 1 | 0 | 0 | Clean |
| Product Catalog | Simple | 1 | 1 | 0 | 1 | 0 | 1 | Clean |
| Territory Sales Drilldown | Simple | 1 | 1 | 0 | 1 | 0 | 1 | Clean |
| Company Sales | Simple | 0 | 1 | 0 | 1 | 0 | 0 | Clean |
| Connection Test | Simple | 0 | 1 | 0 | 1 | 0 | 0 | Clean |
| Customer Demographics | Simple | 0 | 1 | 0 | 1 | 0 | 0 | Clean |
| Product Inventory | Simple | 0 | 1 | 0 | 1 | 0 | 0 | Clean |
| Purchase Order Summary | Simple | 0 | 1 | 0 | 1 | 0 | 0 | Clean |
| 11 reports | 9 / 1 / 1 | 18 | 9 | 12 | 4 | 10 clean, 1 review, 0 manual |
The spreadsheet appendix in a paid engagement carries these columns plus per-report construct lists, file sizes, and the raw analyzer output for every file.
2. Dependency map
Data sources, datasets, drillthrough targets and parameters were read from the RDL XML directly, then every drillthrough target name was matched against the estate's report names.
Shared data sources
AdventureWorks
Shared reference, used by 11 of 11 reports
Every report in the estate points at one shared data source by reference. No report carries an embedded connection string, so there is exactly one connection to re-point and zero credentials sitting inside the RDL files.
- 0 embedded connection strings. Nothing to scrub before the files leave the building.
- 0 shared dataset references. Every one of the 18 datasets is defined inside the report that uses it, so there is no shared-dataset layer to migrate separately.
Report-to-report references
0 embedded subreports. 4 drillthrough actions, of which 2 resolve inside the estate and 2 do not.
- Product Line Sales drillthrough Employee Sales Summary
- Product Line Sales drillthrough Employee Sales Summary
- Employee Sales Summary drillthrough Sales Order Detail (not present in the estate)
- Territory Sales Drilldown drillthrough Sales Order Detail (not present in the estate)
The finding that matters. 2 reports drill through to a report named Sales Order Detail that does not exist in this estate. On any target, that link is dead the moment a user clicks it.
The estate answers this itself. Sales Order Summary carries this line in its own description:
Replaces the legacy Sales Order Detail demo whose AW 2008 SOH.ContactID path was removed in the 2016 schema.
So the target is not misplaced, it was deliberately retired, and there is nothing to go and fetch. The fix is to repoint both actions at Sales Order Summary, which is already in the estate, or to retire the actions if the drillthrough is no longer wanted. Reading the description turns an unresolvable dead link into a one-line change, and that is the difference between a broken-reference list and a dependency map.
A bulk migration tool moves both reports successfully and reports success, because nothing about the files is invalid, and it has no way to find the successor. This is the class of defect a dependency map exists to catch.
3. Duplicate name findings
Names were compared case insensitively, and file contents were compared with a SHA-256 hash over CRLF-normalised bytes.
In the analyzed estate
- 0 duplicate report names across the 11 analyzed files.
- 0 colliding report identifiers.
Zero is the honest answer for a curated estate this small, and it is printed rather than omitted so the section shape is visible either way.
What the check catches, from this same directory
The demo directory these files came from holds 4 more files that were excluded from this sample. Each one is byte identical to a report above once line endings are normalised, and each carries a decorated file name rather than a matching one:
- train-Company Sales - Copy.rdl copies Company Sales.rdl
- train-Connection Test - Copy.rdl copies Connection Test.rdl
- train-Customer Demographics - Copy.rdl copies Customer Demographics.rdl
- train-Product Catalog - Copy.rdl copies Product Catalog.rdl
They are training duplicates, kept deliberately for internal pipeline work, so counting them as estate reports would inflate every figure on this page. They are also a precise illustration of why name matching alone is not enough: a check that compares names finds nothing here, and a check that compares content finds all 4. Real estates accumulate exactly this pattern through folder copies and archive directories, and a bulk migration tool will happily migrate every copy.
4. Blocker register
Blocker counts come from the analyzer's construct table for the T-SQL classes, and from direct element counts for the RDL classes. Both methods are named per row. 2 of 16 classes carry a finding in this estate and 14 are at zero. Zero rows are printed, not dropped. A register that only lists what it found tells you nothing about what it looked for.
| Blocker class | Count | Finding |
|---|---|---|
| Custom assemblies | 0 | No external .NET assembly is referenced anywhere, so nothing here forces a platform that can host one.Method: `<CodeModule>` elements across all eleven files. |
| Custom code blocks | 1 | Product Line Sales declares `<Code />`, an empty, self-closing element with no VB.NET inside it, and no expression in the report calls `Code.` anything. The scan is deliberately conservative and flags it as custom code, which is what pushes that report into the Complex tier and into the review column. Reading the file is what turns that flag into a finding, and this is precisely the difference between a free scan and a paid read.Method: `<Code>` elements, which is what the analyzer counts as custom VB.NET code. |
| Dynamic SQL | 0 | Nothing in this estate assembles a query at runtime, so there is no query text that static analysis cannot see.Method: Analyzer construct `dynamic-sql`: sp_executesql, EXEC of a string, or EXEC of a variable. |
| Linked servers | 0 | No cross-server reference exists in any query.Method: Analyzer construct `linked-server`: OPENQUERY, OPENROWSET, OPENDATASOURCE, or a four-part name. |
| Cross-database queries | 0 | Every query addresses schema-qualified objects such as Sales.SalesOrderHeader inside a single database.Method: Three-part object names following FROM or JOIN, over comment-stripped and literal-stripped query text. |
| Multi-value parameters | 1 | The ProductSubcategory parameter on Product Line Sales. Multi-value parameters survive a move to any RDL host, but they change the shape of the generated predicate on a conversion path, so they are counted rather than assumed.Method: `<MultiValue>true</MultiValue>` elements across all eleven files. |
| Stored-procedure datasets | 0 | Every dataset carries its own SQL text, so nothing sits in a procedure body outside the files.Method: CommandType StoredProcedure datasets plus static EXEC calls in query text. |
| Cursors | 0 | None.Method: Analyzer construct `cursor`. |
| Temp tables and table variables | 0 | None.Method: Analyzer construct `temp-table`. |
| PIVOT and UNPIVOT | 0 | None.Method: Analyzer constructs `pivot` and `unpivot`. |
| Recursive CTEs | 0 | None.Method: Analyzer construct `recursive-cte`, including self-referencing CTEs written without the RECURSIVE keyword. |
| CROSS APPLY and OUTER APPLY | 0 | None.Method: Analyzer construct `apply`. |
| MERGE statements | 0 | None.Method: Analyzer construct `merge`. |
| FOR XML and FOR JSON | 0 | None.Method: Analyzer construct `for-xml-json`. |
| Subreports | 0 | Zero embedded subreports. The 4 report-to-report dependencies in this estate are drillthrough actions, which are listed in the dependency map instead.Method: `<Subreport>` elements. |
| Embedded connection strings | 0 | Every report uses the shared data source by reference. Nothing to scrub before the files leave the building.Method: `<ConnectString>` elements. |
Auto-convertible T-SQL found, by reports affected
Listing what converts cleanly is as much a part of the register as listing what does not. It is the half of the picture that tells you the estate is ordinary.
5. Readiness verdict per candidate target
The same five targets every assessment evaluates, each judged on the evidence above rather than on what we sell. One of these verdicts rules us out.
Stay on SSRS
Defensible. Nothing in the files forces a move.
Zero known-hard T-SQL constructs, zero stored-procedure datasets, one shared data source, and 9 of 11 reports in the Simple tier. There is no technical decay signal here at all. SSRS 2022 carries security patches through January 11, 2033, so the decision is a cost and platform-strategy decision, not a feasibility one. An estate this clean should be priced against the alternatives before anyone moves it.
Power BI Report Server
Lowest friction of the five.
All 11 files use the RDL 2005 schema, which the same rendering engine reads unchanged. The work is deployment plus re-pointing one shared data source, not report rework. Two things travel with the estate rather than being fixed by the move: the empty custom-code element on Product Line Sales, and the 2 drillthrough actions pointing at a report the estate retired. Both remain exactly as broken on the new server.
Power BI Service
Viable, with two named prerequisites.
Paginated reports in Fabric accept these files, and the single multi-value parameter is supported. The prerequisites are concrete. First, the shared data source is a by-reference connection that has to become a cloud connection or run through a gateway. Second, drillthrough targets have to exist in the same workspace, so the 2 actions aimed at Sales Order Detail have to be repointed at its replacement, Sales Order Summary, or removed. Capacity licensing is the real cost driver here and file analysis cannot price it.
ReportBridge
Technically a strong fit, and too small to sell to.
The scan puts auto-conversion at 90 to 95 percent with 1 report flagged for a human read, zero known-hard constructs, and no dynamic SQL for the converter to guess at. That is the shape our pipeline handles best. It is also 11 reports. Our own scanner sets its cohort threshold at 40 reports and returns a plain no for this estate, and 22 to 33 dev-days is what a full manual rebuild of all 11 would cost at rebuild rates, which is a small enough number that tooling is hard to justify. We would tell an estate this size to look at the two Microsoft rows above first.
Third-party RDL platforms
No evidence in the files that this estate needs one.
Bold Reports and Telerik Reporting earn their place when custom assemblies or an embedded viewer requirement rule out the cloud path. This estate references zero external assemblies and carries zero embedded connection strings, so the usual reason to reach for them is simply absent. If an application embeds these reports through the SSRS API, that would change the answer, and it is exactly the signal file analysis cannot see.
6. The reports that will cost the most
A paid Estate Report names the twenty most expensive reports individually, with reasons. This estate holds 11, so all 11 are ranked here and the section stops well short of twenty. That is a property of the sample, not of the deliverable.
- 1
Product Line Sales
Complexscore 1853,570 bytes3 extra datasets, 4 parameters (one of them multi-value), 1 extra data region, 2 charts, 3 interactive actions at the scoring cap, and a custom-code element worth 5 points on its own.
- 2
Employee Sales Summary
Moderatescore 943,209 bytes3 extra datasets, 3 parameters, 2 charts, and 1 drillthrough action. No hard T-SQL and no custom code.
- 3
Sales Order Summary
Simplescore 24,541 bytes2 date parameters. 1 dataset, 1 data region, nothing else. This is the report that replaced the estate's missing drillthrough target, which is why it matters more than its score suggests.
- 4
Employee Department History
Simplescore 18,852 bytes1 extra dataset. 0 parameters, 0 charts, 0 actions.
- 5
Product Catalog
Simplescore 1188,706 bytes1 hyperlink action. Largest file in the estate at 188,706 bytes on disk, of which 149,388 characters are the base64 payloads of 6 embedded images. That is storage cost, not conversion effort, and it is the single most common reason a bulk upload hits a size limit.
- 6
Territory Sales Drilldown
Simplescore 126,878 bytes1 drillthrough action, and its target is the missing report named in the dependency map above.
- 7
Company Sales
Simplescore 016,781 bytes1 dataset, 1 data region. Nothing scores.
- 8
Connection Test
Simplescore 03,792 bytesA SELECT 1 connectivity probe. Real estates carry several of these, and they are usually the first retirement candidates.
- 9
Customer Demographics
Simplescore 06,403 bytes1 dataset, 1 data region. Nothing scores.
- 10
Product Inventory
Simplescore 08,150 bytes1 dataset, 1 data region. Nothing scores.
- 11
Purchase Order Summary
Simplescore 07,255 bytes1 dataset, 1 data region. Nothing scores.
Note what the ranking does and does not track. Product Catalog.rdl is by far the largest file at 188,706 bytes on disk, and 149,388 of the characters inside it are the base64 payloads of 6 embedded images. It still scores 1. File size is a transfer and storage problem. Score is a conversion-effort problem. Confusing the two is how migration plans end up sequenced backwards.
How these numbers were produced
Complexity tiers, the auto-conversion band, construct detection and every per-report count come from running the analyzer over the 11 files. Run it yourself against your own estate with the same script the free scan offers for download.
node public/rdl-scan.mjs src/__tests__/fixtures/sample-estateThe 11 files analyzed
- Company Sales.rdl
- Connection Test.rdl
- Customer Demographics.rdl
- Employee Department History.rdl
- Employee Sales Summary.rdl
- Product Catalog.rdl
- Product Inventory.rdl
- Product Line Sales.rdl
- Purchase Order Summary.rdl
- Sales Order Summary.rdl
- Territory Sales Drilldown.rdl
0 files were skipped as unparseable. All 11 use the RDL 2005 schema.
The 4 files prefixed train- in the same directory are excluded because they are duplicate copies kept for internal pipeline training, and counting a report twice would overstate the estate. They are described in section 3 rather than hidden.
Our own scanner sets its cohort threshold at 40 reports and returns a plain no for an estate this size. We have left that verdict in. Run the same scan on your own files, in your browser or offline on your own machine, and compare the shape of your estate against this one.
This, for your estate
Send your RDL files under NDA and receive this report, at your scale, with the twenty most expensive reports named individually.