Forum Discussion
Helper Iissue while migrating adf pipelines to fabric
Hi dataengineerv2 ,
Thankyou for reaching out to Microsoft Fabric Community.
Yes you are correct, UI Migration Assistant is currently the most comprehensive option for migrating Azure Data Factory (ADF) pipelines to Fabric Data Factory, as it provides readiness assessments, dependency analysis, compatibility reporting, and guided migration capabilities.The best approach depends on your migration scenario:
UI Migration Assistant :
Recommended when migrating a large number of pipelines or when you want a guided experience with compatibility checks, dependency analysis, and migration reports. This is typically the best starting point for most ADF-to-Fabric migration projects.PowerShell Migration Module :
Useful when you need to automate migrations or integrate migration activities into existing scripts and processes. You mentioned that it is behind the UI Migration Assistant in terms of capabilities could you please clarify which specific features you found to be lacking?
This would help better understand the scenario and provide more targeted guidance.Fabric REST APIs :
Best suited for automation, deployment, workspace management, CI/CD processes, and post-migration operations. While REST APIs can automate parts of the migration workflow, they are not currently intended to replace the Migration Assistant as a complete ADF-to-Fabric migration solution.For Reference:
Upgrade your Azure Data Factory pipelines to Fabric
If you can share the specific unsupported scenarios, missing capabilities, or any errors encountered during migration.We are happy to assist.
Best Regards,
Abdul Rafi
Community SupportHi dataengineerv2 ,
Thankyou for reaching out to Microsoft Fabric Community.
Yes you are correct, UI Migration Assistant is currently the most comprehensive option for migrating Azure Data Factory (ADF) pipelines to Fabric Data Factory, as it provides readiness assessments, dependency analysis, compatibility reporting, and guided migration capabilities.
The best approach depends on your migration scenario:
UI Migration Assistant :
Recommended when migrating a large number of pipelines or when you want a guided experience with compatibility checks, dependency analysis, and migration reports. This is typically the best starting point for most ADF-to-Fabric migration projects.
PowerShell Migration Module :
Useful when you need to automate migrations or integrate migration activities into existing scripts and processes. You mentioned that it is behind the UI Migration Assistant in terms of capabilities could you please clarify which specific features you found to be lacking?
This would help better understand the scenario and provide more targeted guidance.
Fabric REST APIs :
Best suited for automation, deployment, workspace management, CI/CD processes, and post-migration operations. While REST APIs can automate parts of the migration workflow, they are not currently intended to replace the Migration Assistant as a complete ADF-to-Fabric migration solution.
For Reference:
Upgrade your Azure Data Factory pipelines to Fabric
If you can share the specific unsupported scenarios, missing capabilities, or any errors encountered during migration.We are happy to assist.
Best Regards,
Abdul Rafi
dataengineerv2We're migrating Azure Data Factory (ADF) pipelines to Microsoft Fabric Data Factory using the REST API. Many of our ADF linked services are parameterized. For example, an Azure SQL linked service uses a server name like:
@{concat('company-sqlsrv-', linkedService().environment, '-database.database.windows.net')}
where environment is provided at runtime (for example, dev, test, or prod) through a global parameter. We also have REST and ADLS linked services where the endpoint or storage path is supplied dynamically (for example, linkedService().baseUrl or a storage path constructed from runtime parameters such as {layer}/{source}).
Fabric connections appear to require a static endpoint, so these don't seem to map directly.
I have a few questions:
Is there a supported way to create a Fabric connection that remains parameterized like an ADF linked service, or is creating one connection per concrete endpoint the only supported approach?
For "generic" linked services that are reused with many runtime URLs or storage locations, what is the recommended design pattern in Microsoft Fabric?
When calling POST /v1/connections, what is the correct credentialDetails payload for creating an Azure SQL connection through an On-Premises Data Gateway? We're receiving a 400 InvalidInput response with the message:
"The Values field is required."
Additionally, WorkspaceIdentity appears to be rejected for gateway-bound connections.
If anyone has documentation, sample payloads, or recommended migration patterns for this scenario, I'd really appreciate the guidance.
- v-moharafi-msft
Hi dataengineerv2 ,
Thank you for reaching out to the Microsoft Fabric Community.
Based on the current Microsoft documentation, Fabric Connections work differently from Azure Data Factory (ADF) Linked Services. In ADF, you can dynamically build connection properties such as server names, URLs, and storage paths using parameters. In Fabric, connection properties are currently static and cannot be parameterized in the same way. Instead, Fabric uses reusable workspace-level connections, while pipelines can use parameters to determine which connection or settings should be used during execution.For migration scenarios where a single ADF linked service is reused across multiple environments (Dev, Test, Prod), the recommended approach is typically to create separate Fabric connections for each endpoint and use pipeline parameters or metadata-driven logic to select the appropriate connection at runtime.Regarding the POST /v1/connections API, the**"Values field required"** error usually indicates that the request payload doesn't match the credential format expected for an On-Premises Gateway connection. Fabric uses different request schemas for cloud connections and gateway-based connections.
The WorkspaceIdentity validation error is also expected in this scenario. Workspace Identity is supported for certain cloud-based connection types, whereas gateway-bound connections use a different authentication model
For Reference:- Migration planning for Azure Data Factory to Fabric Data Factory
- Migration best practices for Azure Data Factory to Fabric Data Factory
- Create Connection – Fabric REST API
If you're able to share a sample of the request payload with any sensitive details removed, the community may be able to provide more specific guidance on what part of the request is causing the validation error.
Please let us know if you have any further questions.
Best Regards,
Abdul Rafi