Teradata to Databricks Migration: A Mid-Market Playbook

Key Takeaways

A Teradata to Databricks migration moves tables, BTEQ scripts, stored procedures and load jobs from a Teradata warehouse onto a Databricks lakehouse governed by Unity Catalog. For a mid-market team, the fastest safe route is to retire unused objects, convert SQL with Lakebridge plus manual review, move data in bulk with Teradata export utilities, and cut over one subject area at a time.

• Cost: the saving comes from ending fixed Teradata capacity and paying for compute as used, but only if SQL warehouses are sized and auto-stopped.
• Effort: procedural code (BTEQ, macros, stored procedures) is the bulk of the work, not the tables.
• Risk: silent differences in case sensitivity, duplicate handling and date logic produce plausible wrong numbers.
• Fit: it makes sense when a renewal or hardware refresh forces a decision and you want analytics and AI on one platform.

Most mid-market Teradata estates were built by a team that has since moved on. The warehouse still runs month-end, but the BTEQ scripts, macros and load jobs that feed it are understood by two people, and the renewal quote arrives every few years regardless. Meanwhile the business wants AI on that data, and only 7% of enterprises in a March 2026 Cloudera and Harvard Business Review Analytic Services survey say their data is completely ready for AI.

The destination is no longer a gamble. Databricks reported in its December 2025 funding announcement that its Data Warehousing product passed $1 billion in annual revenue run-rate. Warehouse workloads on the lakehouse are now mainstream, not experimental.

The published guidance mostly comes from two places: large systems integrators pitching multi-year programmes and tooling vendors pitching their converter. Neither fits a team with a few hundred active tables, a handful of engineers and a renewal date on the calendar. This Teradata to Databricks migration playbook is written for that team.

Start With the Estate, Not the Tools

Teradata estates accumulate. Over ten or fifteen years you collect staging databases, abandoned marts, views built on views and load scripts that run but feed nothing. Migrating all of it is the most expensive mistake available.

So the first step is Lean Six Sigma, not code. Pull object metadata from the Teradata data dictionary and join it to query logging so you can see which tables and views are read, by whom and how often. Anything unread for a quarter goes on a retirement list with a named owner. In most estates we assess, that list is long, and every object on it is one you never convert, test or pay to store.

This is the Assess and Innovate half of our AIM-IT method (Assess, Innovate, Model, Implement, Track). You fix the scope and the workflow first, then automate the move.

What Converts Cleanly and What Needs a Person

Lakebridge is Databricks’ free migration toolkit, announced in June 2025 and published as a Databricks Labs project. It has three parts: an analyzer that profiles the legacy estate, a converter that translates SQL and ETL scripts including stored procedures, and a validator that reconciles results. Teradata is one of the named sources. Databricks says it automates up to 80% of migration tasks. Its documentation describes several transpilers with different dialect coverage, which is why output quality varies by source and by code style.

Databricks SQL supports QUALIFY on Databricks Runtime 10.4 LTS and above, which removes one of the most common Teradata rewrite headaches. The harder items are procedural. A converter that finishes without errors has translated syntax, not proven the logic is equivalent.

Where Teradata Migrations Go Wrong

These are the problems that surface in Teradata moves specifically. Each one produces numbers that look right and are not.

• Case sensitivity changes answers. Teradata columns are often defined as not case specific, so a filter on ‘ACME’ also matches ‘Acme’. Databricks string comparisons are case sensitive by default. Joins and filters silently return fewer rows unless you find and handle every one.
• SET tables hide duplicates. A Teradata SET table rejects exact duplicate rows on insert. Delta tables do not. Loads that relied on that behaviour start writing duplicates into the lakehouse, and totals drift upward.
• Procedural logic lives outside version control. BTEQ scripts and macros are often scattered across scheduler servers and personal folders. If discovery misses them, a downstream report breaks after cutover and nobody knows which script fed it.
• Data movement is slower than planned. Pulling large tables over JDBC is the easy path and the slow one. Bulk export with Teradata Parallel Transporter to files in cloud storage, then ingesting with Auto Loader, scales far better for historical loads.
• Tuning habits do not transfer. Primary index choices and statistics collection were how Teradata performance was managed. On Delta tables the levers are different: file layout, clustering and warehouse sizing. Copying the old physical design adds work without adding speed.

The Migration Sequence We Run

In a Teradata to Databricks migration, for each subject area, such as finance, supply chain or customer, the order is the same. Keep each wave small enough to roll back.

1. Inventory and retire. Build the object list from the data dictionary and query logs, then sign off the retirement list with business owners.
2. Design the target. Define Unity Catalog catalogs and schemas, a medallion architecture of bronze, silver and gold, naming standards and the grant model.
3. Convert. Run Lakebridge analysis and conversion, then review every stored procedure, macro and BTEQ script by hand. Record each case sensitivity and SET table decision explicitly.
4. Move history. Export large tables with TPT to cloud storage, ingest to bronze, and rebuild silver and gold with Lakeflow Declarative Pipelines.
5. Keep data flowing. Stand up incremental loads so the lakehouse stays current while Teradata remains the system of record.
6. Reconcile. Compare row counts, measure sums and key hashes table by table, then compare the headline reports business users trust. Schedule the checks in Lakeflow Jobs so they run after every load.
7. Cut over. Repoint BI and downstream feeds, keep Teradata read-only for an agreed rollback window, then decommission that subject area.

For the wider pattern beyond Teradata, see our guide to warehouse to lakehouse migration and our view on data warehouse modernization.

Are You Ready to Start? Signals For and Against

You are ready when

• You have a date that forces the decision, such as a renewal or hardware refresh, at least two quarters out.
• A business owner for each subject area will sign off reconciled numbers and the retirement list.
• You can name the people who understand the BTEQ scripts and macros, and they are available for review.
• Query logging is on, so you can prove which objects are actually used.
• You have agreed a Unity Catalog naming and access model before the first table lands.

You are not ready when

• Nobody can say which reports depend on which tables, and there is no plan to find out.
• The plan is a single weekend cutover of the whole estate.
• The budget assumes the converter handles everything and leaves no time for procedural code.
• Teradata data quality problems are known but expected to disappear on the new platform. They move with the data unless you fix the process that creates them.

If most of the first list is true, start with a scoped assessment of one subject area. Our Databricks consulting engagements begin there, with the estate inventory and process map before any code is converted.

Frequently Asked Questions (FAQs)

How long does a Teradata to Databricks migration take?

It depends on active object count and the volume of procedural code, not raw data size. Scoping one subject area and running it through reconciliation and cutover gives you a measured pace for the rest of the estate. Retiring unused objects first is the biggest single time saver.

Does Lakebridge support Teradata?

Yes. Databricks names Teradata among the sources Lakebridge covers, and the toolkit includes an analyzer, a converter and a reconciliation validator. It is a free Databricks Labs toolkit rather than a fully supported core product, so plan engineering review time for converted stored procedures and BTEQ scripts.

Can we keep Teradata running during the migration?

Yes, and you should. Teradata stays the system of record while incremental loads keep the lakehouse current. You compare outputs on both platforms until they reconcile, then cut over one subject area at a time with a read-only rollback window.

What is the best way to move large Teradata tables?

For historical volumes, export in bulk with Teradata Parallel Transporter to files in cloud storage and ingest them into Delta tables with Auto Loader. JDBC extraction works for small tables but is usually the slowest path at scale.

Will our Teradata SQL run unchanged on Databricks?

Much standard SQL will, including QUALIFY, but not all of it. Watch case sensitivity, SET table duplicate handling, date and time functions, and anything procedural. Reconciliation against Teradata output is the only reliable proof that converted logic matches.