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).

StrategyWorkflow extraction.externalStageSnowflake stageWorker requirements
regular (default)OmitInternal migration stageteradatasql or Teradata ODBC; optional odbc_driver, dbc_name, authentication
write_nosRequired (same bucket/container Teradata writes to)External stagewrite_nos_* TOML fields; Teradata NOS enabled
tptOmitInternal migration stage (same as regular)tbuild on PATH or TPT_TBUILD_EXECUTABLE

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

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.

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

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:

Teradata typeSnowflake target typeSupported for migrationNotes
BYTEINT, SMALLINT, INTEGER, BIGINTNUMBERYes
NUMERIC, NUMBER, DECIMALNUMBERYes
FLOAT, REAL, DOUBLE PRECISIONFLOATYes
DATEDATEYes
TIMETIMEYes
TIME WITH TIME ZONETIMEYesTZ offset dropped; local time preserved
TIMESTAMPTIMESTAMP_NTZYes
TIMESTAMP WITH TIME ZONETIMESTAMP_TZYes
CHAR, VARCHARVARCHARYes
CLOBTEXTYesLOB; max 2GB
BYTE, VARBYTE, BLOBBINARYYesLOB; max 2GB for BLOB
JSON, XMLVARIANTYes
ST_GEOMETRYGEOGRAPHYYes
BOOLEANBOOLEANYes
INTERVAL types (YEAR, DAY, HOUR, and so on)VARCHARYesStored as a text representation
PERIOD(DATE), PERIOD(TIME), PERIOD(TIMESTAMP), and TIME ZONE variantsVARCHARYesStored as a text representation
ARRAYARRAYYes
LONG VARCHAR, GRAPHIC, VARGRAPHIC, CHAR/VARCHAR UNICODEVARCHARYes

Platform-specific suggestions

  • Large tables: Prefer write_nos when Teradata can write directly to cloud storage aligned with your Snowflake external stage. Use tpt when you need bulk export through Teradata Parallel Transporter on the Worker.
  • 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.