Forum Discussion
migration multiple adf jsons template to fdf without microsoft ui migration utitlity
if I have multiple adf jsons , and want to use all that's as template to fabric data factory so what are the options to migrate that except microsoft migration utility in adf as there i need to set up this adf JSONs linked datasets , linked services and then need to migrate, does it have any other options , like convert adf jsons to fdf , how to deal with linked services and datasets from adf to fabric as it's completey changes the way ..
so i got below approache
No native migrator by microsoft 🙁
You can build your own parser though
ADF JSON
↓
Custom Parser
↓
Metadata Model
↓
Fabric REST APIs
↓
Fabric Pipelines
but for this
any good resources or implementation of this ? like can we migrate multiple adf jsons using this and linked services and datasets migration also automated or need to set up that by manual?
my company using adf heavily and i got topic adf to fdf migration . like if we have some adf JSONs and want to use similar in fabric then how we can do that ... i completed implementation with ms fabric migration utility but but what for if i only have adf jsons not have adf environment so I can't use that utility , claude gave me tuy regarding this but want to know in depth
if anyone worked on this please feel free to share
Hi dataengineerv2,
Based on our understanding, since you only have ADF artifacts stored in Git or exported JSONs and no active ADF environment, creating a temporary ADF instance, reconnecting it to the repository, and then using the migration assessment could be a viable approach to bring those artifacts into a supported migration workflow. Once the initial migration is completed and validated, we suggest treating Fabric as the new source of truth by enabling Git integration and using Deployment Pipelines and Fabric REST APIs for ongoing lifecycle management, rather than repeatedly rebuilding temporary ADF environments. For future additions, you can generally migrate new pipelines incrementally and validate them as separate migration waves, although any shared dependencies should still be reviewed.
Additionally, please refer to the links below:
Overview of Fabric Git integration - Microsoft Fabric | Microsoft Learn
Overview of Fabric deployment pipelines - Microsoft Fabric | Microsoft Learn
Microsoft Fabric REST API references - Microsoft Fabric REST APIs | Microsoft LearnWe hope the information provided helps to resolve the issue. Should you have any further queries, please feel free to contact the Microsoft Fabric community.
Thank you.
5 Replies
Hi dataengineerv2,
Good question and just to clarify one important point: Microsoft now provides official migration options for moving Azure Data Factory pipelines to Fabric Data Factory.
There are mainly a few scenarios to consider :
1. If you still have access to the original ADF environment
You should start with the Microsoft migration / assessment experience. It can assess pipeline readiness, classify items as Ready, Needs review, Coming soon, or Not compatible, and help you plan the migration more safely.2. If you want to bring ADF into Fabric without immediately rebuilding everything
You can use the Azure Data Factory item / Mount experience in Fabric. This allows you to view and work with your existing ADF from a Fabric workspace while keeping the original ADF environment unchanged.3. If you want to automate migration at scale
Microsoft has published the Microsoft.FabricPipelineUpgrade PowerShell module. This is probably the closest official option to what you are describing. It can help upgrade ADF and Synapse pipelines to Fabric pipeline definitions.However, I would still be careful with the idea of a fully automated ADF JSON → Fabric pipeline conversion.
ADF and Fabric Data Factory don’t map 1:1 in every area. Linked services, datasets, triggers, integration runtimes, credentials, gateways, parameters, and unsupported connectors may still require review or manual remediation.
So if you only have exported ADF JSON files but no access to the original ADF environment, I would probably use the PowerShell migration module as the first thing to investigate, then build an assessment layer around it to classify what can be migrated automatically and what needs redesign.
In practice, I would approach it like this :
ADF JSON / existing ADF
- migration assessment
- PowerShell upgrade module where supported
- manual review of connections, credentials, IR/gateway, triggers, unsupported activities
- validation in Fabric workspace
- deployment with Git integration / deployment pipelines
Useful Microsoft docs :
Migration planning for ADF to Fabric
https://learn.microsoft.com/en-us/fabric/data-factory/migrate-planning-azure-data-factoryUpgrade ADF pipelines to Fabric
https://learn.microsoft.com/en-us/azure/data-factory/how-to-upgrade-your-azure-data-factory-pipelines-to-fabric-data-factoryPowerShell migration module
https://learn.microsoft.com/en-us/fabric/data-factory/migrate-pipelines-powershell-upgrade-module-for-azure-data-factory-to-fabricPowerShell migration tutorial
https://learn.microsoft.com/en-us/fabric/data-factory/migrate-pipelines-powershell-upgrade-module-tutorialBring / Mount Azure Data Factory into Fabric
https://learn.microsoft.com/en-us/fabric/data-factory/tutorial-bring-azure-data-factory-to-fabricMigration best practices
https://learn.microsoft.com/en-us/fabric/data-factory/migration-best-practicesSo I would not start from a custom parser unless the official PowerShell upgrade path cannot cover your scenario. The custom parser approach can still be useful, but more as an assessment or gap-analysis tool than as the primary migration engine.
the powershell method still same like ui migration utility so deos is better to use temporary adf if you dindt have running adf to just migrate your entire repo setup via git using microsoft ui migration utility and then note the warnings and the setup we need to do manually then migrate to fabric , connect to git repo there as use that entire repo as template , but in this case if i want to add some more piplelines then it will work right without reprocessing existing stuff,
and then use rest api for select this tempaltes on whatever fabric tenant you want , does this combination sounds good or still better approach there ?Hi dataengineerv2,
Based on our understanding, since you only have ADF artifacts stored in Git or exported JSONs and no active ADF environment, creating a temporary ADF instance, reconnecting it to the repository, and then using the migration assessment could be a viable approach to bring those artifacts into a supported migration workflow. Once the initial migration is completed and validated, we suggest treating Fabric as the new source of truth by enabling Git integration and using Deployment Pipelines and Fabric REST APIs for ongoing lifecycle management, rather than repeatedly rebuilding temporary ADF environments. For future additions, you can generally migrate new pipelines incrementally and validate them as separate migration waves, although any shared dependencies should still be reviewed.
Additionally, please refer to the links below:
Overview of Fabric Git integration - Microsoft Fabric | Microsoft Learn
Overview of Fabric deployment pipelines - Microsoft Fabric | Microsoft Learn
Microsoft Fabric REST API references - Microsoft Fabric REST APIs | Microsoft LearnWe hope the information provided helps to resolve the issue. Should you have any further queries, please feel free to contact the Microsoft Fabric community.
Thank you.
Hi dataengineerv2,
We would like to follow up and see whether the details we shared have resolved your problem. If you need any more assistance, please feel free to connect with the Microsoft Fabric community.
Thank you.Hi dataengineerv2,
We are following up to see if what we shared solved your issue. If you need more support, please reach out to the Microsoft Fabric community.
Thank you.
