Teradata Migration to AWS: The Cost Pattern That Decides It

Teradata migration decisions tend to get made in the months before a support renewal, when a quote for another three years and a hardware refresh lands on the CFO's desk. The engineering case for moving has usually been obvious for a while. What changes is that the cost of staying finally has a date and a number attached to it.

The running example in this guide is made up but typical. A regional wireless carrier with about 3.5 million subscribers put its analytics on an on-premises Teradata system in 2011, and over the years call detail records, billing reconciliation, churn models and network planning all ended up there.

By this fall that came to about 180 terabytes, loaded every night by roughly 4,200 BTEQ scripts and 300 load jobs that nobody had counted before the renewal quote arrived. Its support contract and a hardware refresh come up for renewal next September 30, and the quote is about $13.5 million for three years. The figures in this guide are illustrative and rounded, but the shape of the problem is a common one.

We've been moving data platforms onto AWS for 18 years, and a Teradata exit is often the first big move in a wider data modernization program.

Ammar Nizami's guide to it makes the economic point in passing: "retiring legacy warehouses removes duplicate pipelines and licensing." The catch is that those savings only show up once the old warehouse is actually switched off, and the timing of that switch-off decides most of the business case.

What does a Teradata migration cost?

Usually less than staying over a three-year term, but only once the old system is gone. There's a one-time bill for converting code, moving data, testing and running both systems side by side, and then a new run rate on AWS that replaces the Teradata support, hardware and data center lines. The carrier's numbers look like this.

The AWS line depends a lot on how compute is bought. Redshift Serverless is billed per RPU-hour, at $0.375 in US East (N. Virginia), and AWS says serverless reservations cut that by up to 45% on a three-year term or 24% on a one-year term. For a warehouse like the carrier's, where the nightly load and the morning dashboards are predictable, we'd reserve the base and let the rest scale on demand.

What is the cost pattern behind the decision?

Teradata costs stay fairly flat for the life of a contract and then jump at renewal, when support resets and the hardware refresh arrives. A migration adds a block of one-time spend before the run rate falls, so the whole decision comes down to where that spending sits relative to the renewal. Over the three years after September 30, the carrier's options compare like this.

The last row is the one worth staring at. A slip of a few weeks past September 30 would force the carrier into the shortest extension its Teradata account team offered, which was a year, and that alone costs more than the migration. A tougher negotiation with AWS or with Teradata might move the total by a few hundred thousand dollars, while the date moves it by millions, which is why we'd plan backward from the renewal rather than forward from kickoff.

Why does the renewal date matter more than the discount?

Because the license line is the one cost that no tuning can touch. Kaja Hussain, a Sr. FDE in Database and Application Modernization at Mactores, puts it this way in a piece on AWS cost optimization: "Commercial database licenses are the biggest cost we find that a FinOps tool can't touch."

The same piece is plain about what follows, "We'd treat the renewal date as the real deadline," and for the carrier that means a plan that ends with Teradata switched off before September 30, not one that starts in January and sees how far it gets.

It also changes how to think about running both systems at once. While the carrier is still inside its current contract, the parallel runs cost very little extra, because the Teradata system is paid for either way. A parallel run that crosses the renewal is the expensive kind, and our page on Teradata to Amazon Redshift migration is blunt about it: "a warehouse left running 'just in case' is a second bill, not a safety net."

Where does the money go in a Teradata to Redshift migration?

Mostly into code. Of the carrier's $2.6 million one-time budget, about three-quarters goes to converting and testing BTEQ scripts, TPT and FastLoad jobs, macros and stored procedures, and to proving that the results match. Copying 180 terabytes, the part people tend to worry about first, is one of the smallest lines.

Ammar Nizami, a Senior Forward-Deployed Engineer in our Data Engineering practice, says as much in a guide to Amazon Redshift as an enterprise data warehouse: "We've rarely seen the data copy be the hard part of a Redshift migration." The hard part is behavior that Teradata users stopped noticing years ago.

Teradata SET tables quietly reject duplicate rows and Redshift tables don't, so a churn report that had been deduplicated by accident for a decade can double-count subscribers on its first run. String comparisons that were case-insensitive on Teradata are case-sensitive by default on Redshift, so a join on plan codes like "UNL5G" and "Unl5G" can drop rows without raising an error.

AWS SCT does a lot of the first pass. It converts Teradata BTEQ scripts to Amazon Redshift RSQL, and its assessment report lists the commands and statements it can't convert, which becomes the engineers' to-do list. At the carrier, we'd expect the scheduler and its 300 load jobs to need more hand work than the SQL itself, which makes the nightly batch a data pipeline modernization job in its own right rather than a footnote to the warehouse move.

Should you stay on Teradata, move to VantageCloud or migrate to AWS?

The carrier's CFO asked first whether Teradata itself was going away, and it isn't: the company's second-quarter 2026 results show total ARR of $1.509 billion and public cloud ARR growing 8% to $686 million.

That cloud business is VantageCloud, which keeps BTEQ and Teradata SQL working. Teradata's own pricing page starts VantageCloud Lake at $4,800 a month and VantageCloud Enterprise at $9,000, billed a year in advance, and it notes that unused units don't roll over.

That makes VantageCloud the lowest-risk move and, for the carrier, the middle option on cost. Here are its three paths, in the questions its CFO and data team actually asked.

We'd also look at where the data sits after the move. Ammar's piece on Apache Iceberg on AWS makes the case in one line: "Picking a table format is really picking who controls your data."

For the carrier, that argues for keeping its call detail records as Iceberg tables on Amazon S3 that Redshift and Amazon Athena both query, so the next platform decision doesn't come with an exit bill like this one. On Snowflake or Databricks the conversion work would look much the same; the run rate, the tooling and where the data lives afterward are what would change.

The carrier had eleven months, which is enough. With less than six months left and no count of the scripts, we'd tell a team to sign a short renewal or move to VantageCloud and use the time to do the inventory properly, since a rushed migration that slips past the date costs more than either.

How do you keep the dual-running period short?

By cutting over one domain at a time and switching off its Teradata path as each one goes, so you're never running everything twice. Ammar's data modernization guide puts the rule simply: "Decommission the legacy path per domain only after its consumers have fully cut over."

For the carrier, we'd start with billing reconciliation, because finance checks it every month and a mistake there would surface fastest. Network analytics and the call detail records would follow, then churn and marketing. Each wave gets its own parallel run, and the billing wave would run through at least one month-end close, with row counts, checksums, aggregates and report outputs compared until the numbers agree.

The riskiest conversion gets proven first, even when its domain cuts over last. Our how we work page puts it as "If a plan is going to break, it should break in week three on a proof rather than in month five on a deadline," and at the carrier that proof would be the SET-table and case-sensitivity fixes on the churn model, tested in the first weeks of the build against a year of real subscriber data.

How long does a Teradata migration take?

For one well-scoped domain, about 12 weeks from kickoff to production, which is the median across our engagements. The carrier has three domains and about eleven months until its renewal, so the plan runs backward from September 30.

Discovery and a signed scope take November and December, billing is in production by April, network analytics by June and churn and marketing by August, and the Teradata system is switched off in September with a few weeks to spare.

Those dates only mean something if someone stands behind them. Under our delivery commitment, the ship date and the fee are fixed once the scope is signed, and Mactores carries the cost of the additional work if a delay inside our control moves the date.

Where does the money for a Teradata migration come from?

Mostly from the renewal you're not signing. For the carrier, the $13.5 million quote is the budget the migration replaces, and the savings become real only when Teradata is switched off. Synaptics' Oracle exit followed the same logic, and its case study sums it up: "The license renewal that was inevitable became the budget that funded the next initiative."

AWS can help with the one-time cost, too. Its data warehouse migration page describes a Database Freedom program with "funding to accelerate progress at all stages of a migration," and for eligible workloads the Migration Acceleration Program (MAP) can help offset part of the migration cost as well, so it's worth asking your account team before the scope is signed.