Migration
Teradata to Microsoft Fabric migration: a practical guide
How to move a Teradata warehouse to Microsoft Fabric: Warehouse or Lakehouse, converting Teradata SQL to T-SQL, QUALIFY and case-sensitivity differences, BTEQ and FastLoad replacements, Power BI and cutover.
Hemant Walchale
· 2 min read
Organizations standardized on Microsoft (Azure, Microsoft 365 and Power BI) increasingly choose Fabric as the destination for their Teradata estate. The data model and reporting layer move well. The work is concentrated in converting Teradata SQL to T-SQL and in rebuilding BTEQ and load scripts.
This is the approach we recommend.
1. Inventory and retire
List tables, views, macros, stored procedures, BTEQ, FastLoad, MultiLoad and TPT scripts, scheduled jobs and consumers. Teradata’s query logs (DBQL) show what is used; archive the rest. Also list every Power BI dataset that reads Teradata, because those move last.
2. Choose the landing zone
- Fabric Warehouse for reporting tables, views and stored procedures in T-SQL.
- Fabric Lakehouse for heavy transformation in Spark and for file or semi-structured data.
- Both store Delta tables in OneLake, and Power BI can read them directly.
3. Convert Teradata SQL to T-SQL
| Teradata | Fabric Warehouse (T-SQL) | What to watch |
|---|---|---|
QUALIFY |
Window function in a subquery or CTE, filtered outside | Common; rewrite mechanically. |
SAMPLE, TOP n WITH TIES |
TOP, TABLESAMPLE or window functions |
Check result sizes. |
NOT CASESPECIFIC comparisons |
Case-sensitive by default | Choose collation deliberately or normalize case. |
SET tables |
No duplicate rejection | Add deduplication where the business relied on it. |
| Macros | Stored procedures or views | Rewrite. |
| Volatile tables | Temporary tables or staging tables | Check current Warehouse support for your pattern. |
| Teradata date arithmetic and formats | DATEADD, DATEDIFF, CONVERT |
Test every date calculation. |
| Primary and secondary indexes | Not used | Drop index logic. |
| BTEQ scripts | T-SQL scripts run by Data Factory pipelines | Rebuild error handling. |
| FastLoad, MultiLoad, TPT | Copy activity, COPY INTO from storage |
Stage files in OneLake or ADLS first. |
Check each converted procedure against the Warehouse’s documented T-SQL limitations and test the results.
4. Load, sync and reconcile
Export history to files in OneLake or ADLS and load it with COPY INTO or pipelines. Keep Fabric in sync during the parallel run, then compare row counts, totals and row-level differences by domain. Case sensitivity, SET tables and date logic explain most mismatches.
5. Repoint Power BI and switch off Teradata
Move Power BI semantic models to Fabric one domain at a time (often to Direct Lake mode), and stop each domain’s Teradata jobs on cutover day, working back from the renewal date.
The short version
Retire unused objects, land reporting tables in a Fabric Warehouse and heavy transformation in a Lakehouse, rewrite QUALIFY, macros and BTEQ for T-SQL, handle case sensitivity deliberately, reconcile, repoint Power BI and switch off Teradata by domain.
Compare with Teradata to Snowflake and Teradata to Databricks, or try the platform chooser. Browse all migration guides.
Not sure where your own platform stands? Take the free 3-minute data platform scorecard. Unfamiliar terms are explained in the data engineering glossary.