When replacing legacy ETL tools during a cloud migration, each family of pipelines has three options: keep the existing tool and point it at the new platform, re-platform it onto the vendor’s cloud edition, or replace it with cloud-native transformation and ingestion services. The right choice depends on where the business logic lives, how many pipelines there are, licence timing and team skills. Most programmes end up with a deliberate mix, decided per pipeline family rather than once for the whole estate.
We at DWHPro have spent more than twenty years inside Teradata systems and now lead migrations from Teradata to cloud platforms. In our Swiss retail migration from Teradata to Snowflake, rebuilding the critical ETL pipelines with Python, ELT and dbt was a central part of the work, as our case studies describe.
Why ETL is often the harder half of the migration
Moving tables is well understood. Moving the logic that fills them is not. In a mature Teradata estate that logic is spread across ETL tool mappings, BTEQ scripts, TPT and other load utilities, stored procedures, scheduler definitions and shell scripts that glue them together. Some of it relies on Teradata-specific behaviour that has no exact equivalent on the target. Bulk loading alone needs its own redesign, which we cover in migrating bulk loads from Teradata to Snowflake.
The ETL decision also affects running cost. Logic that runs on an ETL server today may run as warehouse compute tomorrow, and it then appears on a consumption bill.
The three options
| Option | What it means | Fits when | Watch out for |
|---|---|---|---|
| Keep | The existing tool stays and connects to the new platform | The tool is strategic, recently licensed and the team knows it well | Data still flows through the tool’s servers; little gain from the new platform’s own engine |
| Re-platform | Move to the same vendor’s cloud edition, reusing existing designs | Large investment in mappings that work, and a vendor modernisation path exists | Inefficient designs move along unchanged; a new licence model to evaluate |
| Replace | Rebuild with cloud-native ingestion and transformation, often SQL-based ELT | Logic is mostly SQL, the old tool is near end of licence, or you want one engineering model | The largest rebuild effort; needs strong testing and new skills |
What the market offers today
Product names and status change quickly in this space. As of late 2026, these are the main options we evaluate with clients:
- Informatica: a PowerCenter-to-cloud modernisation programme moves PowerCenter workloads to its Intelligent Data Management Cloud (IDMC), reusing existing assets.
- Snowflake: dbt Projects on Snowflake runs dbt transformations inside Snowflake with managed runtimes. Snowflake Openflow is an integration service that connects a wide range of sources and destinations. SnowConvert AI converts Teradata code, including BTEQ, MultiLoad and TPump scripts, and converts SSIS packages (generally available) and Informatica PowerCenter exports (in preview) into dbt projects. Snowflake AIM for Virtualization of Teradata, available to select customers, translates Teradata SQL in real time so existing applications can run against Snowflake during a transition.
- Databricks: Lakeflow covers ingestion (Lakeflow Connect), declarative batch and streaming pipelines (Lakeflow pipelines), visual data preparation (Lakeflow Designer) and orchestration (Lakeflow Jobs).
- Google Cloud: Dataform manages SQL transformation workflows in BigQuery; Dataflow is a managed service for batch and stream processing.
- Independent tools: dbt, managed ingestion services such as Fivetran, and ELT platforms such as Matillion work across several target platforms.
For DataStage, Ab Initio and other tools, ask the vendor in writing what cloud deployment options and processing inside the target warehouse your licence includes, and on which timeline.
How to decide
We assess every pipeline family against the same questions:
- Where does the logic live? Mostly SQL is cheap to move to ELT. Logic buried in graphical transformations is expensive to rebuild.
- How many pipelines, and how alike are they? Hundreds of similar loads justify a pattern or a conversion tool. A handful of complex ones justify careful rebuilding.
- When does the licence end? A renewal date in the middle of the programme is a hard constraint.
- Who will run it? A tool the operations team cannot support is a risk, however modern.
- How does it affect running cost? Inefficient row-by-row designs become visible cost on a consumption platform.
What goes wrong
- Converted code is treated as finished. Automated conversion speeds up the work, but the output needs review, testing and often redesign. Snowflake’s own documentation states that converted output carries flagged issues to resolve.
- The scheduler is forgotten. Dependencies, restart logic and calendars live in the scheduler, not in the ETL code.
- Error handling and audit are lost. Rejected-record handling, load statistics and alerts are often built into the old framework and must be rebuilt explicitly.
- Two changes at once without proof. Changing platform and tool together is legitimate, but only with automated reconciliation of the outputs. We describe our approach in how to prove a Teradata migration before cutover.
- Skills are an afterthought. A team that ran a graphical tool for fifteen years needs training and time to own a code-based ELT stack.
What to insist on
- A complete pipeline inventory with complexity rating, owner and target option for each family.
- A pilot that converts or rebuilds representative pipelines and measures effort, quality and running cost.
- Automated reconciliation of row counts, aggregates and business rules before each cutover.
- A plan to switch off old tools and licences, with dates.
- Training for the internal team, so that it can run and change the new pipelines without outside help.
How DWHPro helps
We assess your ETL estate, recommend keep, re-platform or replace per pipeline family, and lead the rebuild and reconciliation. See our Teradata to Snowflake migration service, or our guide to choosing a migration partner.
Common questions
Should we convert our ETL automatically?
Automated conversion is worth using for large volumes of similar code. Plan for review and testing of everything it produces, and redesign where the converted result is inefficient on the target platform.
Can we keep Informatica after moving to the cloud?
Yes. Keeping it or moving to Informatica’s cloud platform is a valid choice when the investment in existing mappings is large and the team is strong in the tool. Compare it honestly with the cost of a rebuild over the full licence period.
Do we have to adopt dbt?
No. dbt is a common choice for SQL-based transformation and runs natively on several platforms, but the platform’s own services or a retained tool can be equally valid. The decision should follow from your skills and operating model.
Planning a Teradata-to-Snowflake migration?
Review the assessment, conversion, reconciliation and cutover work needed for a controlled transition.