# Teradata to Databricks

> TechFabric migrates Teradata estates to Databricks with TechFabric Airlift. The first two weeks are the Migration Readiness Sprint: objects, load utilities, macros and the consumers that still point at Viewpoint schedules. Lakebridge converts the SQL it can. BTEQ, FastLoad, MultiLoad, TPT and the primary-index design stay with a person.

Source: Teradata
For: Teams leaving Teradata whose load jobs and macros are still the system of record
Length: Two weeks
Canonical: https://www.techfabric.com/databricks/from-teradata

---

Know what the Teradata estate contains before you pick a date

A Teradata estate is old in ways a table count will not show. BTEQ, FastLoad, macros and primary indexes are the work. Two weeks on TechFabric Airlift inventories the objects, names the load jobs and writes down what will never convert.

## What we look at

- Tables, including SET versus MULTISET, and the primary indexes that still decide how they are read
- Macros, stored procedures and UDFs, and which of them hide a rule nobody wrote down elsewhere
- BTEQ, FastLoad, MultiLoad and TPT jobs, and the windows they actually run in
- Viewpoint schedules and the downstream consumers that still wait on them
- Character sets and export encodings that have bitten previous extracts
- Volatile tables and staging patterns that look unused until a nightly job misses them

## What a person still has to do

- Primary indexes are not partitions. Access paths have to be redesigned against how the table is actually queried.
- BTEQ, FastLoad, MultiLoad and TPT become an ingestion path we choose. They do not convert.
- Macros and procedures stay in the residue until someone reads the business rule inside them.
- Viewpoint schedules become Databricks Jobs or Lakeflow. The clock and the dependencies have to be redrawn.
- Encoding and export quirks show up in the first extract, which is why the hard-object pilot is chosen early.

## Questions

### Can you migrate Teradata to Databricks?

Yes. Teradata is one of the twenty-seven source platforms with an executable Airlift playbook. The first two weeks are the Migration Readiness Sprint at /databricks/migration-readiness. The load utilities and the macros are why that sprint exists.

### Do you convert BTEQ and FastLoad?

No, and we will not pretend to. Those jobs become an ingestion path on Databricks, designed against the windows they actually run in. The sprint lists every one of them and names an owner, so they are not discovered the weekend of cutover.

### Our Teradata estate is twenty years old. Is two weeks enough?

It is enough to know what you are looking at. The inventory, the exclusions and the hard-object pilot are the point. A twenty-year estate is exactly why you do not estimate off a table count.

### Does the sprint commit us to leaving Teradata?

No. It is fixed fee and it ends with a recommendation. Some estates should move and some should wait, and the assessment exists to tell you which one you have before anybody commits. Week two is when we say which.