A Teradata migration has worked when the business has signed off on evidence that the new platform produces the same results, within the same processing windows and at the agreed cost. Loaded tables and converted SQL that runs are only the starting point. The evidence comes from three levels of validation, a period of parallel running and acceptance criteria agreed before anyone switches users over.
We at DWHPro treat validation as a workstream that starts with the first migrated table, not as a test phase at the end. This article explains how we approach it and what decision makers should insist on before Teradata is switched off.
Why “everything has been migrated” proves very little
Status reports in migration programmes tend to measure activity: tables moved, scripts converted, jobs rebuilt. None of these numbers says whether the finance report shows the same revenue as last month. Teradata and the cloud platforms differ in many small ways, such as how they compare text, round decimals or treat duplicate rows. Each difference can change a result without producing a single error message.
That is why matching row counts are not proof. Two tables can contain the same number of rows and still produce different totals. In the Swiss retail migration described in our published case study, source-to-target comparisons therefore covered row counts, aggregates and business-logic checks, and every discrepancy was investigated before cutover.
Three levels of validation
| Level | Question it answers | Typical evidence |
|---|---|---|
| Structure | Is everything there, in the agreed form? | Tables, columns, data types and volumes match the target design |
| Data | Does the content match Teradata? | Counts, totals, checksums and key-level comparisons per table |
| Business results | Do the numbers the business relies on match? | Reports, KPIs and regulatory outputs reconciled and signed off by their owners |
The first two levels can be largely automated and repeated for every migration wave. The third needs the people who own the numbers: finance, controlling, risk or operations. Plan their time from the start; a sign-off that waits for an available business expert delays the cutover more than any technical issue.
Get the complete Teradata tuning book, free
Teradata Query Performance Tuning: The DWHPro Guide
By Roland Wenzlofsky & Artemios Vogiatzis
206 pages on statistics and demographics, access paths and indexes, query execution plans, and joins. Get the full PDF and practical Teradata updates from DWHPro.
Confirm your email to receive your download link. Privacy policy. Unsubscribe in any newsletter.
About the free bookWhen the numbers do not match
Differences will appear. What matters is how fast they are explained. When a report shows a different total on the new platform, there are three possible causes:
- The logic was converted incorrectly: a filter, join or calculation behaves differently.
- The data was migrated incorrectly: rows are missing, duplicated or changed in transit.
- The data was already inconsistent in Teradata, and the new platform exposes it.
Knowing which platform behaviours typically cause which symptoms shortens this investigation from weeks to days. It is also where deep knowledge of the source system matters most: you can only explain a difference if you understand what the original system did.
Performance and cost are part of the proof
A migration that produces correct numbers but misses the overnight batch window has not worked. Validation therefore also covers:
- runtimes of the critical batch chains and reports, compared with a baseline taken from Teradata’s query logs;
- behaviour under realistic concurrency, for example the morning peak when loads and reports overlap;
- data freshness for the consumers who depend on it;
- consumption on the new platform, compared with the budget in the business case.
Cost is the easiest of these to overlook, because the first bills arrive after go-live. Measuring it during parallel running turns a surprise into a known figure.
Parallel running
The most reliable evidence comes from running Teradata and the new platform side by side on production data for an agreed period. Both receive the same loads, both produce the same reports, and the results are compared automatically every day. Parallel running costs money, because two platforms run at once, so its length should be agreed in advance and tied to clear exit criteria rather than left open.
Acceptance criteria to agree before cutover
We recommend agreeing the following with business and IT owners before migration work starts, so that the go-live decision is a check against criteria rather than a negotiation:
- All critical tables reconciled, with every difference explained.
- All critical reports and KPIs approved by their business owners.
- Critical batch chains completing within their windows, including restart after a failure.
- Query response times within agreed limits under realistic load.
- Data freshness meeting the agreed latency.
- Consumption within the approved budget.
- Access rights reviewed for the new platform, not copied blindly.
- A rehearsed rollback with agreed triggers, and Teradata kept available until the rollback window has passed.
Tools help, evidence decides
Vendor migration suites such as Snowflake AIM include data validation, data quality tools such as dbt tests, Great Expectations or Soda automate rule checks, and Google’s open-source Data Validation Tool compares Teradata with BigQuery, Snowflake and other platforms. They make validation faster and repeatable. They do not decide which differences are acceptable; that remains a business decision based on the evidence they produce.
How DWHPro approaches validation
We build the reconciliation framework early, run it for every migration wave and report differences with their root cause, so that progress is measured in validated results rather than migrated objects. Our Teradata-to-Snowflake migration services include reconciliation evidence, performance acceptance results and a cutover and rollback runbook as deliverables. If you are earlier in the decision, start with an independent platform assessment.
Common questions
How long should Teradata and the new platform run in parallel?
Long enough to cover the business cycles that matter, such as a month-end close, and to meet the agreed exit criteria. The duration should be fixed in the plan, because parallel running means paying for two platforms.
Is row-level comparison of every table necessary?
Not always. Totals and checksums are sufficient for most tables; row-level comparison is worth its cost for critical tables and wherever totals show a difference.
Who should sign off the migration?
The owners of the business results, not only the project team. IT confirms that the platform runs; the business confirms that the numbers are right.
Planning a Teradata-to-Snowflake migration?
Review the assessment, conversion, reconciliation and cutover work needed for a controlled transition.
Get the complete Teradata tuning book, free
Teradata Query Performance Tuning: The DWHPro Guide
By Roland Wenzlofsky & Artemios Vogiatzis
206 pages on statistics and demographics, access paths and indexes, query execution plans, and joins. Get the full PDF and practical Teradata updates from DWHPro.
Confirm your email to receive your download link. Privacy policy. Unsubscribe in any newsletter.
About the free book