Dataverra

For teams that deliver data conversions

Investigate. Map. Verify.

Dataverra is the working system for complex ETL data conversions — it holds the source schemas, the data map, and the QA evidence, and generates every line of SQL your team runs. From first look at a legacy system to a verified, reconciled target.

Request access Sign in

Dataverra never connects to your client's databases. Ever. It generates dialect-exact SQL; your team runs it, and only metadata comes back.

SQL out. Metadata in. Nothing else.

Every interaction with a real database follows one auditable loop — no client credentials, no network paths, no row-level client data inside Dataverra.

Dataverra schemas · data maps · QA rules run ledger · generated SQL Your database, your hands Oracle · SQL Server · PostgreSQL run by your database developer generates dialect-exact SQL metadata & aggregates only

Investigate

Declare the source systems and Dataverra generates the introspection and profiling SQL — duplicates, orphaned keys, null rates, gaps and overlaps in time periods. Results come back as a data-quality report your BA can put in front of the client before mapping begins.

Map

The vendor's target tables — exact types and sizes — become the start of a living data map. Your BA records source expressions, joins, lookups, and open questions in a spreadsheet-style editor; Dataverra generates the ETL SQL for the working environment, in dependency order, every version kept.

Verify

Structural checks against the vendor definition, duplicate and referential integrity checks, vendor-supplied QA rules, and both-halves reconciliation — row counts and checksums from source and target, diffed by Dataverra against thresholds set in the map. Every verdict traces to the exact SQL that produced it.

How a conversion runs in Dataverra

  1. Define the environments. Every project starts by declaring its sources (Oracle, SQL Server, PostgreSQL, Excel, CSV), the working database, and the final target — because every generated statement must be dialect-exact.
  2. Capture the source schema. Run the generated introspection SQL; upload the results. Dataverra now knows every table, column, type, and key — versioned, so later changes are visible.
  3. Report data quality. Generated profiling SQL surfaces the problems early; findings become the client-facing report.
  4. Map with the experts. In mapping sessions with the client's SMEs and IT, the BA records where each target column comes from and how it transforms.
  5. Run the generated ETL. The database developer executes the generated, validated SQL against the working environment — and reports outcomes back.
  6. Prove it. QA and reconciliation SQL verify the map was followed and the data holds up, with an immutable ledger from generated statement to verdict.

Built for the data you can't touch

No connections, by design

There is no database driver in Dataverra, no connection-test button, no stored DSN. The tool cannot reach a client system — a guarantee you can put in a security review, not a setting.

Metadata and aggregates only

Result intake accepts schema metadata, counts, checksums, and profiling statistics — and mechanically rejects anything shaped like row data. Client PII/PHI never enters the system, which keeps Dataverra out of scope for the data itself.

Isolation enforced by the database

Every customer's workspace is isolated by row-level security inside Dataverra's own database — not by application code. One client can never see another's work, or even that it exists. Project-level access works the same way.

One workspace for the whole conversion team

Project manager

Progress by subject group and table, QA pass-rates, open questions — the roll-up view.

Business analyst

Source investigation, the client data-quality report, and the data map itself.

Database developer

Generated introspection, ETL, and QA SQL to run — results uploaded back with one action.

See it on your next conversion

Dataverra is in early access with consulting teams doing real conversions.

Request access