Implement Teradata migrations across SQL, BTEQ, load utilities, transfer throughput, hash-aware reconciliation, and Databricks modernization.

Migrate Teradata with Airlift

The Teradata profile covers SQL, macros, stored procedures, BTEQ, FastLoad, MultiLoad, TPT, volatile tables, workload management, security, and downstream consumers. Airlift keeps utility and orchestration objects visible so a converted SQL percentage cannot hide the work required to run the target estate.

What Airlift adds to a Teradata migration

Stage	Databricks tool or project adapter	Airlift responsibility
discover	Lakebridge Profiler and Analyzer scan SQL plus BTEQ and utility exports	accept inventory, dependencies, exclusions, profiler variant, source version, and report digests
plan	assessment and unload benchmarks inform target architecture	assign owners and dependency-aware waves; preserve utility, workload, procedural, and human-work decisions
convert	BladeBridge converts supported Teradata SQL	record attempts, tool generations, artifact digests, warnings, and residue lanes
move data	utility-backed unload plus a source-specific incremental strategy	track manifests, watermarks, throughput, lag, restart checkpoints, rejected rows, counts, and reconciliation
validate	hash-aware Lakebridge Reconcile plus utility, workload, and business scenarios	admit independent evidence with the exact hash configuration, source watermark, and target snapshot
certify	Airlift evaluates the active readiness profile	mint a signed certificate identifying artifacts, snapshots, evidence, hash policy, and validation profile
cut over	project utility, BTEQ, schedule, application, and BI effectors	freeze scope, enforce approvals, checkpoint, apply once, verify, and retain rollback evidence
modernize	Unity Catalog, Lakeflow, Delta, liquid clustering, and Databricks SQL work	separate appliance redesign from baseline parity certification

This makes unload throughput, utility replacement, BTEQ control flow, workload behavior, and downstream consumers part of readiness instead of hiding them behind converted SQL.

Compile the executable migration pack

Export SQL, macros, procedures, BTEQ scripts, utility jobs, workload rules, grants, and consumers into a credential-free manifest. Select teradata_vantage or teradata_appliance, record the observed hard cases, then compile it:

fa migration-pack inspect --file teradata-manifest.json
fa migration-pack plan --file teradata-manifest.json --json > teradata-plan.json
fa migration-pack register --file teradata-plan.json \
  --engagement-id <engagement-id> --estate-id <estate-id> \
  --artifact-id <immutable-artifact-reference> --idempotency-key <stable-key>

The compiler preserves BTEQ and utility dependencies, routes proprietary behavior to an explicit remediation owner, and emits utility restart, watermark, reconciliation, validation, target, and deployment requirements. See migration-pack commands for the complete contract.

Inspect and generate a plan

fa source inspect teradata
fa source plan td --json > .airlift/teradata-plan.json

Profile and analyze

Choose the core profiler variant when PDCR is unavailable; use pdcr only when the client has the required environment and access.

databricks labs lakebridge configure-database-profiler
databricks labs lakebridge test-profiler-connection --source-tech teradata
databricks labs lakebridge execute-database-profiler \
  --source-tech teradata \
  --variant core \
  --output-folder ./artifacts/profile

databricks labs lakebridge analyze \
  --source-directory ./source-export \
  --source-tech "Teradata" \
  --report-file ./artifacts/teradata-analysis.xlsx \
  --generate-json true

Convert

databricks labs lakebridge transpile \
  --source-dialect teradata \
  --input-source ./source-export/sql \
  --output-folder ./artifacts/converted

BladeBridge is the preferred deterministic path. BTEQ control flow, load utilities, volatile-table assumptions, query bands, workload rules, and proprietary procedural logic commonly require explicit target implementations.

Transfer and reconcile

Benchmark utility-backed unload throughput before promising a cutover window. Return restart checkpoints, file manifests, source watermarks, lag, counts, and rejected rows through the transfer adapter.

databricks labs lakebridge configure-reconcile
databricks labs lakebridge auto-configure-recon-tables
databricks labs lakebridge reconcile

Teradata has no portable cryptographic hash in pure SQL. Lakebridge row, data, and all reports require a source hash UDF and hash_expression_overrides.source in the reconcile configuration. Without that setup, use schema reconciliation plus admitted Experiments parity scenarios; do not claim full row/data reconciliation.

Validate SET/MULTISET behavior, primary-index assumptions, QUALIFY, ordered analytics, format/character semantics, utility restart, and workload-sensitive performance.

Certify and cut over

Do not resolve full data parity from a row/data report unless the required source hash UDF and override configuration were used and recorded. Assign separate profiles to BTEQ, utilities, procedures, workload behavior, and consumers. The project effector switches loads, schedules, queries, applications, and BI connections only after fresh certificates, approved scope, measured transfer completion, and rollback readiness are confirmed.

Modernize after parity

Replace BTEQ and appliance utilities with Lakeflow or Databricks jobs, use Delta and liquid clustering based on measured workloads, and map security into Unity Catalog under a new release profile.

Complete developer command sequence

Generate this exact recipe from the installed CLI so the guide and executable surface stay in sync:

fa source recipe teradata
fa source recipe teradata --variant teradata_vantage --json > .airlift/teradata-recipe.json

The App is engagement-aware. Teradata appears under Active sources only after the source estate is added to an active engagement. The menu is derived from governed engagement scope; installing Airlift does not expose unrelated source pages.

Every remote mutation below requires --host, --org, authenticated workspace identity, and a stable --idempotency-key. JSON request files contain identifiers, artifact references, and opaque credential references—never passwords, tokens, or connection strings. Run fa <resource> <operation> --help for the current schema and exit semantics.

0. Inspect the source contract

fa source inspect teradata --json > .airlift/teradata-profile.json
fa source plan teradata --variant teradata_vantage --json > .airlift/teradata-capability-plan.json

Expected artifacts:

.airlift/teradata-profile.json
.airlift/teradata-capability-plan.json

Open Engagements → active engagement in the App. This stage is visible at /engagements after replacing the placeholder ID with the governed engagement ID.

1. Create governed scope and connection references

fa engagement create --file engagement.json --idempotency-key migration-create-v1
fa estate register --file teradata-estate.json --idempotency-key teradata-estate-v1
fa connection register --file teradata-connection.json --idempotency-key teradata-connection-v1
fa engagement update --file teradata-scope.json --idempotency-key teradata-scope-v1
fa engagement preflight <engagement-id>

Expected artifacts:

Governed engagement
Source estate
Opaque connection binding

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id> after replacing the placeholder ID with the governed engagement ID.

2. Assess and accept inventory

fa assessment start --file teradata-assessment-start.json --idempotency-key teradata-assessment-start-v1
fa assessment status <assessment-id> --json
fa assessment record --file teradata-assessment-record.json --idempotency-key teradata-assessment-record-v1
fa assessment accept --file teradata-assessment-accept.json --idempotency-key teradata-assessment-accept-v1
fa inventory list --estate-id <estate-id> --json

Expected artifacts:

Assessment report reference
Normalized inventory
Dependency graph

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/sources/teradata after replacing the placeholder ID with the governed engagement ID.

3. Compile the teradata migration pack

fa migration-pack inspect --file teradata-manifest.json
fa migration-pack plan --file teradata-manifest.json --json > generated/teradata-plan.json

Expected artifacts:

Dependency-aware migration pack
Transfer requirements
Validation requirements
Residue lanes

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/artifacts after replacing the placeholder ID with the governed engagement ID.

4. Convert, move, and remediate

fa plan generate --file teradata-migration-plan.json --idempotency-key teradata-plan-v1
fa conversion batch create --file teradata-batch.json --idempotency-key teradata-batch-v1
fa conversion batch start --file conversion-batch-start.json --idempotency-key conversion-start-v1
fa residue list --engagement-id <engagement-id>
fa transfer plan --file teradata-transfer.json --idempotency-key teradata-transfer-v1
fa transfer run <transfer-id> --idempotency-key transfer-run-v1
fa transfer reconcile <transfer-id> --idempotency-key transfer-reconcile-v1

Expected artifacts:

Target artifacts
Residue cases
Transfer checkpoints
Reconciliation evidence

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/runs after replacing the placeholder ID with the governed engagement ID.

5. Validate independently and inspect discrepancies

fa validation run --file teradata-validation.json --idempotency-key teradata-validation-v1
fa validation status <validation-execution-id> --json
fa discrepancy list --engagement-id <engagement-id>
fa artifact list --engagement-id <engagement-id>

Expected artifacts:

Provider run references
Readiness evidence
Discrepancies

Open Engagements → active engagement in the App. This stage is visible at /engagements/<engagement-id>/runs after replacing the placeholder ID with the governed engagement ID.

6. Certify, cut over, and export evidence

fa certificate list --object-id <object-id>
fa cutover status <wave-id> --json
fa evidence list --engagement-id <engagement-id>
fa evidence export --file teradata-evidence-export.json --idempotency-key teradata-evidence-export-v1

Expected artifacts:

Migration certificates
Cutover evidence
Content-digested evidence export

Open Engagements → active engagement in the App. This stage is visible at /assurance after replacing the placeholder ID with the governed engagement ID.

Runway executes releases; Experiments owns validation verdicts; Airlift owns migration readiness and cutover policy.

What developers see in the App

The contextual source workspace shows the accepted estate and the factory stages for this engagement. Artifacts displays immutable references, content digests, media types, and provider lineage. Runs displays assessment, conversion, transfer, validation, and deployment executions without treating a provider's success as an Airlift verdict.

Airlift Teradata source workspace showing the governed estate and developer command entry point — Teradata has its own engagement-scoped workspace; unrelated source systems are not shown.
What you are seeing
This public synthetic capture demonstrates Airlift setup and navigation for Teradata; it is not evidence of a live connection or certified migration.
What to do next
Register the client estate, bind a credential reference, run the Teradata assessment recipe, and admit the resulting evidence.
Read the developer workflow

These are automated captures from public synthetic engagements. The source workspace is specific to Teradata; no unrelated source is presented as its migration journey. For sources without an evidence-backed journey, the image demonstrates setup, navigation, and developer entry points only—not a live connection, converted output, or certified migration. No client data, credentials, workspace hostnames, or internal deployment identifiers are embedded in the images.

Teradata

On this page