Migration · From Teradata
From Teradata, code included
Forge moves the warehouse and the logic around it — views, macros, procedures and BTEQ scripts — to BigQuery, Cloudera, Oracle or PostgreSQL, and proves every object before the cut-over.
What Forge migrates
From Teradata to the target you choose
- Tables
- Structure, types and column defaults, then the data — large tables in waves of their own.
- Views
- Translated to the target's dialect and proven by running both sides.
- Macros
- Turned into the target's table functions, with the same parameters.
- Procedures
- Translated and deployed; when the target rejects one, Forge repairs it from the error.
- BTEQ scripts
- Read as programs, with their dependencies, and turned into notebooks on the target.
How it runs
From assessment to cut-over
- 01
Assess
A report from the catalog and the code itself: what migrates on its own, what needs a decision, and the data to move.
- 02
Plan
Waves in dependency order, so every object lands after what it uses.
- 03
Translate and prove
Each object translated, deployed and compared with the source — counts, aggregates and row fingerprints for tables, results for code.
- 04
Cut over
Jobs arrive switched off. Activating them is the cut-over, on the day you choose.
Where Forge stops and asks
- Logic that can be translated in more than one faithful way is held for a person instead of guessed.
- On BigQuery, row-by-row loops are flagged with a set-based alternative for you to approve.
See it on your own data
We'll set up Qry against a dataset you choose and walk you through it — one hour, no slides.