Teradata Migration & Support
Last reviewed by Tyler Eastridge
AceMQ plans and supports the move of a Teradata estate to Snowflake, Databricks, Trino or Starburst, or Greenplum: an inventory, a written comparison of destinations against your workloads, conversion planning and validation, and a parallel run that proves the numbers match. AceMQ engineers lead each engagement and partner data-warehouse specialists do the platform-specific work, under one AceMQ contract. AceMQ is independent of Teradata, produces no Teradata patches and does not rewrite SQL or BTEQ code.
A senior engineer, not an SDR. No sales sequence attached.
Without a reporting blackout or a rewrite projectFor production incident cover, see AceMQ Teradata 24/7 support.
Customers
Partners
The Problem
Most Teradata questions start with a date, a renewal, and turn into an inventory problem: nobody can say what the estate holds or what still runs. These eight cover that, the destination argument and the report that is fast on Teradata and slow everywhere else.
A Teradata renewal is coming and nobody has a written view of what the estate holds or what a move would involve
Three destinations are being discussed in three different teams, each with its own demo and its own slide
Nobody knows how many BTEQ scripts, load jobs and stored procedures exist, or which of them still run
A report that is fast on Teradata runs slowly after a trial load, and the new platform gets the blame
Workload rules that protect the month-end close have no obvious equivalent on the destination
A pilot passed on row counts and no one has compared the numbers the business actually reads
The engineers who know the estate are leaving, and the move depends on what they carry in their heads
A conversion tool reported most code converted, and the rest is the code that matters
A good fit if you run Teradata in production and are weighing a move, need engineers who can be on a bridge in 15 minutes while you decide, or want a written comparison of destinations against your own workloads before you sign anything.
Not a fit for small teams with non-critical workloads. AceMQ is not a budget consultancy: we work with enterprises running business-critical and compliance-heavy Teradata.
How it breaks, and the fix
Teradata spreads each table's rows across its parallel units by hashing the primary index, so a join runs evenly. Load the same table into another platform without choosing a distribution for that engine, and one skewed key can leave one task doing nearly all the work.
Loaded as-is, one task doing the work
One source table, three parallel tasks, the shuffle and the report
Rows are spread across the parallel units by the primary index hash and the report's join runs evenly. The report finishes inside its window, so nobody has looked at how.
The table is copied across unchanged. The join key is skewed, so task 2 receives most of the rows while tasks 1 and 3 finish early and wait. The report runs long, and the new platform gets the blame.
Distribution, partitioning or clustering is chosen for the new engine from the real workload. A parallel run compares results and runtimes against Teradata, which keeps serving until they match.
The first load is the easy part. What decides the outcome is how the workload behaves on the new engine, and that is set before the cutover: how tables are distributed or clustered, how Teradata's workload rules turn into warehouse sizing or queues, how BTEQ and Teradata Parallel Transporter jobs become pipelines, and how stored procedures are rebuilt. The destination vendors publish conversion tools, and their output is a draft to be validated. A parallel run, where both platforms serve the same reports and the numbers are reconciled, is how a team knows the move is done. An inventory, a written comparison of destinations and a pilot are the first AceMQ deliverables.
Our Services
AceMQ runs five Teradata service lines: an estate assessment, a target platform decision, conversion planning and validation, parallel run design, and interim operations of the Teradata estate while you move. A fixed-scope health check is available too. Rewriting SQL or BTEQ code is not one of them.
A written inventory of what the Teradata estate holds and what actually runs, before any destination is chosen.
A written comparison of Snowflake, Databricks, Trino or Starburst and Greenplum against your workloads, with the reasons.
Planning of how Teradata code reaches the destination and checking of what comes out. AceMQ does not rewrite the code.
How both platforms serve the same reports for a period, and how the numbers are compared until nobody doubts them.
Engineers on call for the Teradata estate while the move is under way, so the old platform stays dependable.
Senior engineers on your account, a 15-minute emergency response, no ticket routing and no junior triage.
24/7 Support
AceMQ Teradata support gives you an AceMQ engineer and a 15-minute first response when a load fails or the warehouse is unavailable, 24/7. Lower severities get 1-hour, 4-hour and next-day responses. Teradata's own patches, licences and entitlements stay with Teradata: AceMQ does not provide them.
P1 escalation path
A replay of one P1, from the first page to the written root-cause analysis
15-minute P1 response, 24/7.
A response time, not a resolution time.
P1 opened, on-call engineer paged
Phone, email or Slack reaches the on-call senior engineer directly, whether the incident is in RabbitMQ, Kafka, Redis, PostgreSQL or Kubernetes. No web form, no tier-1 queue.
Senior engineer on your bridge
A senior engineer who already knows your environment joins a live bridge, so nobody has to re-explain your topology.
Specialists across the stack join
When an incident crosses components, the engineers who know each one join. For RabbitMQ, the path runs to the core team.
Written root-cause analysis
Root cause, the fix applied and the prevention steps, delivered after every P1.
Beyond SLAs — the model behind senior-only, zero-cold-start expert access.
Tickets go to senior engineers briefed on your environment, not an anonymous queue. The proposal states who does the work.
Any ticket can be escalated to a live session with an engineer through calendar booking. No gatekeeping and no approval step.
Scheduled health checks on your deployment and alerts on risks in the versions you run, so problems surface before they reach production.
Proactive alerts on critical bugs and CVEs affecting your exact version, with version compliance monitoring so you're never caught off guard.
How It Works
An AceMQ Teradata engagement runs in four stages: a scoping call with a quote within 1 hour, a read-only inventory of the estate, a written comparison of destinations against your workloads, then a pilot and a parallel run. Each stage ends in writing.
Quote within 1 hour
A senior AceMQ engineer asks what you run: the Teradata estate and where it is hosted, how many databases, jobs and users, which reports matter most, which destinations are in play and what is driving the date. A quote request is answered within 1 hour.
Scoped per estate
A read-only inventory of databases, tables, views, procedures, BTEQ and load jobs, workload rules and the reports that depend on them, with data volumes and usage. Nothing in production changes, and the findings are written.
Scoped per estate
A written comparison of the destinations against your own workloads, with a pilot domain proposed. Support cover for the Teradata estate during the move starts here if you want it.
Ongoing
A pilot domain moved first, a parallel run that reconciles results, and a cutover by domain with Teradata kept running until the numbers match. On-call response with a 15-minute P1 SLA throughout.
A senior engineer, not an SDR. No sales sequence attached.
Parallel run
The move is finished when the business reads the same numbers on the new platform as on Teradata, not when the last table is loaded. A parallel run is how that is shown. This is the order the work runs in.
Freeze
Agree which databases, jobs and reports are in the first domain and which are retired, using the inventory. Retiring unused objects is the cheapest part of the move.
Pilot
Move one domain with the destination's own tools, validate the converted code and choose distribution, partitioning or clustering for the new engine instead of copying Teradata's.
Reconcile
Serve the same reports from both for a period. Compare row counts, checksums and the figures the business reads, and compare runtimes under real load.
Cut over
Repoint reports one domain at a time. Teradata stays available as the rollback until the retirement criteria written at the start are met.
Typical engagements
Typical engagements from AceMQ on moving a warehouse, with the environment, what AceMQ assesses and what the engagement delivers. Each card links to the full write-up.
Enterprise Data Warehouse Team
Inventorying a Teradata estate, comparing Snowflake, Databricks and Trino against its workloads, and planning a pilot and a parallel run.
Snowflake
Databricks
StarburstGlobal Insurance Group
Resolving pipeline runtime blowouts caused by queries spilling to remote storage on undersized warehouses while concurrent jobs queued behind them.
Snowflake
dbt
Airflow
TerraformRetail Analytics Provider
Ongoing support for Snowpipe, stream, and task failures including stale streams past their retention window and silent partial-load conditions.
SnowflakeSnowpipeAirflow
S3Solutions
AceMQ covers Teradata end to end. Projects: consulting and implementation, health checks and migrations. Ongoing cover in four tiers, from 24/7 support and incident management to proactive monitoring, managed Teradata on your infrastructure and fully managed Teradata on AceMQ infrastructure, plus end-of-life versions.
Projects
Fixed-scope work led by a senior engineer: architecture and new builds, a health check of what you run today, or a migration with a reversible cutover.
Support and managed services
Four tiers of ongoing cover once you are live. Each tier hands more of the day-to-day work to AceMQ, from a 15-minute emergency SLA to AceMQ hosting and running Teradata for you.
Compare the four Teradata support tiersSide by side
No destination is best for every Teradata estate, and AceMQ works with all four below. This table sets out what each one is, how Teradata code gets there, how it is billed and where it fits. BigQuery is another common destination; it is not compared here.
| Question | Snowflake | Databricks | Trino or Starburst | Greenplum |
|---|---|---|---|---|
| What kind of platform is it? | A fully managed warehouse service. There are no servers or versions to run. | A lakehouse platform built on Apache Spark and Delta Lake, with notebooks and jobs beside SQL. | A distributed SQL query engine that reads data where it sits. It needs storage underneath, such as object storage with Iceberg tables. | A massively parallel database built on PostgreSQL, shared-nothing like Teradata. Your team runs it. |
| How does Teradata code get there? | Snowflake publishes a code converter, SnowConvert, with Teradata-specific options. Output is a draft that is validated. | Databricks Lakebridge lists Teradata among its SQL source dialects. It converts code and does not move data. | Teradata-specific syntax, BTEQ scripts and stored procedures are rewritten for Trino's SQL, by hand or with tools. | Teradata-specific syntax and stored procedures are rewritten for the PostgreSQL dialect. |
| How is it billed? | Credits for compute, plus storage. Warehouse design decides the bill. | Databricks units for compute plus the cloud infrastructure underneath. | Compute you run, or Starburst's commercial editions, plus storage billed separately. | Hardware or cloud instances you run. Greenplum has been a commercial product since May 2024, so the licence or a fork is a decision. |
| What does it do well with a Teradata workload? | BI and SQL reporting on elastic compute, where the warehouse is the whole job. | Estates that also need data engineering, machine learning or streaming beside the warehouse. | Querying several sources in place, or staging a move so that not everything has to be copied first. | A like-for-like architecture for teams that want to keep running an MPP database themselves. |
| What is hard? | Cost control after the move, and re-creating Teradata workload rules as warehouse sizing. | Warehouse-style governance and concurrency need design, and SQL tuning differs from Teradata. | It is an engine, not a warehouse: table maintenance, catalogs and storage are yours. | Staying on a platform that is smaller than the cloud warehouses, and carrying its operations yourself. |
To compare the two cloud destinations in depth, read Databricks vs Snowflake compared.
One partner, not five
Teradata rarely fails in isolation. AceMQ covers the full surrounding infrastructure — so one team owns the whole path instead of pointing at each other.
Guides, articles and comparisons
A comparison from AceMQ engineers of Databricks and Snowflake on architecture, cost model and migration, plus the AceMQ services for the destinations: Snowflake, Databricks, Starburst and Greenplum.
FAQs
Five answers on Teradata from AceMQ: what AceMQ will and will not do, how to choose a destination, who rewrites the SQL, how to keep the old estate supported during the move, and how a parallel run proves the numbers match.
Still have questions about Teradata? Email an Expert
AceMQ inventories the estate, compares destinations against your workloads, plans conversion, validates results through a parallel run and can support the Teradata estate meanwhile, with AceMQ engineers and partner data-warehouse specialists under one contract. AceMQ does not rewrite SQL or BTEQ code, produce Teradata patches, advise on Teradata licensing or act as a Teradata or destination-vendor partner.
It depends on the workload. Snowflake fits SQL reporting on elastic compute, Databricks fits estates that also need data engineering or machine learning, Trino or Starburst fits querying data in place, and Greenplum fits teams that want a like-for-like parallel database they run themselves. AceMQ writes the comparison from your inventory and does not favour one.
No. Rewriting code is outside AceMQ's scope. The destination vendors publish conversion tools, and their output is a draft to validate. AceMQ plans how code is converted, builds the tests that check it and lists the changes that remain for your team or another provider.
Yes. AceMQ engineers can be on call for the estate during the move with a 15-minute emergency response, 24/7. Teradata's own patches, licences and entitlements come from Teradata under your contract, and AceMQ does not provide them.
By running both platforms in parallel before cutover. Row counts and checksums come first, then the figures in the reports the business reads, then runtimes under real load. The retirement criteria for Teradata are written down at the start, so the end of the parallel run is not a judgement call.
Yes. AceMQ works on Teradata in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual contract that covers 24/7 support and proactive reviews. Many teams start ad hoc and move to an annual contract once the first engagement is done.
Every AceMQ proposal is tailored to your requirements: your Teradata environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how Teradata is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.
Let's talk
A senior AceMQ engineer reviews your Teradata estate, tells you what comparison or cover fits, and quotes it. Quote requests are answered within 1 hour.
Production incident right now?Email a Teradata Architect
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.comPrefer to talk now? Call us directly or use the consultation tab to find a time that works.
