Merge pull request #2231 from MicrosoftDocs/main638941755061905528sync_temp

For protected branch, push strategy should use PR and merge to target branch method to work around git push error

Author: learn-build-service-prod[bot]

docs/data-factory/.openpublishing.redirection.data-factory.json

@@ -65,11 +65,6 @@
         "redirect_url": "/fabric/data-factory/known-issue-staging-item",
         "redirect_document_id": true
       },
-      {
-        "source_path_from_root": "/docs/data-factory/migrate-pipelines-powershell-upgrade-module-for-azure-data-factory-to-fabric.md",
-        "redirect_url": "/fabric/data-factory/migrate-from-azure-data-factory",
-        "redirect_document_id": true
-      },
       {
         "source_path_from_root": "/docs/data-factory/connector-azure-blob-storage-dataflows.md",
         "redirect_url": "/fabric/data-factory/connector-azure-blob-storage",

docs/data-factory/dataflow-gen2-deployment-pipelines.md

@@ -5,46 +5,47 @@ ms.reviewer: whhender
 ms.author: miescobar
 author: ptyx507x
 ms.topic: conceptual
-ms.date: 9/19/2025
+ms.date: 09/22/2025
 ms.custom: dataflows
+ai-usage: ai-assisted
 ---
 
 # Dataflow Gen2 and deployment pipelines
 
 >[!NOTE]
->Fabric deployment pipelines support [Dataflow Gen2 with CI/CD support](dataflow-gen2-cicd-and-git-integration.md). This article aims to provide general concepts and guidance on how to best use Dataflow Gen2 with deployment pipelines.
+>Fabric deployment pipelines support [Dataflow Gen2 with CI/CD support](dataflow-gen2-cicd-and-git-integration.md). This article provides guidance on how to use Dataflow Gen2 with deployment pipelines.
 
-Microsoft Fabric offers a robust set of tools for implementing Continuous Integration/Continuous Deployment (CI/CD) and Application Lifecycle Management (ALM). These capabilities empower teams to build, test, and deploy data solutions with speed, consistency, and governance.
+Microsoft Fabric provides tools for Continuous Integration/Continuous Deployment (CI/CD) and Application Lifecycle Management (ALM). These tools help teams build, test, and deploy data solutions with consistency and governance.
 
-Dataflow Gen2 with CI/CD support enables seamless integration of dataflows into [Fabric deployment pipelines](/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines). It automates build, test, and deployment stages, ensuring consistent, version-controlled delivery of dataflows. It accelerates development cycles, improves reliability, and simplifies management by embedding Dataflow Gen2 directly into Fabric’s end-to-end pipeline orchestration.
+Dataflow Gen2 with CI/CD support integrates dataflows into [Fabric deployment pipelines](/fabric/cicd/deployment-pipelines/intro-to-deployment-pipelines). This integration automates build, test, and deployment stages. It provides consistent, version-controlled delivery of dataflows and improves reliability by embedding Dataflow Gen2 into Fabric's pipeline orchestration.
 
-This article provides guidance on the different solution architectures for your Dataflow and related Fabric items to build a deployment pipeline tailored to your needs.
+This article provides guidance on solution architectures for your Dataflow and related Fabric items. You can use this guidance to build a deployment pipeline that fits your needs.
 
 While there are many goals with deployment pipelines, this article focuses on two specific goals:
 
-* **Consistency**: Ensure the mashup script of your Dataflow remains unchanged across all deployment stages.
-* **Stage-specific configuration**: Use dynamic references for data sources and destinations that adapt to each stage (Dev, Test, Prod).
+- **Consistency**: Keep your Dataflow's mashup script unchanged across all deployment stages.
+- **Stage-specific configuration**: Use dynamic references for data sources and destinations that adapt to each stage (Dev, Test, Prod).
 
 ## Solution architectures
 
-A good solution architecture enables you to not only have something that works for your Dataflow Gen2, but also components that extend through your overall Fabric solution. 
+A good solution architecture works for your Dataflow Gen2 and extends through your overall Fabric solution.
 
 The following list covers the available solution architectures when using a Dataflow Gen2:
 
-* **Parameterized Dataflow Gen2**: Using the [public parameters mode](dataflow-parameters.md), you can parameterize Dataflow components—such as logic, sources, or destinations—and pass runtime values to dynamically adapt the Dataflow based on the pipeline stage.
-* **Variable libraries inside a Dataflow Gen2**: Using the [variable libraries integration with Dataflow Gen2](dataflow-gen2-variable-library-integration.md), you can reference variables throughout your Dataflow. These variables are evaluated at runtime based on values stored in the library, enabling dynamic behavior aligned with the pipeline stage.
+- **Parameterized Dataflow Gen2**: Using the [public parameters mode](dataflow-parameters.md), you can parameterize Dataflow components—such as logic, sources, or destinations—and pass runtime values to dynamically adapt the Dataflow based on the pipeline stage.
+- **Variable libraries inside a Dataflow Gen2**: Using the [variable libraries integration with Dataflow Gen2](dataflow-gen2-variable-library-integration.md), you can reference variables throughout your Dataflow. These variables are evaluated at runtime based on values stored in the library, enabling dynamic behavior aligned with the pipeline stage.
 
-The main differences between these two relies on how a parameterized Dataflow requires setting a process through either the REST API or the [Fabric pipeline Dataflow activity](dataflow-activity.md) to pass values for runtime whereas the variable libraries integration with Dataflow Gen2 relies on a variable library being available at the workspace level and the correct variables being referenced inside the Dataflow.
+The main difference between these two approaches is how they pass values at runtime. A parameterized Dataflow requires a process through either the REST API or the [Fabric pipeline Dataflow activity](dataflow-activity.md) to pass values. The variable libraries integration with Dataflow Gen2 requires a variable library at the workspace level and the correct variables referenced inside the Dataflow.
 
-While both options are valid, each has its own set of considerations and limitations. We recommend doing an assessment as to how you'd like your workflow to be and how such workflow would fit into your overall Fabric solution.
+Both options are valid, and each has its own considerations and limitations. We recommend evaluating how your workflow works and how it fits into your overall Fabric solution.
 
 ## General considerations
 
-The following are a collection of things to consider when using a Dataflow Gen2 inside a Fabric deployment pipeline:
+Here are things to consider when using a Dataflow Gen2 inside a Fabric deployment pipeline:
 
-* **Default References**: Dataflow Gen2 creates absolute references to Fabric items (for example, Lakehouses, Warehouses) by default. Review your Dataflow to identify which references should remain fixed and which should be adapted dynamically across environments.
-* **Connection Behavior**: Dataflow Gen2 doesn't support dynamic reconfiguration of data source connections. If your Dataflow connects to sources like SQL databases using parameters (for example, server name, database name), those connections are statically bound and can't be altered using workspace variables or parameterization. 
-* **Git Integration Scope**: As a general recommendation, only the first stage (typically Dev) needs Git integration enabled. Once the mashup script is authored and committed, subsequent stages can use deployment pipelines without Git.
-* **Use Fabric pipelines to orchestrate**: A [Dataflow activity in pipelines](dataflow-activity.md) can help you orchestrate the run of your Dataflow and pass parameters using an intuitive user interface. You can also use the [variable library integration with pipelines](variable-library-integration-with-data-pipelines.md) to retrieve the values from the variables and pass those values to the Dataflow parameters at runtime.    
-* **Deployment Rules Compatibility**: While deployment rules can modify certain item properties, they don't currently support altering Dataflow connections or mashup logic. Plan your architecture accordingly.
-* **Testing Across Stages**: Always validate Dataflow behavior in each stage after deployment. Differences in data sources, permissions, or variable values can lead to unexpected results.
+- **Default references**: Dataflow Gen2 creates absolute references to Fabric items (for example, Lakehouses, Warehouses) by default. Review your Dataflow to identify which references should remain fixed and which should be adapted dynamically across environments.
+- **Connection behavior**: Dataflow Gen2 doesn't support dynamic reconfiguration of data source connections. If your Dataflow connects to sources like SQL databases using parameters (for example, server name, database name), those connections are statically bound and can't be altered using workspace variables or parameterization.
+- **Git integration scope**: We recommend that only the first stage (typically Dev) needs Git integration enabled. Once the mashup script is authored and committed, subsequent stages can use deployment pipelines without Git.
+- **Use Fabric pipelines to orchestrate**: A [Dataflow activity in pipelines](dataflow-activity.md) can help you orchestrate the run of your Dataflow and pass parameters using an intuitive user interface. You can also use the [variable library integration with pipelines](variable-library-integration-with-data-pipelines.md) to retrieve the values from the variables and pass those values to the Dataflow parameters at runtime.
+- **Deployment rules compatibility**: Currently, deployment rules can modify certain item properties but don't support altering Dataflow connections or mashup logic. Plan your architecture accordingly.
+- **Testing across stages**: Always validate Dataflow behavior in each stage after deployment. Differences in data sources, permissions, or variable values can lead to unexpected results.

docs/data-factory/includes/migrate-pipelines-prepare-your-environment-for-upgrade.md

@@ -0,0 +1,58 @@
+---
+title: Prepare the Environment for Fabric Pipeline Upgrade
+description: Steps to prepare the environment for pipeline upgrade
+author: whhender
+ms.author: whhender
+ms.reviewer: ssrinivasara
+ms.topic: include
+ms.date: 09/16/2025
+---
+
+Before you start upgrading pipelines, [verify](#verify-your-installation) your environment has the required tools and modules:
+
+- [PowerShell 7.4.2 (x64) or later](#install-powershell-742-x64-or-later)
+- [FabricPipelineUpgrade module](#install-and-import-the-fabricpipelineupgrade-module)
+
+### Install PowerShell 7.4.2 (x64) or later
+
+You need **PowerShell 7.4.2** or later on your machine.
+
+[Download PowerShell](/powershell/scripting/install/installing-powershell-on-windows)
+
+### Install and import the FabricPipelineUpgrade module
+
+1. Open PowerShell 7 (x64).
+
+1. Select the Start menu, search for **PowerShell 7**, open the app's context menu, and select **Run as administrator**.
+
+    :::image type="content" source="../media/migrate-pipeline-powershell-upgrade/powershell-icon.png" alt-text="Screenshot of the PowerShell icon.":::
+
+1. In the elevated PowerShell window, install the module from the PowerShell Gallery:
+
+    ```PowerShell
+    Install-Module Microsoft.FabricPipelineUpgrade -Repository PSGallery -SkipPublisherCheck
+    ```
+
+1. Import the module into your session:
+
+    ```PowerShell
+    Import-Module Microsoft.FabricPipelineUpgrade
+    ```
+
+1. If you see a signing or execution policy error, run this command and then import the module again:
+
+    ```PowerShell
+    Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
+    ```
+
+### Verify your installation
+
+Run this command to confirm the module loaded correctly:
+
+```PowerShell
+Get-Command -Module Microsoft.FabricPipelineUpgrade
+```
+:::image type="content" source="../media/migrate-pipeline-powershell-upgrade/verify-installation-module.png" alt-text="Screenshot of the module command output.":::
+
+
+

docs/data-factory/includes/resolution-file-basics.md

@@ -0,0 +1,42 @@
+---
+title: Basics to Create a Resolution File
+description: Map your Azure Data Factory Linked Service to your Fabric Connection
+author: whhender
+ms.author: whhender
+ms.reviewer: ssrinivasara
+ms.topic: include
+ms.date: 09/17/2025
+---
+
+```json
+[
+  {
+    "type": "LinkedServiceToConnectionId",
+    "key": "<ADF LinkedService Name>",
+    "value": "<Fabric Connection ID>"
+  }
+]
+```
+
+- The `type` is the type of mapping to perform. It's usually `LinkedServiceToConnectionId`, but you might also use [other types in special cases.](../migrate-pipelines-how-to-add-connections-to-resolutions-file.md#resolution-types)
+- The `key` depends on the `type` you're using. For `LinkedServiceToConnectionId`, the `key` is the name of the [ADF linked service](/azure/data-factory/concepts-linked-services) that you want to map.
+- The `value` is the GUID of the Fabric connection you want to map to. You can [find the GUID in settings of the Fabric connection](../migrate-pipelines-how-to-add-connections-to-resolutions-file.md#get-the-guid-for-your-connection).
+
+So, for example, if you have two ADF linked services named `MyAzureBlobStorage` and `MySQLServer` that you want to map to Fabric connections, your file would look like this:
+
+```json
+[
+  {
+    "type": "LinkedServiceToConnectionId",
+    "key": "MyAzureBlobStorage",
+    "value": "aaaa0000-bb11-2222-33cc-444444dddddd"
+  },
+  {
+    "type": "LinkedServiceToConnectionId",
+    "key": "MySQLServer",
+    "value": "bbbb1111-cc22-3333-44dd-555555eeeeee"
+  }
+]
+```
+
+Create your **Resolutions.json** file using this structure and save it somewhere on your machine so that PowerShell can access it.