5 Manual-Correction Tools Every RDL Migration Needs

Automated T-SQL conversion for SSRS migrations is a solved problem — right up until you hit the last 15%. That tail of queries is where migrations stall, schedules slip, and "we'll finish it next sprint" turns into next quarter.

The failure modes in the last 15% don't have a common root. They're a long tail of domain-specific patterns: recursive CTEs, cross-database joins, custom functions, deprecated T-SQL features. You can't prompt-engineer your way out. The only practical answer is a fast human-in-the-loop editor.

Here are the five tools we built into the ReportBridge admin UI after watching real migration teams spend days on problems that should have taken minutes. If you're building your own pipeline, these are the affordances that move the needle.

1. Editable T-SQL and PostgreSQL side-by-side

Every failed conversion should show the original T-SQL and the AI's attempt, both editable in place. Not read-only panels — actually editable, so a domain expert can fix the PostgreSQL directly without re-triggering the full conversion pipeline.

┌──────────────────────┬──────────────────────┐
│ Original T-SQL       │ Converted PostgreSQL │
│ (editable)           │ (editable)           │
│                      │                      │
│ WITH RECURSIVE_PARTS │ WITH parts AS (      │
│ AS (                 │   SELECT ...         │
│   SELECT ...         │   UNION ALL          │
│   UNION ALL          │   SELECT ...         │
│   SELECT ...         │ )                    │
│ )                    │ SELECT * FROM parts  │
│ SELECT * FROM parts  │                      │
└──────────────────────┴──────────────────────┘
      [Re-validate]   [Save]   [Revert]

Why editable on both sides? Sometimes the bug is in the original T-SQL — a hardcoded server name, a reference to a retired table. Letting users fix the source side and re-convert is faster than reverse-engineering the PostgreSQL back.

2. RDL XML viewer

Sometimes the problem isn't the SQL at all. It's a hardcoded parameter default in the RDL, a custom assembly reference, or a report-level expression that references a retired shared dataset. Without a view of the raw RDL XML, you're guessing.

<ReportParameter Name="Fiscal">
  <DataType>String</DataType>
  <DefaultValue>
    <!-- Hardcoded reference to a dataset
         that no longer exists in target -->
    <DataSetReference>
      <DataSetName>RetiredLookup</DataSetName>
      <ValueField>value</ValueField>
    </DataSetReference>
  </DefaultValue>
</ReportParameter>

Expose the XML. Don't try to parse it into a pretty editor — let people read the raw structure. Migration engineers already know RDL; they don't need a beginner view.

3. Fix-hint panel

When a conversion fails, pattern-match the error against a known taxonomy and show a one-sentence hint. Not an LLM suggestion — a deterministic lookup. Hallucinated fix suggestions waste more time than they save.

ERROR CATEGORY         → HINT
──────────────────────   ─────────────────────────────
recursive_cte_missing  → PostgreSQL requires the
                         RECURSIVE keyword on the WITH
cross_db_reference     → Target schema has no cross-
                         database routing. Remove
                         [OtherDb].[dbo]. prefix.
reserved_word          → Identifier collides with a
                         PostgreSQL reserved word.
                         Run scrub or quote manually.
stripped_alias         → Subquery is missing LIMIT 1.
                         Returns wrong answer silently.
type_mismatch_varchar  → VARCHAR(MAX) → TEXT; cast
                         required on comparison.

Build the taxonomy from real failures. Don't guess at what the hint should be — categorize 100 real errors first, then write hints for the categories that show up more than twice.

4. One-click deterministic post-processing

Some fixes are mechanical. Reserved-word quoting, double-quote vs square-bracket identifier swap, GETDATE → NOW. These should be buttons, not prompts. Let a user apply them with one click after any manual edit.

[Scrub reserved words]
  Identifies PostgreSQL reserved-word collisions
  in the current query and quotes them.
  Deterministic. Idempotent. Safe to run twice.

[Normalize date functions]
  GETDATE() → NOW(), DATEADD → INTERVAL, etc.

[Strip T-SQL hints]
  Removes WITH (NOLOCK), OPTION (RECOMPILE), and
  other query hints that have no PG equivalent.

The test for "is this a button?": if you can write the transformation as a pure function from input string to output string with no judgment calls, it's a button. If there's any "it depends," it stays in the editor.

5. History with one-click revert

Every save creates a version. Every version is a one-click revert away. This sounds obvious — but it's the tool that makes migration teams willing to experiment.

History for: MonthlyFinancialSummary.rdl
─────────────────────────────────────────────
v5  2026-04-22 14:22  "manual alias fix"      [revert]
v4  2026-04-22 14:10  AI conversion v2        [revert]
v3  2026-04-20 09:45  reserved-word scrub     [revert]
v2  2026-04-20 09:32  AI conversion v1        [revert]
v1  2026-04-15 11:02  original T-SQL import   [revert]

Without versioning, a failed experiment means pulling the RDL from source control and re-running the pipeline. With versioning, it's one click. The difference shows up in completion rate, not just speed: people tolerate risk differently when rollback is free.

The economics

A typical report library has 200-1000 reports. At an 85% automated pass rate, 30-150 reports need manual attention. Without the five tools above, each is a 30-60 minute round-trip through dev tools, diff viewers, and source control. With the tools, it's a 5-10 minute fix in a single pane.

That's the difference between a 40-hour manual phase and a 6-hour one. It's also the difference between a migration that ships and one that stalls at 85% complete.

FAQ