Prove your data migration matched before cutover.

Before you switch off the old system, check:

  • Row counts and totals, old against new
  • Records, matched on their key
  • Renamed, dropped and changed columns
Book a demo

Used by data teams at

CarTrawlerAppfire

The row counts match. The values might not.

  1. Cutover sign-off rests on row counts in a spreadsheet.

  2. Finance spots the gap between the old report and the new one first.

  3. Every validation query is rewritten for the new system, days before cutover.

Test the legacy and new system side by side, before cutover.

Trust the new system the way these teams trust their data.

“We went from detection to prevention. Most data quality tooling will tell you something broke after it broke. Our goal is to catch it before that reaches the dashboards and datasets in the first place.”
Sid SrivastavaDirector of Data Governance, Quality, and MLOps at 2K
Sid Srivastava
  • Investing in data quality is key for cross-functional teams to make accurate, complete decisions with fewer risks and greater returns, using initiatives such as product thinking, data governance, and self-service platforms.
    Mario KonschakeDirector of Product-Data Platform
    Mario Konschake
  • We’re catching issues we never would’ve noticed before because the tool looks across so much more data than we could check manually.
    AppfireZach PhillipsSenior Product Analyst
    Zach Phillips
  • We can guarantee the quality; that it has been checked, that it is compliant, that it passes all of the quality rules.
    CarTrawlerPatrick CallinanDirector of Insights and Data Science
    Patrick Callinan

Questions to settle before cutover.

What the checks compare, where they run and when to run them.

How do you test a data migration?

Compare the old system and the new one table by table. Start with counts and totals, because they are fast and show which tables need a closer look. Then compare the records on a unique key for the tables that matter most, and compare the two schemas. Run the comparison after every load until cutover.

Read about data reconciliation
Are matching row counts enough?

No. Two tables can hold the same number of rows and still differ: a changed amount, a record missing on one side and an extra one on the other cancel out in the count. A comparison on a key shows each record that changed, went missing or appeared.

Can Soda compare two different databases?

Yes. The source and the target can sit in different data sources, for example SQL Server and Snowflake. Soda reads both sides and runs the comparison itself, page by page, so memory use stays stable. Comparing every record is not supported when one side is Synapse; counts, totals and schema comparisons are.

See the reconciliation checks reference
What if the new tables use different column names or formats?

Renamed columns can be mapped in the schema comparison. For values stored in different shapes, such as padded text or amounts in cents, a comparison on records can apply an expression to each side first, like TRIM(name) or amount / 100. Each side can also take its own filter.

Does the data leave our network?

It does not have to. With a self-hosted Soda Runner on the Enterprise plan, the checks run in your own Kubernetes cluster and the data stays within your network. With the Diagnostics Warehouse on, the records that differ are written to tables in your own warehouse. Sending samples of failed records to Soda Cloud is optional.

See the deployment options
When should the comparison run?

When neither side is being written to, or on a closed partition whose rows no longer change. Run it after each load until cutover, then keep the checks running on the new tables, on a schedule or from your deploy pipeline.

The counts match. Now check the records.

Thirty minutes with the Soda team on how you test the migration today, and how Soda would compare your two systems.

  • With a self-hosted Soda Runner (Enterprise plan), the checks run inside your own network
  1. 1You
  2. 2Your company
  3. 3Your time