Anatomy of a Validated Migration

"It converted" is not a claim worth much on its own. A query can convert, run without error, and still return the wrong answer, which is the failure mode that actually hurts a migration. Here is what "converted" means in our pipeline, stage by stage, and where each stage stops short of proving something it does not prove. If you have not yet run the construct scan that decides which of your queries reach this pipeline cleanly, see the 10 conversion gotchas first.

Stage 1: Static Assessment, Before Anything Runs

Before a query is converted at all, the free assessment classifies it from the .rdl file alone, which T-SQL constructs it contains, auto-convertible or known-hard. This stage is honest about its own ceiling: it is a static scan, not a guarantee and not a quote. It cannot see your data volume, schema drift, collation behaviour, or what is hidden inside a stored procedure. That is exactly why the estimate it produces is a range, capped well below 100%, rather than a single confident number.

Stage 2: Automated Conversion, Up to Three Fix Rounds

The AI conversion pass rewrites the T-SQL for PostgreSQL syntax using your live schema as context. When the first attempt fails, the pipeline does not stop there: the converted SQL is tested via EXPLAIN against your live PostgreSQL database, the error is fed back to the AI for correction, and this loop runs up to three times per query before a dataset is either accepted or flagged for a human.

Stage 3: EXPLAIN Plus a LIMIT 1 Execution

A dataset counts as converted when its generated PostgreSQL passes an EXPLAIN plan check plus an actual LIMIT 1 execution against a live database. This is a real run, not a syntax check, it proves the query plans and executes. It does not prove the results match SQL Server. Those are two different claims, and conflating them is exactly the kind of mistake that lets a silently wrong report ship.

Stage 4: The Parity Check

Once a query executes cleanly, it still has to agree with the original. The parity check runs the report against both SQL Server and PostgreSQL and compares total row counts for exact equality, plus a cell-by-cell diff of a sample of rows. You see exactly which reports match and which need manual attention before cutover, not a guess based on the fact that the query ran without an error.

Stage 5: Frozen, Verified, Locked

Once a conversion passes and is verified, it is frozen: the converted SQL is hash-locked so a later pipeline change or model update cannot silently alter a query that already works. This is what turns validation into something durable rather than a one-time check. A report that passed six months ago is still running the exact SQL that passed, not a fresh reconversion that happens to look similar.

What 95.8% Actually Measures

"Effective conversion rate" counts report datasets, the individual SQL queries inside an RDL, of which one report can have several, not whole reports. A dataset counts as converted when its generated PostgreSQL passes the EXPLAIN plan check and the LIMIT 1 execution described in Stage 3, after the automated fix rounds in Stage 2. Ours is 317 of 331 scorable datasets across a 190-report production library. It measures whether the query runs, not that its results match SQL Server row for row, that is Stage 4, a separate step. It is our historical rate on our own library, not a prediction for your estate.

What Even This Does Not Prove

Five stages of validation is not the same as zero risk, and pretending otherwise would be exactly the overclaim this whole pipeline exists to avoid. The Stage 1 estimate is static and cannot see your data volume or schema drift. The Stage 4 parity check samples rows rather than comparing every one. And none of it validates business logic that lives outside the query itself, a downstream calculation, a display rule, a report that is "correct" only because someone with domain knowledge says so. Validation narrows where the risk can hide. It does not remove the need to look.