Prove Your Data Migration Produces the Same Business Numbers
Veritrace replays your legacy and migrated pipelines on the same inputs, traces each critical number from source to report, and gives your data owners and auditors signed evidence that the migrated numbers match the legacy system before cutover.
- Runs in your cloud or a dedicated environment
- No access to production systems
- Works with any data migration tool
Why Data Migrations Slow Down at Sign-Off
Teams validating a migrated data platform rely on row-count and checksum comparisons, hand-written test SQL and long parallel runs, and often reach cutover without evidence that the business numbers match.
Table Reconciliation Passes While Reports Drift
Row counts and checksums confirm the data landed. They miss logic changes such as empty-string handling, dates that carry time, NULL ordering and rounding.
Parallel Runs of Old and New Platforms Last Months
Teams run both platforms side by side and compare outputs by hand until someone is confident enough to sign.
Auditors Need Evidence That the Numbers Match
Regulated teams need a record of what was tested, what differed and who accepted each difference before the legacy system is switched off.
Six Levels Veritrace Checks Between Your Legacy and Migrated Platforms
Standard migration validation compares schemas, row counts and checksums. Veritrace also compares critical business numbers, pipeline behavior, report figures and operations, and gives each level a pass, warning or fail.
| Level | What it checks | Standard validation | Veritrace | |
|---|---|---|---|---|
| 1 | Schema and Types | Column types and precision, such as a NUMBER(18,2) column that became DOUBLE | Checked | Checked |
| 2 | Table Data | Row counts, checksums and column profiles on both platforms | Checked | Checked |
| 3 | Critical Data Elements | The business numbers your teams report on, compared at each hop from source to report | Not checked | Checked |
| 4 | Pipeline Behavior | How jobs handle rejected rows, incremental loads, history tables, backfills and late-arriving records | Not checked | Checked |
| 5 | Report Figures | The figures on regulatory returns and reports, line by line | Not checked | Checked |
| 6 | Operations | Run times against your SLAs and how retry policies behave | Not checked | Checked |
How Veritrace Validates a Data Migration
Veritrace works in six steps, from setting up sandboxes for your legacy and migrated platforms to tracking both through the parallel run before cutover.
Set Up Legacy and Migrated Sandboxes
Veritrace sets up production-like sandboxes for your legacy and migrated platforms and reads the converted code from your repository, with no access to production systems.
Confirm the Source-to-Target Mapping
Veritrace maps source objects to target objects, including renamed, split and merged tables, and your team confirms the mapping before the run.
Generate Test Inputs
Veritrace builds test rows that reach each branch of your logic and adds known dialect traps such as empty strings, dates that carry time, NULL ordering, rounding and time zones.
Replay Legacy and Migrated Jobs
The legacy job and the migrated job run on the same inputs in a sandbox, with the clock frozen, writes redirected and external calls stubbed.
Trace Each Difference to Its Code
For each difference, Veritrace finds the first step where the two platforms diverge and shows the code on both sides, the triggering input and a suggested fix.
Track Both Platforms Through the Parallel Run
During coexistence, Veritrace compares your critical numbers daily and alerts the data owner when drift crosses your materiality threshold.
Veritrace runs your existing data quality rules, such as Great Expectations suites, dbt tests or Soda checks, on both platforms, alongside rules it generates from your source data.
What Veritrace’s Signed Evidence Pack Contains
Veritrace produces one signed, deterministic and replayable record for each validation run, ready for cutover sign-off.
- 1
Scope and Method
Critical data elements, pipelines replayed, load patterns, inputs, sandbox rules and tolerances.
- 2
Results for Each Level
A pass, warning or fail for schema, table data, critical numbers, pipelines, reports and operations.
- 3
Critical Number Trace
The value of each critical number at each hop from raw data to report, and where each difference entered.
- 4
Root Causes
The impact, legacy and migrated code lines, confidence and status of each difference.
- 5
Quality Rules
Data quality rules run on both platforms, with any that fail only on the migrated platform.
- 6
Accepted Risks
Who accepted each difference below materiality, the reason and when the acceptance expires.
- 7
Sign-Off
Approval status from the data owner, migration lead and internal audit.
- 8
Integrity
Your signing key, a trusted timestamp, the retention location and a command to verify the record.
| 1 Schema and types | Warning | NUMBER(18,2) became DOUBLE |
| 2 Table data | Pass | 1,206 of 1,206 tables match |
| 3 Critical data element | Fail | CAD −5.44M at the report |
| 4 Pipeline behavior | Fail | 3 of 4 replayed pipelines differ |
| 5 Report figures | Fail | Return line 1.1 differs |
| 6 Operational | Warning | 38 min against a 60 min SLA |
| Signed with | Your key vault signing key | |
| Timestamp | RFC 3161, 2026-11-04 10:42 IST | |
| Stored | Object-locked bucket in your account, 7-year retention | |
| Personal data | None. Rows and identifiers excluded, trigger values masked | |
Readable by People and Machines
Your data owners and auditors read the PDF report, and your systems store the signed JSON file, which is the authoritative copy and can be verified without Veritrace.
Sign-Off With Separation of Duties
Three different people approve the migration before cutover, so no one signs off on their own work.
- Data ownerApproves any small differences left unfixed
- Migration leadFixes differences and reruns the validation
- Internal auditSigns the cutover against the record
A Record of What Was Tested
The evidence pack states how much of your pipeline logic each run tested, so auditors can see exactly what a sign-off covers.
See Veritrace Validate a Credit-Risk Migration Demo
A bank moves its credit-risk mart from Oracle to Databricks. All 1,206 tables reconcile, while Total Credit Exposure on the regulatory return comes out CAD 5.44M lower.
Standard validation
PassTables match on row counts and checksums
Veritrace
Not equivalentLower Total Credit Exposure on the regulatory return, from 5 root causes
Five Root Causes Behind the CAD 5.44M Difference
- F1−CAD 2.10M
Empty Text Treated Differently
Oracle stores an empty string as NULL and Databricks keeps it as text, so 1,318 uncollateralized loans drop out of the filter.
- F2−CAD 1.12M
Same-Day Drawdowns Excluded
The converter removed a date truncation, so loans drawn later on the snapshot day fall outside the reporting window.
- F3−CAD 2.22M
Deduplication Keeps the Wrong Record
Oracle sorts NULLs first in a descending sort and Databricks sorts them last, so an older, smaller balance wins.
- F4+CAD 0.03
Rounding Drift
A fixed-precision money column became floating point, adding 3 cents and failing a zero-tolerance reconciliation.
- F5Timing shift
Load Window Shifted
The legacy host ran on Toronto time and Databricks runs on UTC, so daily loads pick up rows a day late.
Security and Data Handling
Veritrace runs in your cloud or in an isolated environment we host for you, and your security team reviews its access before the first run.
Isolated for Each Customer
Your Veritrace environment is dedicated to your company, whether it runs in your cloud or ours.
No Access to Production
Veritrace runs your legacy and migrated pipelines in production-like sandboxes, which are deleted after each run.
Short-Lived Credentials
Veritrace receives new credentials for each validation run, and they expire 60 minutes after it ends.
Hashed and Masked Data
Comparisons use keyed hashes and group totals. Triggering inputs are masked, and only the data owner can reveal them.
Full Audit Log
Each query by the runner and each action by a person streams to your SIEM.
Your Signing Key
Evidence is signed through your own key vault and kept in locked, tamper-proof storage.
Two Ways to Deploy Veritrace
Your team runs Veritrace in both options and chooses where it is hosted.
In Your Cloud
Install Veritrace in your own cloud infrastructure, where results, evidence and logs stay in your account.
Hosted by Veritrace
Use Veritrace in an isolated environment that we host and dedicate to your company.
Supported Migration Paths
Veritrace works with any data migration tool or in-house team.
Oracle packages and SQL converted to Databricks SQL and Spark.
PowerCenter mappings and workflows moved to Databricks pipelines.
SSIS packages and T-SQL moved to Fabric pipelines and notebooks.
Stored procedures moved to PostgreSQL, with business logic rewritten as Java services.
Book a Veritrace Demo
See a complete validation run, from setting up the legacy and migrated sandboxes to the signed evidence pack.
- How Veritrace sets up sandboxes for your legacy and migrated platforms
- How each difference is traced to the code that caused it
- What the evidence pack contains and who signs it off
Demo Requested
Thanks for your interest. We’ll be in touch to schedule a time.
Frequently Asked Questions
What does Veritrace do?
Veritrace proves that a migrated data platform produces the same business results as the legacy system. It replays both platforms on the same inputs, traces each difference to the code behind it and produces signed evidence for cutover sign-off.
How is Veritrace different from standard migration validation?
Standard migration validation compares schemas, row counts and checksums. Veritrace also checks critical data elements, pipeline behavior, report figures and operations, which is where conversion errors tend to surface.
Does our data leave our environment?
With the in-your-cloud option, no. Veritrace runs inside your cloud infrastructure, and results, evidence and logs stay in your account. With the hosted option, it runs in an isolated environment dedicated to your company. Neither option accesses your production systems.
Do we need to change our code conversion tool?
No. Veritrace reads the converted code from your Git repository, whichever tool, accelerator or team produced it.
Is production data required to validate a migration?
No. Veritrace generates test inputs that reach each branch of your pipeline logic and replays the same inputs on your legacy and migrated platforms in secure, production-like sandboxes.
Can Veritrace use our existing data quality rules?
Yes. Veritrace imports your existing rules, such as Great Expectations suites, dbt tests or Soda checks, generates further rules from your source data and runs both sets on each platform.
How is Veritrace delivered?
Veritrace is self-service software. Install it in your own cloud infrastructure or use it in an isolated environment hosted by Veritrace.
What does the demo cover?
The demo walks through a complete validation run, from sandbox setup and mapping to root causes and the signed evidence pack.