The cost of a Teradata migration is driven far more by business logic, data pipelines, validation and parallel running than by the number of terabytes. A defensible estimate therefore comes from analysing the workload and measuring a representative pilot, not from a price per terabyte. Budgets based on data volume or object counts look precise and are usually the ones that are exceeded.
We at DWHPro estimate migrations from the Teradata side, where most of the cost hides. This article explains what drives the cost, how to get to a number you can defend in front of a steering committee, and which costs are most often forgotten.
Why data volume is the wrong yardstick
Copying data is the most automated and predictable part of a migration. Two warehouses of the same size can need very different effort: one holds mostly history that is loaded once, the other runs hundreds of interdependent jobs with business rules accumulated over fifteen years. The second costs many times more to migrate, and its size says nothing about that.
What actually drives the cost
| Cost driver | Why it matters |
|---|---|
| Business logic in the database | Stored procedures, macros and complex SQL have to be converted and proven to give the same results |
| Load and batch processes | Teradata-specific load jobs, scripts, schedules, dependencies and restart logic need rebuilding |
| Validation | Reconciling data and business results, including the time of the business experts who sign off |
| Performance redesign | Large tables and critical batch chains designed for Teradata need redesign on the target |
| Downstream consumers | Reports, applications and interfaces that read from the warehouse must be switched and tested |
| Parallel running | Both platforms run and are paid for until the new one is accepted |
| Knowledge and documentation | Undocumented logic and scarce subject-matter experts slow every phase |
A quick way to see the scale: ask how many people today understand why the critical nightly batch is built the way it is. If the answer is “one or two”, discovery and validation will take longer than any tool vendor’s estimate assumes.
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 bookThree steps to a defensible estimate
- Workload assessment. Analyse what really runs on Teradata: query logs, the code in the database, the load processes and their dependencies, and the reports that depend on them. Unused objects and redundant data are identified and left behind, which often reduces the scope noticeably. Result: a complexity picture and a first, assumption-based budget.
- Pilot on a representative workload. Migrate a demanding slice of the warehouse, including difficult logic and a real batch chain, and validate it end to end. Result: measured effort for conversion and validation, real runtimes and real consumption on the target.
- Extrapolation. Scale the measured effort to the full scope, plan migration waves and parallel running, and add contingency for what the pilot could not show. Result: a schedule, a resource plan and a budget based on measurement rather than assumption.
The pilot is the step most often skipped to save time, and the one that saves the most. It replaces productivity assumptions with numbers from your own system.
Running costs are a separate calculation
Do not mix the cost of the migration with the cost of running the new platform. Cloud platforms charge for consumption, so the running cost depends on how the workload is designed and governed after the move. Model it with scenarios based on your actual Teradata workload: an optimistic case with well-tuned workloads, an expected case and a conservative case with higher concurrency and larger compute. We explain why similar systems end up with very different bills in why two identical Teradata migrations produce different Snowflake costs.
For the business case, compare complete costs over three to five years: migration, parallel running, platform consumption for production and non-production, training and the operating model afterwards.
The costs that are most often forgotten
- Parallel running of both platforms until acceptance.
- Development and test environments on the new platform, which consume from day one.
- The time of business experts for validation and sign-off.
- Changes to reports, applications and interfaces outside the warehouse.
- Training and new operating routines for monitoring and cost control.
- Teradata contract terms that run on after the planned switch-off date.
How long does it take?
The honest answer before an assessment is “it depends”, and any precise figure given without looking at your workload should be treated with caution. What can be said: the assessment itself takes weeks, not months; the pilot shows the real pace of conversion and validation; and the overall schedule follows from the number of migration waves and the length of parallel running. We establish that plan before committing to delivery dates.
What DWHPro offers
We publish our entry prices. A 4-day platform diagnostic costs €4,800 and is credited in full against the assessment if it is commissioned within 90 days. A migration assessment costs €19,500 and typically takes two to three weeks with one or two senior engineers. It delivers an architecture review, a map of your data landscape, a risk register and a costed roadmap with documented assumptions. Implementation is scoped separately once the assessment and pilot have established the facts. Prices exclude VAT; see our Teradata-to-Snowflake migration services for details.
An assessment can also conclude that optimising your Teradata system, or moving it to Teradata Cloud with its always-on and elastic compute, is the better investment. We discuss when in optimise or migrate your data platform.
Common questions
Can you give a price per terabyte?
No, because volume is a weak predictor of effort. Business logic, pipelines and validation decide the cost, and they differ widely between warehouses of the same size.
Does an automated conversion tool make the migration cheap?
Conversion tools reduce the cost of translating code. They do not remove the cost of redesigning performance-critical parts, rebuilding pipelines, validating results and running both platforms in parallel. Snowflake also offers to run existing Teradata workloads without rewriting them (Teradata virtualization in Snowflake AIM). That can lower the initial cost of the move, but the legacy logic comes along, and modernising it later is a cost to plan for.
Will the cloud platform cost less than Teradata?
Not necessarily. It depends on your workload, the commercial terms and how consumption is governed after the move. A credible business case shows the assumptions behind the comparison instead of promising a percentage saving.
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