The latest articles on DEV Community by Azure Pipeline Notes (@azurepipelinenotes). https://dev.to/azurepipelinenotes https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4107042%2F697d0a00-5e13-49b5-bee4-8b271ce62dde.png https://dev.to/azurepipelinenotes en Azure Pipeline Notes Thu, 03 Sep 2026 01:42:57 +0000 https://dev.to/azurepipelinenotes/migrate-azure-data-factory-to-fabric-in-2026-what-the-built-in-tool-actually-does-1i36 https://dev.to/azurepipelinenotes/migrate-azure-data-factory-to-fabric-in-2026-what-the-built-in-tool-actually-does-1i36 <h1> Migrate Azure Data Factory to Fabric in 2026 (what the built-in tool actually does) </h1> <p>Microsoft now lets you move Azure Data Factory pipelines into Fabric Data Factory from inside ADF itself. The button is labeled <strong>Migrate to Fabric (Preview)</strong>. It is not a one-click cutover, and Azure Data Factory is not being shut off.</p> <p>This is written for data engineers and platform teams at Microsoft-heavy shops in the US, UK, and the rest of Europe. If you run ADF in East US, West Europe, or North Europe, and someone just asked “should we move to Fabric this quarter,” this is the practical version of that conversation.</p> <p><strong>Last checked:</strong> September 2026, against Microsoft’s current upgrade docs. The feature is still Preview. Screens and supported activities will keep moving.</p> <h2> ADF is not dying. The investment is. </h2> <p>There is no deprecation date for Azure Data Factory. You can keep running ADF and Fabric side by side. Execution of a mounted factory still happens on your Azure resources, on the same subscription that already holds your IR and linked services.</p> <p>The direction of travel is still obvious. New pipeline features, Copilot, OneLake, lakehouse, and warehouse integration land in Fabric first. New pipelines you put in ADF are pipelines you will eventually move. That is the actual reason to care, not a countdown clock.</p> <p>If you are starting a greenfield pipeline today and you already have Fabric capacity (F-SKU) in East US or North Europe, build it in Fabric. If you have years of ADF, do not rebuild the estate this quarter.</p> <h2> What you need before you click anything </h2> <ul> <li>An existing ADF instance with pipelines</li> <li>A Microsoft Fabric tenant</li> <li>A Fabric workspace in the <strong>same Microsoft Entra ID tenant</strong> as the factory</li> <li>Contributor (or higher) on that workspace if you start from the Fabric side</li> </ul> <p>Skip this and the mount step fails in a boring way. Cross-tenant factories will not mount. Same tenant, different region is fine. Capacity still has to exist in a Fabric region you actually use.</p> <h2> Two doors, one landing zone </h2> <p>You can start in ADF or in Fabric. They meet at the same migrate step.</p> <p><strong>Start in ADF</strong> if you have not assessed the factory yet. This is the default I would use. You get a read-only readiness scan before anything is copied.</p> <p>In the ADF authoring canvas: <strong>Migrate to Fabric (Preview) → Get started (preview)</strong>.</p> <p><strong>Start in Fabric</strong> if you already know which factory you want to bring over and you are fine skipping the in-ADF assessment. Workspace toolbar → <strong>Migrate</strong> → <strong>Data Factory</strong>, then pick the instance.</p> <p>Starting in Fabric skips the assessment. If you care about readiness (you should), start in ADF.</p> <h3> The four assessment statuses </h3> <p>Every factory and every pipeline gets one of these:</p> <div class="table-wrapper-paragraph"><table> <thead> <tr> <th>Status</th> <th>Meaning</th> </tr> </thead> <tbody> <tr> <td>Ready</td> <td>Safe to migrate as-is</td> </tr> <tr> <td>Needs review</td> <td>Small changes first. Global parameters are the usual example.</td> </tr> <tr> <td>Coming soon</td> <td>Fabric support is planned. Leave it in ADF for now.</td> </tr> <tr> <td>Not compatible</td> <td>No equivalent. Redesign, or keep it in ADF.</td> </tr> </tbody> </table></div> <p>Drill into a pipeline and you see the activity that caused the status. Export the result to CSV and drop it in the team channel. The assessment does not change your factory. You can rerun it after you clean things up.</p> <p>Unsupported activities do <strong>not</strong> block the whole factory. Only the pipelines that contain them are stuck. Everything else can move in a separate batch.</p> <h2> Mounting is not migrating </h2> <p>After the assessment, you pick a Fabric workspace and <strong>mount</strong> the factory.</p> <p>Mounting is a snapshot. It lets you see the ADF structure inside Fabric. It does not copy pipelines, it does not alter ADF, and it does not start running anything in Fabric.</p> <p>Nothing moves until you explicitly choose <strong>Migrate to Fabric (Preview)</strong> on the mounted factory and pick pipelines.</p> <p>This is the step people skip in their heads. Then they panic in Slack because “we migrated” when they only mounted.</p> <h2> What happens when you actually migrate </h2> <p>You select pipelines. You do not have to take the whole factory. Do not start with the 2:00 a.m. Eastern finance load.</p> <p>Then you map ADF <strong>linked services</strong> to Fabric <strong>connections</strong>.</p> <p>For a short list of common Azure connectors, the tool tries to create the Fabric connection for you, including account key, SAS, service principal, and system-assigned managed identity (mapped to workspace identity). That list currently includes Blob Storage, ADLS Gen2, SQL Server, Azure SQL Database, Azure SQL Managed Instance, Cosmos DB (NoSQL and MongoDB), Azure Data Explorer, PostgreSQL, and MySQL.</p> <p>Everything else: pick an existing Fabric connection or create one, then confirm.</p> <p>If you map nothing, the pipelines still migrate. Activities that need those connections land <strong>deactivated</strong>. You wire them up later. That is useful for a dry run. It is a Sev-2 if you re-enable triggers without noticing.</p> <p>Migrated pipelines go into a folder named <code>{factory}_Migration</code>. Pipeline names are prefixed with the source factory name so they do not collide. If a pipeline with the same name already exists in the workspace, that one is <strong>skipped</strong>. Rerunning a migration means you delete the previous copies in Fabric first.</p> <h3> Triggers after migration </h3> <p>Schedule triggers come across <strong>disabled</strong>. That is on purpose.</p> <p>You re-enable them after you have tested. Other trigger types do not get a free ride:</p> <ul> <li>Custom event triggers: do not migrate</li> <li>Storage event triggers: coming soon</li> <li>Tumbling window triggers: Fabric’s interval-based scheduling is not the same thing. Watermarks, backfill, and trigger-to-trigger dependency need a redesign</li> <li>Chaining / dependency triggers: not supported yet</li> </ul> <p>Also check expressions. <code>pipeline().TriggerName</code> exists in ADF and does not currently exist in Fabric. If you branch on the trigger name, pass it in as a pipeline parameter instead.</p> <h2> What still will not go through the button </h2> <p>This is the list that decides whether this is a Friday afternoon or a quarter.</p> <p><strong>Integration runtimes</strong></p> <ul> <li>Self-hosted IR (SHIR) does not migrate. Replace it with a Fabric on-premises data gateway (OPDG). Same job, different install, different ops. If SHIR is how you reach SQL Server in a US office or a UK datacenter, budget a gateway project, not a wizard click.</li> <li>Managed virtual network IR does not migrate. Fabric’s virtual network gateway is a different model. Reconfigure, do not expect a mapping.</li> <li>SSIS IR is out. Keep those packages on ADF and call them from Fabric if you must.</li> </ul> <p><strong>Workloads that stay behind</strong></p> <ul> <li>Change data capture (CDC)</li> <li>Apache Airflow DAGs (Fabric has its own Airflow offering, it is a copy-paste of DAGs, not this wizard)</li> <li>U-SQL / Data Lake Analytics (deprecated anyway)</li> <li>Cross-cloud / Azure ML refresh workloads until workspace identity support lands</li> </ul> <p><strong>Connectors</strong></p> <ul> <li>Long-tail enterprise connectors (SAP ECC, SAP BW, MDX, SAP CDS): no Fabric equivalent, redesign</li> <li>Marketing and finance SaaS (HubSpot, Google Ads, QuickBooks, Shopify, Xero): not supported today</li> </ul> <p><strong>The metadata-driven factory</strong></p> <p>If your ADF is a framework (parameterized linked services, dynamic datasets, a control table that says “run this source today”), the wizard will disappoint you. A lot of US enterprise factories are this shape.</p> <ul> <li>Global parameters: recreate as Fabric <strong>variable libraries</strong>. Auto-migration is still coming.</li> <li>Dynamic / parameterized linked services: not supported. Each permutation becomes its own connection.</li> <li>Metadata-driven pipelines that switch connections at runtime: do not migrate cleanly.</li> </ul> <p><strong>Activities</strong></p> <ul> <li>Mapping data flows: this one changed. They <strong>are</strong> supported in Preview. The wizard converts them to Mapping Data Flow transforms inside Dataflow Gen2, and the pipeline comes along. Treat it as Preview, then test row counts. Do not assume every transform survived.</li> <li>Synapse Spark job definitions / notebooks: partial. Plan on Fabric notebooks or Spark jobs.</li> <li>Copy activity upsert into Lakehouse tables: not supported. Copy to staging, MERGE from a notebook.</li> <li>Web / webhook / HTTP with custom auth or headers: rebuild</li> <li>Certificate auth on Web activity: rebuild</li> <li>User-assigned managed identity: use workspace identity</li> <li>Customer-managed keys, dual tokens, federated identity: do not migrate</li> </ul> <p>Copy, ForEach, If, Lookup, Switch, Until, Set variable, and Execute pipeline (which becomes <strong>Invoke pipeline</strong>) are the boring ones that usually go through.</p> <h2> Fabric is not ADF with a new coat of paint </h2> <p>A few differences will bite you even on “Ready” pipelines.</p> <p><strong>No publish step.</strong> You save and run. That is nicer. It also means there is no “debug vs published” safety blanket. Use a non-production workspace.</p> <p><strong>No dataset objects.</strong> File path, format, and compression live on the activity. Your mental model of reusable datasets goes away. That is fewer objects. It is also more copy-paste unless you parameterize well.</p> <p><strong>Identity.</strong> ADF managed identity becomes Fabric workspace identity. Plan the RBAC on the storage accounts and Azure SQL servers before you migrate, not after the first Copy fails at 2 a.m. Eastern.</p> <p><strong>Schedules.</strong> ADF lets one trigger fan out to many pipelines, with a central trigger hub. Fabric currently wants schedules on the pipeline. No reuse hub. If you have 80 pipelines on one nightly trigger, budget time.</p> <p><strong>Key Vault.</strong> ADF’s Key Vault story is mature. Fabric’s is narrower (Key Vault reference, limited auth types). Check yours before you call the pipeline “Ready.”</p> <h2> How I would actually run this on a real factory </h2> <ol> <li>Run the ADF assessment this week. Export the CSV. Do not migrate yet.</li> <li>Sort pipelines into three buckets: Ready and low-risk, Ready but production-critical, everything else.</li> <li>Stand up a <strong>dev</strong> Fabric workspace in the same tenant, on the same capacity region you use for Power BI. Mount there.</li> <li>Migrate five boring Copy pipelines. Map connections. Leave triggers off.</li> <li>Recreate global parameters as variable libraries. Fix <code>TriggerName</code>. Confirm row counts against ADF.</li> <li>Only then take a second wave. Leave SHIR, SSIS, tumbling windows, and metadata frameworks in ADF. Parallel run is expected, not a failure.</li> <li>Do not migrate production until a non-prod run has completed end to end on a schedule you re-enabled on purpose.</li> </ol> <p>If the CSV comes back mostly Not compatible, stop. You did not fail. You just found out the factory is a framework, an SSIS host, or an on-prem gateway farm. Those do not belong in this wizard yet.</p> <p>If the CSV comes back mostly Ready, and you already use Fabric for Power BI or a lakehouse, start the first wave. The backlog only grows.</p> <h2> When to wait </h2> <p>Wait if the factory depends on SSIS IR, managed VNet, SHIR you are not ready to replace, heavy tumbling-window backfill, or a metadata-driven linked-service design.</p> <p>Migrate a first wave now if the pipelines are Copy plus control flow, the connectors are the Azure ones in the auto-map list, and you want new work to land in Fabric instead of ADF.</p> <p>Microsoft’s own walkthrough is here: <a href="https://learn.microsoft.com/en-us/azure/data-factory/how-to-upgrade-your-azure-data-factory-pipelines-to-fabric-data-factory" rel="noopener noreferrer">Upgrade your Azure Data Factory pipelines to Fabric Data Factory</a>. Use it for the clicks. Use the assessment CSV for the decision.</p> <p><em>I write practical notes on Azure data pipelines for teams already running Microsoft stacks. Next up: the ADF activities that still break in Fabric, and what to build instead.</em></p> azure dataengineering microsoftfabric cloud