Teradata migration to Microsoft Fabric: what changes

If you are planning a Teradata to Synapse migration, Microsoft still supports the platform you would land on, but it no longer points you there. Azure Synapse Analytics remains supported, and Microsoft’s seven-part Teradata guide for it, written in 2022, is still published. Microsoft’s current tooling and guidance for a Teradata migration, though, target Fabric Data Warehouse. The Migration Assistant gained a Teradata source, in preview, in September 2026, alongside new planning, methods and translation pages written for Teradata.

So the target changes, and four things change with it. Metadata goes in as a zip of .sql and .bteq files, and Microsoft documents no direct connection to Teradata. Data goes in separately, through Copy job, a Fabric pipeline or COPY INTO, so FastLoad, MultiLoad and TPT jobs are rebuilt rather than repointed, and BTEQ scripts come back as stored procedures without their error-level handling. Some Teradata syntax the 2022 guide told you to rewrite no longer needs rewriting. And three behaviours change without raising an error: SET tables stop rejecting duplicate rows, timestamps lose their time zone offset, and keys stop being enforced. This article takes each in turn, from Microsoft’s own pages, and ends with what to decide before anything runs.

Where Microsoft now points a Teradata migration

Microsoft has not retired Synapse, and has not said it will. When Fabric became generally available in November 2023, Microsoft’s Fabric Updates Blog stated: “Microsoft has no current plans to retire Azure Synapse Analytics”, adding that customers “can continue to deploy, operate, and expand” it. The same post promised advance notice under the Modern Lifecycle Policy if that changed. It was just as clear about direction: “This is why most of our innovation efforts will be focused on Fabric”, and, because Fabric uses an open format, “your data warehouses cannot be upgraded in place either.”

The 2026 position is the same on retirement and narrower in scope. John Hoang, a Principal Program Manager at Microsoft, wrote in May 2026 that “Synapse remains supported for existing workloads” and that “Synapse continues to receive security fixes and stability updates”, while positioning Fabric as the path forward. The current Learn overview of dedicated SQL pools now opens with a tip: “If you’re new to data warehousing, start with Fabric Data Warehouse. Existing dedicated SQL pool workloads can upgrade to Fabric to access new capabilities across data science, real-time analytics, and reporting.”

None of these pages calls Synapse deprecated or gives it a retirement date. What has moved is the investment. The Teradata guidance Microsoft has published this year assumes Fabric as the destination, and its planning page says to “Confirm Warehouse as the target for SQL-centric relational analytics.”

So a Teradata to Synapse migration is still possible, and no Microsoft page rules it out. Note the wording, though: the 2026 support statement speaks of existing workloads, and a Teradata estate arriving on Synapse would be a new one. If Fabric is where you expect to end up, it is also a plan to migrate twice. Microsoft’s own statement is that a Synapse warehouse cannot be upgraded in place, so the later move is a second migration, with its own type changes and object gaps, which are covered in what does not move in a Synapse to Fabric migration.

Azure Databricks is the other destination in Microsoft’s ecosystem, and a different decision. Where the choice is open, our preference is Fabric: the warehouse, its pipelines and the reporting then sit in one service, on Fabric capacity and a single Fabric bill, rather than across two platforms billed separately. Microsoft’s Fabric overview describes its workloads as operating “within the same Fabric environment”. This article covers Fabric Data Warehouse only.

What the 2022 Synapse Teradata guide still gets right, and what it does not

Microsoft’s Teradata to Azure Synapse Analytics series describes itself as “part one of a seven-part series that provides guidance on how to migrate from Teradata to Azure Synapse Analytics.” Its pages are dated June to August 2022. They carry 2026 update stamps, but none of the seven mentions Fabric, so read them as Synapse guidance.

Much of the method survives. The new Fabric planning page assesses the work in seven workstreams covering the same ground as the old series’ seven parts: design and performance, ETL and loading, security and operations, visualisation and reporting, SQL compatibility, migration tooling, and what comes after migration. The 2022 advice on scripts mostly holds too. Where ETL runs through “Teradata-specific utilities like BTEQ and TPT”, the series’ answer was that “your approach should be to re-engineer using Data Factory.” On Fabric that is still the answer for the loading utilities. BTEQ is the exception: Migration Assistant now translates the scripts into stored procedures, so they are reviewed and wired into pipelines rather than re-engineered from scratch.

What does not survive is the detail. Four pieces of the 2022 advice are contradicted by Fabric’s current documentation:

The Synapse column comes from parts one, five and six of the series. The Fabric column comes from the QUALIFY reference, the Teradata translation reference, the ingestion guidance and the tables page. If your migration plan was written from the 2022 series, these four rows are the places to revise it first.

What the Migration Assistant does with Teradata, in preview

Microsoft announced Teradata support in its September 2026 feature summary: customers “can upload Teradata SQL and BTEQ files” and convert tables, views, stored procedures, functions and macros. The Migration Assistant for Fabric Data Warehouse lists the source as “Teradata metadata (preview)”, and the tile you select in Fabric is labelled Teradata (Preview). Five details shape how a Teradata to Fabric Data Warehouse migration uses it.

It reads files, not a live system. Teradata metadata goes in as “a .zip archive of .sql and/or .bteq files”, according to the upload guide. The direct connection is documented only for “an Azure Synapse Analytics dedicated SQL pool or SQL Server database” in the connection guide. So the first job is extraction, and it has to be DDL: Migration Assistant “ignores query-only files that don’t define an object.”

It moves metadata and code, not data. In Microsoft’s words, “Migration Assistant translates and deploys metadata and code. Data movement runs as a separate Copy job or ingestion step in the migration workflow.”

BTEQ scripts become stored procedures, minus their control statements. The translation reference says Migration Assistant “translates BTEQ scripts into stored procedures and preserves supported script elements”, and that “Teradata macros migrate as stored procedures.” It also removes a list of BTEQ statements from the translated code, among them .LOGON, .RUN FILE, the .EXPORT variants, .OS, and .ERROROUT, .ERRORLEVEL and standalone .MAXERROR. Those last three matter most. A BTEQ script that decided whether the next step should run, based on an error level, loses that decision in translation. Microsoft’s instruction is to “Capture ERRORCODE and ACTIVITYCOUNT; add orchestrator logic for ERRORLEVEL and maximum-error policies.” The stored procedure does the work, and the pipeline around it decides what happens when it fails.

Copilot’s fixes need a paid capacity, and a test. For objects that fail translation, Copilot can suggest corrections, but “Copilot in Microsoft Fabric isn’t supported on trial SKUs.” Microsoft adds its own caveat: “Copilot can make mistakes.” The methods page asks you to compare each correction with how Teradata behaves, and to test boundary, null, precision and error cases.

Waves are supported, with one destructive option. Migration Assistant can add objects to an existing warehouse wave by wave, but “For a table, Keep incoming drops and re-creates the existing table. If the table contains data, this action causes data loss, and you must load the data again.” Use it only on tables you have not loaded yet.

Then there is collation, where Microsoft’s pages disagree. The Teradata methods page lists “A destination Warehouse name and collation choice” as a prerequisite, and its steps tell you to “choose the collation”. The newer upload and connection guides both say the opposite: “the new warehouse has case insensitive collation, regardless of the default warehouse collation setting.” Do not assume you can choose. Check the collation of the warehouse you get, and test any key, join or filter that relied on case to tell two values apart. The methods page lists “collation-sensitive values” among the things to reconcile before cutover.

SET tables, MULTISET tables and keys Fabric will not enforce

If you read one section closely, make it this one, because it is where a clean migration produces wrong numbers.

Teradata’s own documentation is precise: “A MULTISET table allows duplicate rows in compliance with the ANSI/ISO SQL 2011 standard. A SET table does not allow duplicate rows.” It adds that where there are uniqueness constraints in the table definition, “the table cannot have duplicate rows even if it is declared as MULTISET.”

Fabric Data Warehouse has no such table type. Microsoft’s translation reference maps both to an ordinary table. For a MULTISET table nothing changes, because its duplicate-row handling already matches Fabric’s default. For a SET table, “SET duplicate-row enforcement isn’t preserved; add metadata or upstream enforcement if needed.”

The keys go the same way:

• Teradata indexes do not come across: “Primary, secondary, unique, and hash indexes aren’t emitted; Fabric manages distribution and clustering.”
• Primary keys and unique constraints become NONCLUSTERED … NOT ENFORCED. “The constraint is retained as metadata, and key columns are forced NOT NULL.”
• CHECK constraints “must be enforced upstream or in the loading process.”
• Default constraints have no home at all. Fabric’s constraints page says the warehouse does not “support default constraints at this time”, and the key constraints it does accept cannot be declared inline in CREATE TABLE.

Put together, every rule Teradata used to keep duplicates out, whether the table type, a unique index or a unique constraint, becomes either metadata or nothing. Nothing errors when a duplicate arrives. It loads, and every total that touches it is overstated. Because key columns are forced NOT NULL, also check that no source column carrying a key constraint holds nulls before you load.

The design consequence is that de-duplication becomes load logic. Microsoft’s pattern for replacing MultiLoad already has the right shape: load into a staging table, validate, then MERGE into the target. For every former SET table, and every table that relied on a unique index, the validation step is where duplicates have to be caught, because the target will not catch them. Decide per table whether to reject, collapse or keep them, and write the decision down. It is a change of behaviour, and the reports built on that table were written against the old one.

Types and objects that need a decision before anything runs

Most Teradata types translate cleanly. These do not, and each needs a decision before the first wave rather than a defect ticket after it. Entries come from Microsoft’s translation reference unless linked otherwise.

Two rows deserve more than a cell.

Time zones. The offset loss surfaces furthest from its cause. The column arrives holding a plausible timestamp, and what has gone is the information that said which local time it was. Fabric can still use datetimeoffset in queries, through CAST and AT TIME ZONE, but cannot store it, so carry the offset or zone name in its own column before migrating. The mechanism is the one described in our Synapse to Fabric migration article, because the target type is the same: DATETIME2 stores no offset, whatever the source.

Identity. Fabric IDENTITY columns must be bigint, “Defining a seed and increment isn’t supported”, and values are “guaranteed unique, but the values aren’t necessarily sequential or ordered, and gaps can occur.” To keep existing key values, Microsoft documents SET IDENTITY_INSERT followed by DBCC CHECKIDENT, with the instruction “Always reseed after migration.” That page is written for SQL Server, Azure SQL Database and Synapse sources, not Teradata, so treat it as the general method and prove it on one table first.

Less needs rewriting than the 2022 guide implies. The T-SQL surface area page confirms that “MERGE syntax is supported and is a generally available feature”, that QUALIFY is supported, and that “Session-scoped #temp tables are supported”. Global temporary tables “that begin with ## aren’t supported”, and Microsoft’s temp table guidance recommends distributed temp tables, because they “align with normal user tables.”

The same surface area page lists what is not supported, including materialized views, recursive queries, triggers, manually created multi-column statistics and SET TRANSACTION ISOLATION LEVEL, with a warning worth taking literally: “Even if they appear to succeed, they might cause problems for your warehouse.” ALTER TABLE supports only a subset of operations, such as adding nullable columns and dropping columns, and ALTER COLUMN is in preview, which is one more reason to settle types before loading rather than after. Microsoft’s planning page asks you to “Confirm current Fabric Data Warehouse limitations and T-SQL surface area before each migration wave”, and to give every blocking difference an owner.

Replacing BTEQ, FastLoad, MultiLoad and TPT

Microsoft’s methods page makes the point that matters most in one line. Teradata utilities carry orchestration as well as data movement, so recreate the whole of what each one does, “rather than translating only the load statement.” Its mapping:

Five practical points sit underneath that table.

History and increments are separate designs. For history, Microsoft’s advice is to “bulk unload Teradata tables to ADLS Gen2. Use Parquet files when supported, keep an extraction manifest, and load the files by using COPY INTO.” COPY gives “the highest data ingestion throughput”, according to the ingestion guidance. Where a flow needs multi-step orchestration, transformations, branching or custom recovery, Microsoft points to a Fabric pipeline instead, and the pipeline copy activity for Teradata offers partition options of “None (default), DynamicRange and Hash” for parallel reads.

Reject handling depends on the file format. In Fabric, COPY INTO reads CSV, JSONL and Parquet, but “ERRORFILE applies to CSV and JSONL”, and “you can’t use MAXERRORS when FILE_TYPE is PARQUET.” If a current load tolerates and logs a number of bad rows, the Parquet path cannot reproduce that with COPY options alone. Use CSV or JSONL with an error file, or build the tolerance into the pipeline.

Copy job reads Teradata in full or by watermark, not by CDC. Microsoft’s Copy job connector table lists Teradata as a source and destination, with full load and watermark-based incremental reads, and leaves it out of the CDC replication list, which is itself in preview. Copy job does “watermark-based incremental copy” on columns such as datetime, date and integer, and CDC-based copy only “when CDC is enabled on the source”. Microsoft reserves deletes for CDC: watermark copy is for when “you only need to track inserts and updates”. If the coexistence period needs deletes to flow through, design for them explicitly.

MERGE runs under snapshot isolation. “Fabric Data Warehouse enforces snapshot isolation on all transactions”, and a T-SQL change of isolation level “is ignored at query execution time”, per the transactions page. The same page notes that a MERGE can create a write-write conflict even when it only appends, and advises avoiding “concurrent UPDATE, DELETE, MERGE operations on the same table.” Where several MultiLoad replacements write to the same table, sequence them rather than running them at once.

Check the gateway for the path you choose. The Teradata database connector page says: “You must select an on-premises data gateway for this connector, whether the Teradata database is on your local network or online.” That sentence sits in the Dataflow Gen2 connection steps, and the page does not say whether it also applies to Copy job or pipelines. Confirm it for your route before the network design is fixed.

Exports leave the warehouse too. Microsoft maps BTEQ .EXPORT to a pipeline, a notebook or a supported export pattern, and since .OS commands are removed from translated code, anything a script did at the operating system has to move “outside the warehouse”, into the schedules, notebooks or pipeline activities the translation reference lists.

Proving it: waves, acceptance and the parallel run

Microsoft recommends selective modernisation for most Teradata workloads, delivered in waves: “Migrate in waves by business domain, data mart, or workload cluster. Avoid a single big-bang migration.”

Its definition of done goes well beyond object counts. “Don’t use object creation success as the only completion signal.” A wave counts as complete only when its data, security, operations, downstream consumption and behaviour all pass their acceptance criteria, and source and target should run in parallel “for the period required by the workload’s risk profile.” The methods page adds a test worth copying into any plan: “Compare source and target results for representative business cycles.” And the translation reference is plain about its own output: “Translation output requires technical and functional validation.”

Our position: the parallel run is the deliverable

In our view the parallel run is the deliverable of a Teradata migration, not a buffer at the end of it: run both platforms and reconcile results before rerouting anything, especially when the migration reports zero errors. Migration Assistant’s summary counts objects: how many migrated and which need fixing. On a Teradata source, the differences that matter are the three this article keeps returning to, and Microsoft’s translation reference maps each of them automatically: SET tables that no longer reject duplicates, offsets that were dropped, and keys that have become metadata. Any one of them can leave a warehouse that opens, answers queries and disagrees with Teradata.

So we do not recommend letting the parallel period become the buffer that gets compressed when the project runs late. Microsoft’s own wave checklist asks that “Data reconciliation and business validation meet the agreed thresholds” before cutover, and only a parallel run can show that they do.

Microsoft’s methods page gives the baseline for what to reconcile: “row counts, aggregates, nulls, decimals, timestamps, and collation-sensitive values.” On a Teradata source, add explicit checks for duplicate rows in former SET tables, for period and interval boundaries, and for any timestamp that carried an offset.

Capacity is a separate decision

A Fabric warehouse runs on Fabric capacity, shared with everything else assigned to that capacity, and sizing it is a separate exercise from the migration. How consumption, smoothing and throttling work, and how to plan and charge back for them, is covered in our Fabric capacity planning article. One migration-specific dependency is worth carrying over from above: Copilot’s translation fixes need a paid SKU, not a trial.

Where to start

Start with the inventory, not the Migration Assistant. Before the first upload, assemble:

1. A zip of DDL and BTEQ for the first wave, with every dependency, and no query-only files.
2. Every SET table, unique index and unique constraint, with a decision on how duplicates will be handled in the load.
3. Every TIMESTAMP WITH TIME ZONE, PERIOD, INTERVAL and BOOLEAN column, with a target design for each.
4. Join indexes, triggers, recursive views, macros, and any table wider than 1,024 columns.
5. Every utility script, FastLoad, MultiLoad, TPT and BTEQ, with its schedule, its restart behaviour and its error levels, because the upload takes only .sql and .bteq files and translation strips BTEQ’s error-level statements.

Then migrate one small wave, a single business domain or data mart, and run it in parallel until it reconciles.

Veratas designs and builds data warehouses on Microsoft Fabric, Azure Synapse and Delta Lake. Our fixed-scope data warehouse foundation, from $12,000, covers one subject area, modelled as a star schema and loaded: ETL or ELT pipelines from your sources, a semantic model for reporting, data quality and load validation, and documentation and handover, live in 5 to 7 weeks. Fabric capacity or Azure consumption is billed separately by Microsoft, and an enterprise, multi-subject warehouse is quoted separately. If a Teradata migration is on your roadmap and you want to work out where to start, talk to our team.

Frequently asked questions

Is a Teradata to Synapse migration still possible? Yes. Microsoft has given Synapse no retirement date, still publishes its 2022 Teradata to Azure Synapse Analytics guide, and says Synapse continues to receive security fixes and stability updates. But its 2026 support statement is worded for existing workloads, its dedicated SQL pool overview tells newcomers to start with Fabric Data Warehouse, and its 2026 Teradata tooling and guidance target Fabric, not Synapse.

Does the Migration Assistant for Fabric Data Warehouse support Teradata? Yes, in preview. You upload a zip archive of .sql and .bteq files; Microsoft documents no direct connection to a Teradata system. It translates and deploys metadata and code, including tables, views, stored procedures, functions and macros, and the data moves separately through Copy job, a Fabric pipeline or COPY INTO.

What happens to Teradata SET tables in Fabric? They become ordinary tables, and SET duplicate-row enforcement is not preserved. Primary keys and unique constraints survive only as NOT ENFORCED metadata, so keeping duplicates out has to move into the load, typically a staging table that is validated before a MERGE.

What replaces BTEQ, FastLoad, MultiLoad and TPT on Fabric? Microsoft maps FastLoad to COPY INTO or Copy job, MultiLoad to COPY INTO plus MERGE, Teradata Parallel Transporter to a Fabric pipeline with copy and script activities, BTEQ .IMPORT to COPY INTO, and BTEQ .EXPORT to a pipeline, a notebook or a supported export pattern. Migration Assistant turns BTEQ scripts into stored procedures, but error-level handling moves to the pipeline.

Does Fabric Data Warehouse support QUALIFY, MERGE and stored procedures? Yes. QUALIFY is supported, MERGE is generally available, and Teradata macros and BTEQ scripts migrate as stored procedures. Recursive queries, triggers and materialized views are not supported, so recursive views, triggers and join indexes need redesign.

Divya Pal Singh

Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.