Migrating an enterprise Teradata estate to Microsoft Fabric can require extensive manual work across database objects, SQL and BTEQ code, dependencies, and operational processes. Fabric Migration Assistant helps reduce that effort so teams can focus their review on the objects and workflows that need attention.
Fabric Migration Assistant for Data Warehouse now supports Teradata sources in preview. It converts eligible Teradata metadata and code to Fabric-compatible T-SQL, deploys eligible destination definitions, and flags scripts that need review or remediation, reducing the manual effort required to prepare a migration.
You can choose which objects to migrate, review the translated code, and focus remediation on exceptions instead of manually translating every eligible object. Migration Assistant does not move the associated data; you load data in the following step of the migration flow.
Define a migration scope you can validate
Reduce migration risk by starting with a representative set of interdependent objects from one workload or business process. Keeping the related tables, views, procedures, functions, and macros together lets you evaluate the translated result as a working unit. A focused scope makes it easier to distinguish among three outcomes:
- Translation: The source definition was converted to Fabric-compatible T-SQL.
- Deployment: The translated definition was created successfully in the destination warehouse.
- Validation: The migrated workload produces the expected behavior and results.
Translate Teradata metadata into Fabric-compatible T-SQL
Package your Teradata .sql and .bteq files into a ZIP archive, including the object definitions and dependencies needed for the selected scope.
From the Fabric workspace, open Migrate and select Teradata (Preview) under Migrate to a warehouse. The guided experience lets you upload the archive, choose the objects in scope, and confirm the destination before migration begins.
Migration Assistant translates and creates eligible definitions for:
- Tables
- Views
- Stored procedures
- SQL functions
- Macros, which translate into stored procedures
After the run, review migrated objects to see their status and translation details. This review helps you identify datatype and SQL changes that require validation before you treat successful object creation as a completed migration.
Use the file-based Migration Assistant guide for the upload, object-selection, and review workflow.
Focus remediation where it's needed
Teradata and Fabric Data Warehouse don't have a one-to-one mapping for every construct. Some definitions translate directly; others need a different implementation.
Teradata macros translate into stored procedures, while volatile tables map to local temporary tables. Review the maintained Teradata SQL translation reference for object mappings, data types, BTEQ behavior, and constructs that need redesign.
Migration Assistant groups scripts that could not be translated or deployed under Objects to fix. For each object, the source definition, translation comments, and error details help you determine whether the issue requires a syntax correction or a broader change to workload behavior.
If Copilot is available and enabled in your environment, Fix query errors can suggest a correction. Treat the suggestion as a starting point: compare it with the source definition and error details, revise it as needed, and run the script to validate the result before creating the object.
Before accepting a corrected object, confirm that it preserves the intended workload behavior by comparing parameters, joins, filters, and transaction boundaries with the source logic.
Bring BTEQ business logic into Fabric workflows
BTEQ scripts can combine SQL with control flow, session management, imports, exports, and operational logic. Migrating those scripts requires attention to the surrounding workflow, not just the SQL statements.
Migration Assistant translated eligible SQL and supported BTEQ elements into stored procedures. Review the generated procedures, then rebuild imports, exports, orchestration, and external operations with the appropriate Fabric capabilities.
Different parts of a BTEQ workload can use different Fabric capabilities:
- SQL and supported control flow: Review the translated stored procedure.
- Data imports and exports: Use the appropriate loading or export capability, including COPY INTO or pipeline copy activities.
- Scheduling, orchestration, and external operations: Recreate the required behavior through Fabric pipelines or other appropriate execution environments.
Translation doesn't automatically reproduce the entire operational environment. Validate parameters, error paths, sequencing, and external dependencies alongside the translated SQL. The objective is to preserve the business behavior you need while choosing suitable Fabric implementations.
Figure: Animated GIF —Migration Assistant for Teradata migration showcasing metadata translation flow.
Choose how to move the data
Metadata migration establishes the destination definitions in Microsoft Fabric Data Warehouse. Data movement loads the associated rows after the required table definitions are in place.
Choose the method that fits each workload:
- Copy job: Use the guided transfer from Migration Assistant's Copy data step. Connect to Teradata, select tables, review mappings, and choose the copy mode. A full copy can establish the initial dataset; incremental copies are an option when the source configuration supports them.
- Staged files and COPY INTO: For large historical transfers, unload Teradata data to Azure Data Lake Storage Gen2 and load the staged files into Fabric Data Warehouse with COPY INTO.
- Fabric pipelines: Use pipelines when the migration needs multi-step orchestration, transformations, branching, or custom recovery logic.
To learn more, refer to Migration methods for Teradata to Fabric Data Warehouse for data movement options and guidance on replacing Teradata loading utilities.
Validate the migrated workload
Run representative queries and compare the results with the Teradata workload. Validate row counts, aggregates, filters, joins, null handling, and the date and numeric behavior that affects the business process - not merely whether each object exists in the destination.
Include both expected paths and failure paths in the test scope. For procedures and translated BTEQ logic, verify parameter handling, transaction boundaries, retry behavior, and the sequence of dependent operations.
Next steps
Use Plan a migration from Teradata to Fabric Data Warehouse to define the scope and validation approach. Review Translate Teradata SQL for Fabric Data Warehouse for object mappings and use Migration methods for Teradata to Fabric Data Warehouse to choose the data-movement method.