What this actually is
Most database conversion tools show you the converted SQL and ask you to trust it. Ours instead runs both sides — the query the source system would have answered, and the same query against the converted PostgreSQL schema — and compares every returned cell using its declared type (whole numbers, exact decimals, text, true/false), rather than comparing the SQL text or a loose string match. A decimal that loses precision, a missing row, or a column that quietly changed type is a fail, not a rounding error.
This is a comparator, not a finished migration service. It tells you whether two result sets match. It does not yet write the conversion for you against a real source database, and we have not measured how much of the conversion work it removes.
What has actually been proven45 checks · runner raw exit 0
On 11 Sep 2026 we ran the comparator’s full check set and recorded the raw results, not a summary written after the fact.
- 36 unit checks on the comparison logic itself14 acceptance checks, 18 holdout checks written to try to break it, and 4 command-line checks — equal values, unequal values, missing input, decimals that lose precision, duplicate JSON keys, non-finite numbers, and more. All 36 passed.
- 9 end-to-end checks against a live, disposable PostgreSQL 15.7 databaseReal queries run inside a throwaway, network-isolated PostgreSQL container, then compared cell by cell against the expected result. 6 matched correctly, and 3 were deliberately broken cases — a changed decimal, a missing input, and a mismatched schema — to prove the checker actually catches errors instead of always saying pass. All 9 came back the verdict we expected.
- Test runner: raw exit 0The process that ran all of the above returned success with no suppressed failures.
- A second model reviewed the check code independentlyThat review ran out of turns before finishing and left no written notes, but a smoke re-run of what it did inspect came back raw exit 0. We are not counting this as a finished independent audit.
Every number above is taken from evidence/summary.json and package/run-evidence/results.json, written at the time the checks ran, not typed up afterward.
What has NOT been proven
Real SQL Server execution: UNKNOWN. Every check so far compares a fixture-authored expected result against a live PostgreSQL result. No check has run the equivalent query against an actual SQL Server and compared its real output. We have no authorised SQL Server to test against yet.
A representative customer workload: UNKNOWN. All 45 checks use small synthetic cases we wrote ourselves — totals, ties, month boundaries, empty results. None of them came from a real customer database or a real schema.
Advantage over converting the SQL by hand: UNKNOWN. We have not timed this checker or a model-assisted conversion against a conventional, manual conversion on the same source, so we cannot tell you it saves time or money. No benchmark like that has been run.
A public service, a checkout, a marketplace listing, or a paying customer: none exist. This page is the first public mention of the tool. There is no product to buy yet.
See the real check results
You do not have to take our word for the 9 end-to-end checks. Here are all 9 rows, exactly as the comparator recorded them: the check name, the declared type on each side of the comparison, and whether it matched.
- Open the 9 rows as a CSVThis is a sample of the comparator’s own test results — not customer data, because no customer data has touched this tool. It opens in Excel, Numbers or Google Sheets.
What “source type” and “target type” mean in that file: most rows compare a fixture we wrote against the live PostgreSQL container’s real answer, so the two types usually match on purpose. Three rows were deliberately broken — a changed decimal, a missing input, and a schema that does not match — to prove a wrong answer gets caught rather than waved through.
The six conditions that would put a price on this page
These come from our own frozen benchmark, written before any of this was tested, so we could not move the goalposts afterward. In plain terms:
- Run the checker against a real, disposable SQL Server that a migration owner sets up and authorises, and capture the exact version, exit code and results — not just a normalised comparison, which cannot prove the query actually ran.
- Agree in advance exactly which data types, row orders and edge cases (dates, collation, multiple result sets, errors) are in scope. Today the checker only handles whole numbers, exact decimals, text and true/false.
- Have the workload owner hold back their own hard test cases — nulls, decimal edge cases, ties, month boundaries — rather than let us write every test ourselves.
- Time a conventional, manual conversion of the same workload against the model-assisted one, under the same conditions, and log the setup and correction time honestly for both.
- Compare every in-scope case’s real SQL Server output against the real PostgreSQL output, and deliberately inject a few wrong answers to confirm they get caught, not passed.
- Only move toward a priced pilot once every in-scope case matches, the planted errors are caught, real time savings are measured, and a real buyer agrees the scope and the price — not assumed interest.
Until those six are done, any price on this page would be a promise we cannot back up.
Get involved before there is a price
No pay button on this page. If you own a SQL Server migration and can supply an authorised, disposable copy of the source database plus an anonymised workload, email operations@ustechautomations.com. Say what the source system looks like and what you would want checked. A person replies; nothing is charged.
Email us a test workloadWe will tell you honestly whether we can test against it yet, and what we would still need. This is not legal, compliance or production-migration advice, and running it against a live production system is not something we ask for or want.