Contact The fleet documents your SSIS, ADF, Synapse and T-SQL estate into one knowledge base, then builds, tests and operates it on Microsoft Fabric: delivered as dbt or in your own framework, iterating until the tests pass.
Microsoft Fabric is a single SaaS analytics platform, and its storage layer, OneLake, keeps every table in the open Delta Lake format. For a legacy Microsoft estate (SSIS packages, Azure Data Factory pipelines, Azure Synapse across its four workloads, hand-written T-SQL), Fabric covers almost every destination you’d need, and Microsoft positions it as the path forward for exactly this kind of estate. The catch: “near-complete” isn’t “identical.” A faithful migration is a rebuild onto deliberately chosen Fabric workloads, not a file import, and the choices that matter get made before anyone writes code.
Two of those destinations carry most of the work. The Warehouse is the T-SQL relational engine, with full multi-table ACID transactions. It’s the home for dedicated SQL pool code, stored procedures, views, functions and BI-facing dimensional models, and the only target the dbt-fabric adapter writes to. The Lakehouse is the Spark-first store for structured and unstructured data, where notebooks read and write Delta directly and a read-only SQL analytics endpoint exposes its tables to T-SQL. They share OneLake and the same SQL engine, so the strongest designs use both: land and transform in a Lakehouse, serve curated data from a Warehouse. Around them, Data Factory in Fabric replaces ADF: Copy activity and Copy job for movement, Dataflow Gen2 for low-code Power Query transforms, the full control-flow set for orchestration, and Connections in place of linked services and datasets.
The fleet turns this from a guessing exercise into a documented, gated rebuild. The Documenter reads the actual logic (the distribution key behind a fast join, the %run that shares a notebook’s variables, the trigger or recursive CTE the Warehouse will reject) and records it in one knowledge base against its Fabric destination. That feeds the assessment gate, the first of three human checkpoints; design is the second, promotion the third. Between the gates the Builder, Test and Operate crews run autonomously: the Builder produces dbt models or native Fabric artifacts, the Test agent runs them, and the loop iterates until green: a rejected distribution clause stripped, an unsupported construct re-expressed, row counts and checksums reconciled to the source baseline. Autonomous in the loop, accountable at the gates. Weighing Fabric against the alternative? See the Fabric vs Databricks comparison.
Four source families, documented by their own specialists, then rebuilt on Microsoft Fabric.
SQL Server Integration Services.
Migrate SSIS to Fabric →
Azure Data Factory.
Migrate ADF to Fabric →
All four workloads, pipelines, notebooks, dedicated sql pools, serverless sql.
Migrate Synapse to Fabric →
T-SQL, stored procedures, views & functions.
Migrate T-SQL to Fabric →
Already deep into dbt? We build dbt, open-source and free to run. Built your own framework over the years? We build that.
table (the adapter default), view, table clone or incremental, built in dependency order from the ref() / source() DAG against the Warehouse.dbt_valid_from, dbt_valid_to, dbt_scd_id, dbt_updated_at) plus merge incremental models (the current default) keyed on a unique_key.unique, not_null, accepted_values, relationships) and seeds, with helper logic drawn from tsql-utils rather than dbt-utils.If Condition, Switch, For Each, Until, Invoke pipeline) with success and failure branches preserved.MERGE for upserts, invoked from pipelines through the Stored procedure activity.MERGE INTO for code-first upserts./Tables Delta data as T-SQL views, plus Connections and schedules replacing linked services, datasets and legacy triggers.Source patterns mapped to deliberate Microsoft Fabric targets.
view, table or incrementaltimestamp or check strategy), or an incremental model using merge on a unique_keyMERGE in a Warehouse stored procedure, or Spark MERGE INTO in a Lakehouse notebookCOPY INTO / CTAS; procedures recreated with CREATE PROCEDUREOPENROWSET / external tables / partitioned viewsOPENROWSET(BULK ...) staged then modeledOPENROWSET(BULK ...) in the Warehouse%run, mssparkutils, writes Delta)%run chains re-expressed for FabricThe Documenters and the knowledge base are shared; the builder follows your delivery flavor above: only the Build, Test and Operate crews differ per platform.
The Fabric dbt Builder generates a complete dbt project that targets the Microsoft Fabric Warehouse: sources, staging and mart models, snapshots for slowly changing dimensions, your macros, tests and generated docs. It writes to your layer conventions, so the project looks like one your team would have written.
The Fabric Framework Builder generates into the way your team already works on Fabric: data pipelines, Warehouse T-SQL procedures and Lakehouse notebooks, following your naming, error handling and orchestration patterns. Warehouses and Lakehouses are both in scope, so the build matches your architecture rather than forcing a new one.
The Fabric Test Agent generates the tests, not just runs them. It checks schema parity against the documented legacy behavior, reconciles row counts, verifies slowly changing dimension effective dating, and asserts null and key integrity, turning "looks right" into a suite that either passes or tells you exactly what failed.
The Fabric Operator closes the loop. It deploys the build to DEV, runs the pipelines for real, reads every runtime failure, and routes the fix back to the builders, then re-runs. That cycle repeats autonomously until the suite is green, and every iteration is logged in the knowledge base.
The Cutover Agent owns the endgame. It plans the parallel-run period, keeps watermarks in sync between old and new, sequences the switchover itself, and produces the legacy decommissioning checklist, so going live is a controlled step, not a leap.
It follows the logic, not a preference. The Warehouse is the T-SQL, multi-table-ACID relational engine: the right landing spot for dedicated SQL pool code, T-SQL stored procedures, views and functions, and dimensional models for BI. The Lakehouse is the Spark-first store for structured and unstructured data, the natural home for notebook transformation and medallion bronze/silver layers. They share OneLake storage and the same SQL engine and are designed to be used together, so a typical rebuild lands and transforms in a Lakehouse with PySpark, then serves curated data from a Warehouse. On the dbt flavor the target is always the Warehouse, because the dbt-fabric adapter writes there.
Not as a generally available runtime, so we do not claim one. There is an Invoke SSIS Package activity in preview that runs existing `.dtsx` packages from OneLake as a bridge, and Microsoft lists the Azure-SSIS Integration Runtime as undetermined for Fabric. The honest path is a rebuild: row transforms become set-based SQL or Dataflow Gen2, Lookup plus SCD Type 2 becomes a snapshot or a `MERGE`, precedence constraints become pipeline control flow, and Script Tasks move to notebooks or Functions because CLR and .NET do not run in the Warehouse engine. The fleet documents each package first so the rebuild lands on the right Fabric workload rather than assuming a one-to-one swap.
The Warehouse shares a large surface with the SQL Database Engine, but a few constructs are not in it and tend to bite a migration. Triggers, materialized views, synonyms and recursive queries are unsupported; primary, unique and foreign keys exist only as `NOT ENFORCED` metadata; `ALTER TABLE` is limited and `ALTER COLUMN` is preview; and CLR is unavailable. `MERGE` and `TRUNCATE TABLE` are generally available. The Documenter reads for exactly these patterns so the assessment gate flags what has to be re-expressed before any build starts, and the build-test-run loop catches anything the surface area rejects.
No, and that boundary shapes the design. Every Lakehouse automatically provisions a SQL analytics endpoint that gives a read-only T-SQL surface over its `/Tables` Delta data, on the same engine as the Warehouse. You can create views, table-valued functions and run queries there, but not `INSERT`, `UPDATE`, `DELETE` or `CREATE TABLE`. Writes happen through Spark notebooks, pipelines or dataflows into the Lakehouse, or through the Warehouse for T-SQL DML. The fleet keeps reads and writes on the right side of that line so the rebuilt logic behaves the same as the original.
Whichever you already run. If your team is SQL-first and invested in dbt, the Builder produces a dbt project against the Warehouse via the dbt-fabric adapter: models, snapshots, tests and docs, with `merge` as the default incremental strategy. If you have built your own orchestration over the years, the Builder produces native Fabric artifacts in that framework: Data pipelines, Warehouse procedures and Lakehouse notebooks. Both run through the same build-test-run loop and the same three human gates: assessment, design and promotion. The knowledge base and the Documenters are shared; only the Build, Test and Operate crews differ by flavor.
Tell us about your estate and we'll show you exactly what the fleet builds on Microsoft Fabric, in dbt or your framework.
Plan my migrationA short form, no spam. We usually reply within one business day.