Overview
A typical request: a data warehouse team facing a Teradata renewal wants a written view of what the estate holds, which destination fits it and how the move would be proven. AceMQ and partner data-warehouse specialists deliver an assessment and a plan, scope and process, not a migration. Rewriting SQL and BTEQ code is outside AceMQ's scope.
Challenge
Three destinations are usually under discussion in three teams, each with its own demo. Nobody has a count of BTEQ scripts, load jobs and stored procedures, or knows which still run. Workload rules that protect the month-end close have no obvious equivalent on the destination. A trial load that passes on row counts can still run slowly because the distribution that suited Teradata does not suit the new engine, and the new platform gets the blame.
Environment
A Teradata Database estate on premises or hosted, hundreds of tables and views, BTEQ and Teradata Parallel Transporter jobs, stored procedures, workload rules, and reporting tools that business users depend on.
Approach
AceMQ inventories databases, objects, jobs, users and usage, and ranks the reports that matter most. It compares Snowflake, Databricks, Trino or Starburst and Greenplum against the workloads on workload fit, cost model and operating effort, and proposes a pilot domain. For the pilot it plans conversion with the destination vendor's tools, treats their output as a draft, and designs a parallel run that compares row counts, checksums, report figures and runtimes.
Solution
- Inventory of databases, tables, views, procedures, BTEQ and load jobs, and users, with usage and data volumes
- Ranking of reports and workloads by business importance, with unused objects flagged for retirement
- Written comparison of Snowflake, Databricks, Trino or Starburst and Greenplum against the workloads, with the reasons
- Conversion plan for the pilot domain using the destination's own tools, with test cases for converted and unconverted code
- Parallel-run design: reconciliation of counts, checksums and report figures, plus runtime comparison under real load
- Retirement criteria for Teradata written down in advance, and a cutover outline by domain with a rollback
Outcome
The team receives a written inventory, a destination comparison grounded in its own workloads, a conversion and validation plan for a pilot domain, a parallel-run design and the criteria for retiring Teradata. The choice of destination and the decision to move at all stay with the team.
Technologies
Snowflake
Databricks
Starburst
Apache Hive
Apache Spark
dbt
Terraform
Airflow
PostgreSQL
Kubernetes
Trino
