Database migration verification · for agentic data migrations
Trust your agent. Verify its migration.
An AI agent can attempt to migrate your data estate to Snowflake or Databricks. The devil is in the details: thresholds, rounding, time zones, late batches, the order that rules run in. Prover AI compares every value the new system produces with what you run today, tells the agent exactly what to fix, and checks again, until the two agree.
Free for one object. Your agent packages its before and after; we send back every place they disagree, with evidence, within 48 hours. Or talk to a person.
Доверяй, но проверяй.Trust, but Prover.
Check
Today
Migrated
Verdict
customer_tier · threshold ≥ 250,000.00, compared before rounding
1,204
1,199
differs
usp_month_end_close · same 31-day input, 14 outputs compared
14 / 14
12 / 14
differs
invoice_total · currency conversion rounded HALF_EVEN, not HALF_UP
18,204.35
18,204.36
differs
shipments · batch stamped after the cutoff, carried into the period
excluded
included
differs
product_category · nine rules applied in order, first match wins
C: 2,310
C: 2,287
differs
dim_customer · slowly changing dimension, one current row per key
48,201
48,201
match
stock_on_hand · dedup on (item, warehouse, as_of), latest count wins
32,814
32,814
match
unit_cost · decimal(18,8) carried without silent truncation
0.12345678
0.123457
truncated
order_status · NULL treated as "unknown", not as "not active"
3,410
3,388
differs
order_ts · stored in local time, read back in UTC
23:30 EDT
03:30 UTC
platform
Ten of the thousand-plus checks in a typical run. Every row count and every column sum matched. What failed was behaviour: thresholds, rounding modes, rule order, late batches, null semantics. Illustrative rows; real ledgers name the object, the rule, and the evidence.
How it works
The agent builds once. Then the loop starts, and that is where the work is.
Writing a first version is quick. Knowing whether it is right, and making it right, is most of the cost. Prover runs that part as a loop between itself and the agent, at machine speed, with nobody in the middle.
A six-table migration of public financial reference data to Databricks. The agent spent 1 h 44 m building and 7 h 18 m fixing what Prover found, 9 h 2 m in all. Hours are the agent's working time; Prover's checks are the fast part of each round.
30
issues found and fixed in the loop
Twenty-five against the current system, five against the new schema. None needed a person to move it along.
1,137
checks, every table read in full
No sampling on either side. Every check leaves by a labelled exit: exact match, platform difference, stated assumption, or a real defect in the build.
0 hand-written transforms
nobody wrote or debugged one
A person was needed only where the customer's own material ran out and a judgement had to be made.
A person is needed only where judgement is genuinely required. Nothing is set aside that a person did not sign for.
Rule
Where your material is ambiguous
The build took a position. You confirm it or overturn it. Each ruling is recorded.
Approve
What the checking proposes to set aside
Platform differences and stated assumptions are put up for signature in batches. You can refuse one.
Decide
Whether a run stands
Approved clean, approved with named exceptions, or rejected. The exceptions are on the record, not buried.
Why a loop, and not a review
Nobody reads the agent's output. That is not going to change.
An agent that migrated four hundred objects produced four hundred notebooks, a few thousand lines of reasoning, and a summary that says it went well. The review agent you pointed at it produced another few thousand lines agreeing. The defects are in there somewhere.
People do not read that, and should not have to. The only way to find what is wrong with agent-built data work is to measure the result against the thing it replaced, automatically, every time it changes.
✗Reading the agent's transcript to find where it went wrong
✗Reading a review agent's opinion of the first agent's work
✗Reading four hundred generated notebooks before cutover
✗Trusting "all tests pass" and matching row counts
✓Measuring every value of the result against what you run today, and sending the differences back to the agent
Anything you are building with AI and data right now may already carry defects like these.
They do not announce themselves. They surface at cutover, in a quarter close, in a regulator's question, or never. The cost of finding one is smallest the day it is made and largest the day someone else finds it. Prover finds them the day they are made.
What an audit finds
The row counts matched. The numbers were still wrong.
Every one of these passed the test suite that came with the migration. Each was found by measuring the result against the system it replaced.
SQL Server → Databricks · WideWorldImporters (public Microsoft sample)
The vendor's own reference warehouse was 114 rows stale.
An agent rebuilt the warehouse ETL as PySpark. Prover compared 1,376 elements against the reference Microsoft ships with the sample. 477 findings on the first pass collapsed to 243 after a single fix: Spark writers default every column to nullable, which is a real defect, not a platform difference. Then it found the reference itself had drifted.
Screenshot: the finding card for the 114-row drift, from the Prover review surface. (Pending.)
Public dataset. Full ledger available on request.
Oracle + Teradata → Databricks · demo estate
"Total failures: 0." Fourteen of fourteen row counts matched. Two routines were wrong.
A tier threshold and a status filter had each been translated slightly differently. No row count can see this. Only checking the behaviour of the routine against the original, on the same input, does. The same class turned up as customers sitting a few cents from a threshold, and as decimals silently truncated from eight places to six inside perfectly matching counts.
Screenshot: the run summary reading "Total Failures: 0" beside the two findings. (Pending.)
Thousands of differences. A handful of rules. Four left for a human.
When the brief is "change nothing," almost every difference is just how the new platform writes the same value. Prover's platform rules license those in bulk, with each rule signed for once, and leave a residual short enough to read before lunch. On a second estate one ratified type-spelling rule accounted for 278 of 308 differences.
Synthetic rehearsal estates.
Across engagements
The verifier is wrong about as often as the builder.
Roughly half the rounds on real engagements turned out to be defects in the checking, not the build. That is why Prover runs positive controls, states its denominators, and freezes the subject before grading. No green is a check that could not have failed.
Lessons register, 20 migrations.
Verify one object, free
You have an agent. Let it do the packaging.
Pick one thing the agent migrated that has a business number in it. Give your agent the prompt below. It assembles that one object's before and after into a zip and hands it back to you. You send the zip; we send back the ledger within 48 hours. Or skip all that and talk to a person.
1
Give this to your agent
Paste it into Claude Code, Cursor, Cortex Code, or whatever built the migration. It tells the agent what Prover is, what to collect, what to leave out, and what comes back.
prompt for your agent
I want one migrated data object independently verified by Prover (prover.genesiscomputing.io), a tool from Genesis Computing. Prover compares what a migration produced against what the legacy system produces, checks every value, and returns a ledger where every difference is attributed to a cause: the platform, a stated assumption, or a defect in the build, with evidence.
Your job: assemble a verification package for ONE object and hand it back to me. Do not send anything anywhere yourself.
1. Pick one object from the migration you built or are working on: a view, stored procedure, report query, dbt model, or metric with a business number in it. Prefer one with real logic (filters, thresholds, joins, aggregations) over a plain table copy.
2. Collect into a folder named prover-package/:
legacy/ the original definition from the source platform (DDL, SQL, procedure body, or report query)
migrated/ the definition produced on the target platform (SQL, notebook, dbt model)
sample/legacy.csv and sample/migrated.csv
the output of each definition on the SAME input window, up to 500 rows, same column order where possible
manifest.json { "object_name", "description" (what it is supposed to produce, in one paragraph),
"source_platform", "target_platform", "built_by" (agent / tool / team, and which),
"input_window", "masked_columns": [], "known_differences": [] (anything you already believe differs, and why),
"how_to_run_each_side" (the exact command or query used to produce each sample) }
3. Mask or drop any column holding personal or confidential data, and list it under masked_columns. Include NO credentials, connection strings, or full tables.
4. Zip the folder as prover-<object_name>.zip. Tell me the path, and give me a five-line summary of what is inside and anything you were unsure about.
What comes back: a ledger for this object. Every check leaves by a labelled exit (exact match, platform difference, stated assumption, or a real defect in the build), each with evidence. I should expect it within 48 hours of the zip landing at prover@genesiscomputing.ai.
When the agent hands you the zip, email it to prover@genesiscomputing.ai. A person confirms receipt within one business day. Nothing your agent packages leaves your machine until you send it.
2
Talk to a person
If you would rather describe the migration first, or want to run Prover yourself inside your own environment, say so here and a person replies within one business day.
What we do not do
We do not need access to your systems. A zip is enough.
We do not keep your files after the ledger is delivered.
We do not require a call to hand over the result.
Questions
What people ask before they send an object
What does "independent" mean here?
Prover did not build the migration and has no stake in it passing. It compares the result against the system it replaced and against the specification you asked for, and it reports every difference by cause. A verdict that a check could not have failed is reported as exactly that, not as green.
Does it matter which agent or tool did the migration?
No. Prover verifies results, not builders. It has graded migrations built by coding agents, by migration tools, and by people. The loop works the same way: each finding is sent to the agent, fixed, and re-measured.
What exactly do we send?
Whatever the prompt tells your agent to package. For one object: the legacy definition (a view, a stored procedure, a report query), the migrated definition the agent produced, and a sample of the output from each side, a few hundred rows in CSV, masked however you need. With definitions alone we can tell you where the logic diverges. With sample rows we can show you which values it changes.
We can't share anything from the legacy system.
Send the migrated definition and a description of what it is supposed to do. We will tell you what we would check and what usually goes wrong for that shape of object. Where a legacy reference truly cannot be shared, Prover can grade against a faithful reconstruction, and it grades the reconstruction too, since a reference accrues defects at the same rate as a build.
What platforms?
Targets: Snowflake and Databricks first. Sources graded so far include SQL Server, Oracle, Teradata, Postgres, BigQuery, and file-based feeds. If yours is not listed, ask; the comparison is platform-agnostic, the connectors are the only variable.
What happens to our files?
They live in an isolated sandbox for the duration of the audit and are deleted when the ledger is delivered. Ledgers name objects, rules, and evidence; they do not carry your data values unless you ask for them to.
Who is behind Prover?
Prover AI is built by Genesis Computing, the team behind the Genesis agent platform. Prover is available on its own; you do not need anything else from us to use it.