Migrating Data from Teradata¶

This page covers Teradata-specific setup for Data migration. For workflow and Worker field definitions, see Data migration configuration reference. For SnowConvert AI CLI commands, see Manual Migration: Data migration.

Prerequisites¶

Before you migrate data from Teradata, make sure the following are in place:

• Teradata connectivity on Workers: Install teradatasql (preferred, pure Python) or register a Teradata ODBC driver on each Worker host. Default gateway port is 1025 unless your site uses another.
• Teradata Tools and Utilities (for tpt): If you use the tpt extraction strategy, tbuild must be on PATH or set via TPT_TBUILD_EXECUTABLE.
• NOS / WRITE_NOS (for write_nos): Teradata NOS / WRITE_NOS must be enabled on the source system, and you need cloud storage credentials aligned with your Snowflake external stage.
• Snowflake external stage (for write_nos): Create an external stage whose URL matches the bucket or container Teradata writes to.

Connectivity and extraction strategies¶

Teradata supports three extraction strategies. Pick one per table (or inherit from defaultTableConfiguration.extraction).

regular — partitioned SQL extraction¶

The Worker runs partitioned SELECT streams through teradatasql (preferred) or pyodbc with a registered Teradata ODBC driver. Data is converted to Parquet and uploaded to the Snowflake internal migration stage.

Authentication: TD2 (default), LDAP, or KRB5 via optional authentication in Worker TOML.

Worker TOML example (standard authentication):

[connections.source.teradata]
host = "teradata.example.com"
port = 1025
database = "MY_DB"
username = "your_username"
password = "your_password"
# odbc_driver = "Teradata Database ODBC Driver 17.20"  # when not using teradatasql
# dbc_name = "TDPID_ALIAS"
# authentication = "LDAP"

Workflow YAML (default — omit extraction block):

tables:
  - source:
      databaseName: MY_DB
      schemaName: sales
      tableName: orders
    target:
      databaseName: TARGET_DB
      schemaName: sales
      tableName: orders
    columnNamesToPartitionBy:
      - order_id

Prompt (when cloud storage isn’t ready yet, or volume is genuinely small):

Set up Teradata data migration for my project with regular extraction, including the Worker connection

write_nos — server-side export to object storage¶

Teradata writes Parquet directly to S3, Azure Blob, or GCS. Fixed output settings: FORMAT PARQUET, COMPRESSION SNAPPY, MAXOBJECTSIZE 16MB, OVERWRITE FALSE.

Worker TOML example:

[connections.source.teradata]
host = "teradata.example.com"
port = 1025
database = "MY_DB"
username = "your_username"
password = "your_password"
write_nos_location_scheme = "/az/"                    # /s3/, /az/, or /gs/
write_nos_location_host = "myaccount.blob.core.windows.net"
write_nos_location_container = "td-nos-exports"
write_nos_function_mapping = "nos_util.WRITE_NOS_FM"  # recommended credential mode

Workflow YAML:

    extraction:
      strategy: write_nos
      externalStage: TARGET_DB.SALES.MY_CLOUD_STAGE

Credential modes (choose exactly one): write_nos_function_mapping (recommended), write_nos_authorization_name, or write_nos_access_id plus write_nos_access_key.

Prompt:

Set up Teradata data migration using write_nos extraction for all tables and help me create the matching Snowflake external stage

tpt — Teradata Parallel Transporter on the Worker¶

The Worker generates a TPT EXPORT job, runs tbuild, converts delimited output to Parquet, then uploads like regular. Optional tuning: tpt_delimiter (default ASCII file separator U+001C), tpt_max_sessions (default 4).

Worker TOML example:

[connections.source.teradata]
host = "teradata.example.com"
port = 1025
database = "MY_DB"
username = "your_username"
password = "your_password"
tpt_delimiter = "|"
tpt_max_sessions = 8

Workflow YAML:

    extraction:
      strategy: tpt

Prompt:

Use tpt extraction for the ORDERS table

Under regular extraction, the Worker auto-enables TPT when tbuild is available unless you set use_tpt_for_bulk = false in Worker TOML.

Data type mappings¶

These mappings are applied automatically during migration type conversion:

Platform-specific considerations¶

• Server-side export (write_nos): Prefer write_nos for all tables when Teradata NOS and a Snowflake external stage aligned with the target bucket or container are in place. Use regular or tpt when volume is genuinely small, or when WRITE_NOS prerequisites aren’t set up yet.
• Worker parallelism: Teradata systems are often CPU and BYNET sensitive. Keep Worker parallelism moderate and coordinate with your DBA.
• Anti-locking: AIM DMV adds LOCKING ROW FOR ACCESS automatically on every Teradata source scan. No configuration is required. See Anti-locking and query modifiers.

Related content¶

• Data migration
• Data migration configuration reference
• Validating Data from Teradata