Most of the energy in an SSRS migration goes into two things: getting the RDL to render faithfully, and converting the embedded T-SQL to PostgreSQL. Both matter. But there's a third thing that quietly decides whether users experience the migration as an upgrade or a downgrade — and it has nothing to do with how a single report looks. It's how reports get to people.
SSRS didn't just render reports on demand. It ran reports that took minutes, and it delivered reports on a schedule through subscriptions. Drop those two capabilities and you've handed users a faithful renderer that times out on their biggest report and makes them re-run their Monday report by hand. So we built both into ReportBridge.
The two assumptions interactive tools make
Dashboards and interactive analytics quietly assume that every report is (a) fast enough to run while you watch and (b) fresh enough to render live every time. Operational reporting violates both:
- Some reports are slow. A wide regulatory extract or a multi-hundred-page packet can run far past any reasonable synchronous window. Render it live and it hits a gateway or browser timeout; users retry, add load, and still get nothing.
- Some reports are expected on a schedule. The nightly reconciliation, the month-end packet, the Monday compliance report. SSRS subscriptions pre-rendered these so they were waiting. Without them, every user re-runs the same expensive query independently.
Capability one: async background rendering
The fix for slow reports is to take them off the request path entirely. Instead of holding a connection open and hoping the report finishes before something upstream gives up, ReportBridge hands long-running reports to a dedicated render worker. You trigger the report, the work runs in the background, and the viewer polls for completion and notifies you when the result is ready.
From the user's side it's a "Render in background" action and a status that resolves to a finished report — no spinning tab, no timeout, no lost work if they navigate away. From the platform's side, the heavy work is isolated on a worker sized for it, so one slow report can't starve the interactive path everyone else is using.
Capability two: scheduled snapshots
Subscriptions are the other half. ReportBridge lets you schedule a report from the admin app: pick a cadence, and a cloud scheduler renders the report on that timetable against your live PostgreSQL data, storing each result as a snapshot. Users open the most recent snapshot instantly instead of waiting for a fresh render — exactly the SSRS subscription experience, rebuilt for a PostgreSQL backend.
The one thing we refused to leave implicit is data freshness. A pre-rendered report is only useful if people know how current it is, so the viewer shows a last-refreshed banner on every snapshot. Nobody mistakes this morning's numbers for last week's, and nobody mistakes a snapshot for a live query.
Access control doesn't get a side door
Both paths run through the same Domo group-based access control as interactive reports — enforced server-side, fail-closed. A scheduled snapshot or a background render is only visible to users whose groups already have access to that report. This sounds obvious, but it's exactly the kind of thing a bolt-on scheduling feature gets wrong: pre-rendering a report must never quietly widen who can see it. In ReportBridge the delivery mechanism is downstream of the same authorization check, not parallel to it.
What we deliberately didn't build (yet)
The dedicated render worker comfortably handles routine long-running reports. Reports that need to run for truly extreme durations would want a heavier worker tier, and that's on the roadmap — deferred on purpose until a real workload needs it rather than built speculatively. The honest version of "we support long-running reports" includes naming the ceiling and the plan for raising it, instead of implying there isn't one.
What this means for an SSRS migration
If you're scoping an SSRS replacement, put these on the checklist alongside rendering fidelity and SQL conversion:
- Inventory your slow reports and your subscribed reports separately from the rest. They're the ones a rendering-only migration silently breaks.
- Confirm the replacement runs heavy reports off the request path — not just "faster," but genuinely asynchronous.
- Confirm scheduled delivery exists and that snapshot freshness is visible to end users, not buried in an admin log.
- Confirm access control applies to scheduled and background output the same way it applies to live reports.
Get those right and the migration reads as an upgrade: same workflows, same delivery expectations, no SQL Server or Windows Server to license underneath. Get them wrong and the most faithful RDL renderer in the world still feels like a step backward.
FAQ
Why aren't subscriptions just a nice-to-have?
Because for a large class of operational reporting, the schedule IS the product. The Monday morning compliance report, the nightly reconciliation, the month-end regulatory packet — users expect those waiting for them, already rendered. SSRS subscriptions did this for two decades. If a migration drops them, every user goes back to manually re-running the same expensive query, and the organization feels the replacement as a downgrade no matter how faithful the rendering is.
What counts as a 'long-running' report?
Anything that can't reliably finish inside a synchronous request window. A wide date-range extract, a multi-hundred-page packet, a report joining several large tables. Rendered live, these hit browser or gateway timeouts; users retry, pile on database load, and still get nothing. Moving them off the request path — render in the background, notify when ready — is the only robust answer.
How is a scheduled snapshot different from just caching?
A cache is opportunistic and tied to a request; a scheduled snapshot is deliberate and tied to a timetable. The platform renders the report on the cadence you set, against live PostgreSQL data, and stores the result regardless of whether anyone asked for it. Users then open the most recent snapshot instantly, and a last-refreshed banner makes the data's age explicit so nobody mistakes a Monday snapshot for live numbers.
Does scheduling or background rendering change who can see a report?
No. Both paths run through the same Domo group-based access control as interactive reports, enforced server-side and fail-closed. A snapshot or a background render is only visible to users whose groups already have access to that report. Pre-rendering never widens the audience.
What about reports that need to run for a very long time?
The dedicated render worker comfortably covers routine long-running reports. Reports that need to run for extreme durations are on the roadmap via a heavier worker tier, deferred until a real workload needs it rather than built speculatively. If you have an extreme case, raise it during onboarding and we'll confirm the fit before you migrate it.
Async background rendering and scheduled snapshots ship in ReportBridge today. See the scheduled & long-running reports overview, or read the changelog for the full release notes.
Try ReportBridge for your migration