Migrating off SSRS, from RDL and tablix to markup

What ports and what does not

The datasets, which are SQL and which carry across directly. The RDL does not: it is XML, so it is at least readable, but the tablix is a single control doing the work of a table, a matrix and a grouped list at once, and unpicking which of those a given report is using is the first task. The larger question is the report server itself, because SSRS was never only a renderer. Subscriptions, scheduled delivery, the report portal and access control all live there, and a rendering API replaces one part of that.

What the call becomes

The report execution web service call, or a ReportViewer render, becomes a POST to /v1/pdf with html. Report parameters become template inputs. Everything the report server did around the render, scheduling, emailing, snapshotting, has no counterpart and needs somewhere else to live, which is the part of this migration to scope honestly before starting.

Side by side

The old shape and the new one, with the parts that have no counterpart called out in comments rather than quietly omitted.

// Before: rendering through the report server
byte[] pdf = rs.Render("/Invoices/Invoice", "PDF", null, deviceInfo,
                       parameters, null, null, out _, out _, out _, out _, out _);

// After
var payload = JsonSerializer.Serialize(new {
    html = RenderInvoice(dataset, totals),
    options = new { format = "A4" }
});
var resp = await http.PostAsync("https://api.pdfpipe.xyz/v1/pdf",
    new StringContent(payload, Encoding.UTF8, "application/json"));

/* Scope the report server's other jobs before committing:
     subscriptions and scheduled delivery -> a scheduler in your stack
     emailing a rendered report           -> your own mail path
     the report portal                    -> wherever users get it now
     row-level access control             -> your application's authz
     snapshots and history                -> document storage; this API
                                             has /v1/documents and
                                             /v1/retrieve for storing
                                             rendered output

   The tablix translates by which mode it is in:
     table mode  -> a table with thead and tbody
     matrix mode -> a table built from a pivoted dataset, pivoted in
                    your query rather than by the control
     list mode   -> a repeated block per row                          */

The CSS delta, in both directions

What the old engine accepted that a current one does not, and what it refused that a current one wants. The second direction is the one people forget, and it is where the value of the migration is.

• Nothing to migrate. The RDL's style properties are readable XML and transcribe into CSS with effort but no ambiguity.
• Tablix grouping becomes headings and subtotal rows with break rules, the same as any grouped report.
• A matrix tablix is the awkward one: the control pivoted the data itself, and the replacement is to pivot in the query, which changes the dataset rather than the markup.
• Page setup in the RDL becomes options.format and options.margin.

What changes without anything erroring

The dangerous list. Each of these produces a different document and no diagnostic, so none of them are caught by a test that only checks the render succeeded.

• Everything visual, because it is a rebuild.
• Expressions in the RDL, which stop evaluating and take derived fields, conditional visibility and aggregates with them.
• Anything the report server was doing on a schedule, which stops happening rather than failing, and which nobody notices until somebody asks where the monthly report went.
• Page count.

What to diff before cutting over

Compare the numbers over the same parameters, and separately make a list of every subscription configured on the server. That list is the part of the migration that is not about documents at all, and it is the part most likely to be forgotten.

The one thing that always breaks

The subscriptions. The report renders, the new pipeline works, and the scheduled deliveries that were configured in the report portal years ago silently stop. Nobody is watching the report server once the reports have moved, so the first sign is a person asking why they no longer receive something.

Frequently asked

Other migrations

The nearest neighbours first, then others that started from the same kind of tool, because the model matters more than the language.