Subscriptions are the part of an SSRS estate that gets planned for last and costs the most to skip. They are also, based on migration experience, the most common cause of migration overrun. If you have not yet counted how many you have, start with the inventory, subscriptions live in the report server catalog, not in any single RDL file, so a files-only scan will not find them for you.
Subscriptions Transfer to No Target
Say it plainly: subscriptions transfer to no target. They are not a checkbox in a migration tool, and no platform on the comparison list, including staying on the Microsoft stack, moves your existing subscriptions over unchanged. A subscription is a schedule, a set of parameters, and a delivery instruction, all three defined against the specific catalog item and specific report server they were created on. Move the report and none of those three definitions come with it automatically.
This is not a ReportBridge-specific gap. It is why subscription rebuild work belongs in every migration estimate, on every target, as its own line item rather than an assumed extra of moving the report itself.
What Rebuilding a Subscription Actually Means
Four separate pieces, and a plan that only covers one or two of them is not a complete plan:
- Schedule. SSRS drives subscriptions off SQL Server Agent. Whatever runs the report on your new platform needs its own scheduler, cron or otherwise, and every cadence, daily, weekly, month-end, needs to be re-entered by hand or migrated deliberately, not assumed to carry over.
- Rendering. The report has to actually execute on the new platform with the right parameters at the right time. For a fast report this is trivial. For the wide regulatory extract that runs for minutes, it is not, a synchronous request that used to be fine on a schedule can time out the moment a person triggers it live.
- Delivery. Where the output lands changes the shape of the rebuild entirely. Email attachment, a network file share, or a link a user opens in a viewer are three different engineering problems, and SSRS supported the first two as first-class options that most modern report viewers do not replicate by default.
- Failure alerting. SSRS subscriptions fail silently more often than any other part of the platform, and nobody notices until a compliance deadline is missed and someone asks why the Monday report never arrived. Whatever replaces subscriptions needs its own answer to "how do we find out a scheduled run failed, rather than finding out a report never arrived." This is a planning question every rebuild has to answer for itself; it does not come free with any platform.
How ReportBridge Approaches Scheduling and Long-Running Reports
ReportBridge addresses the schedule and rendering pieces directly. Heavy reports run through async background rendering, a dedicated render worker executes the report and the viewer notifies you when the result is ready, instead of a browser tab waiting on a live request. Recurring reports use scheduled snapshots, a report pre-renders on a cron timetable against your live PostgreSQL data, and the viewer carries a last-refreshed banner so nobody has to guess whether they are looking at this morning's numbers or last week's. Both paths use the same Domo group-based, fail-closed access control as interactive reports, scheduling a report never widens who can see it.
The honest distinction to plan around: this is a pull model, the user opens the viewer and gets the freshest snapshot instantly, not SSRS's push model of emailing a rendered file on a schedule. If part of your subscription workflow exists specifically to land a file in an inbox or a shared folder rather than to have a fresh report waiting when someone opens it, that is a real gap to plan for, not a detail. See the full scheduled reports capability for the complete picture, including current availability status.
Steve Harlow is the founder of ReportBridge. He rebuilt subscription and scheduling workflows for a multi-jurisdictional regulatory program during an SSRS migration of nearly 200 paginated reports. Questions? steve@report-bridge.com