Navigating through Forums and Migrating from Synapse to Azure Fabric

[XhevahirMehalla]

Hello -

I need help with two things:

1. Is very difficult to post a question on each forum . Please send tme the links for each forum. Most important is Fabric and Power BI.
2. I need to migrate to Azure Fabric from Azure synapse analytics to Azure fabric and to asses how much work this involves and how much resources I need.

This is the current architecture:

1. Data lake gen 2 stored data extracted daily from Oracle OCI database (store files as CSV) and have two layers (raw and staging layer). Raw holds CSV files on daily basis, Staging hold parquet files after being transformed using Synapse Pipelines.
2. Data source is Oracle OCI database= (200 tables) 
3. Using Copy Data/synapse to copy data from Oracle OCI to Data Lake Gen 2.
4. Use Synapse Transformation - Use Data Flow to transform data between RAW and STAGING layers in Data lake gen 2.
5. Once the data is transformed is loaded to a AZURE SQL db.
6. No Spark usage or sqlserverless pool. Is just pure copy and transform and load to Azure SQL db.
7. Use a VM to setup Integration Runtime in order to access Oracle database in OCI.
8. We have an Application which user uses to load some data/excel and this data lands on Data lake gen 2 and then goes through transformation and lands on SQL db.

Network Architecture:

1. Vnet and subnets
2. Data and apps are assigned to differents subnets.
3. We use Private Links to access each resource.
4. Use Site-to-Site VPN to connect to Oracle Site and On-prem env.
5.  Use NSGs
6. Use DNS zones and private DNS zones to access Application to load the files  from step 8 above.
7. we use Manage Private endpoints for each service on Synapse.

Env setup:

1. One Subscritpion for Dev and UAT
2. Seperate subscription for Prod.
3. We use Azure Devops to deploy all code and manage releases.

Now :

How can I migrate this to anothe Tenant/Client on Fabric?

How is easy would be to migrate them to Fabric?

It will take more time to migrate this to Fabric as we never worked before although I as the architect know what need to be done?

Or if we just stay on synapse and copy the code to another tenant/client?

We have full control of the env and will manage this - only the client pays for it.

Project starts in a week time and I need to start thinking what approach to take.

Few things:

1. Current team - knows the synapse solution
2. I, the architect knows high level the Fabric and been to FabCon Vienna and played around with fabric for the last year or so but that's it.

Please can someone guide me on:

1. how to migrate if I decides to? For each workload I need to know how to migrate them.
2. pros and cons of taking this aproach?

I need a really help on this.

Thanks very much!

[v-sgandrathi]

Hi @XhevahirMehalla,

Thanks for reaching out to the Microsoft Fabric Community Forum.

We understand you’re looking for guidance on both navigating Microsoft community forums and assessing your migration from Azure Synapse Analytics to Microsoft Fabric. Let’s address each of your queries in detail below.

You can post your questions in the following Microsoft community forums:

Power BI forums - Microsoft Fabric Community

Fabric platform forums - Microsoft Fabric Community

Microsoft Fabric brings together data engineering, data movement, data science, real-time analytics, and business intelligence within a single SaaS platform. Transitioning from Synapse means moving your pipelines, datasets, and workloads to Fabric’s unified environment, such as Lakehouse or Warehouse. Since your current setup mainly uses Copy Data, Data Flows, and Azure SQL Database and not Spark or SQL Serverless, the migration should be of moderate complexity.

Data Ingestion:
In Fabric, you use Data Pipelines or Dataflow Gen2 for ingestion, both offering built-in connectivity to Oracle and ADLS Gen2. The Fabric Gateway now replaces the Integration Runtime (IR) for connecting to on-premises or private sources, so you'll need to set up your Oracle connections and gateway in your new Fabric workspace.

Data Transformation:
You can rebuild your Synapse Data Flows with Dataflow Gen2 in Fabric, using similar visual mapping and transformation logic. Alternatively, you can use Notebooks (Spark) for more advanced or scalable data transformations.

Data Storage:
Fabric centralizes data in OneLake, a unified data lake. You can link your existing ADLS Gen2 containers as Shortcuts to avoid data duplication and set up your raw and staging zones in a Fabric Lakehouse with minimal changes.

Data Loading:
If you load data into Azure SQL DB, you can move this to Fabric Warehouse, which has a managed T-SQL endpoint, supports incremental loads, and integrates with Power BI, providing a familiar relational experience and unified Fabric features.

Application Integration:
Applications that upload Excel or CSV files can still do so directly into OneLake using REST APIs or Shortcuts. Automated downstream processes can continue with Fabric Pipelines or Dataflows, requiring little to no logic changes.

DevOps and CI/CD:
Fabric offers built-in Git integration with Azure DevOps and GitHub, allowing version control for pipelines, lakehouses, and reports. You can use Fabric Deployment Pipelines to promote workspaces, streamlining your Synapse release process with a SaaS-based approach.

VNETs and Private Endpoints: Fabric is a SaaS service, but private access is supported using Private Links (in preview) and Managed VNETs for secure connectivity.

DNS and Private Zones: These can continue as-is; you only need to ensure Fabric workspaces have access via Fabric Gateway.

Multi-Subscription Setup: You can replicate your Dev/UAT and Prod setup with separate Fabric workspaces and managed capacities.

Pros:

Unified data platform (ETL, analytics, BI in one environment)

Native Power BI integration and data governance through OneLake

Reduced infrastructure maintenance (no IR or manual scaling)

Built-in DevOps, semantic modeling, and monitoring features

Simplified licensing with pay-per-capacity model

Challenges:

Requires rebuilding Synapse Data Flows and Pipelines in Fabric equivalents

Limited support for some complex Synapse activities (e.g., stored procedures, parameterized pipelines)

Learning curve for Fabric concepts (Lakehouse, Warehouse, Dataflow Gen2)

Fabric is still evolving, so some advanced enterprise network controls may be in preview

Since your current architecture doesn’t involve Spark, Serverless SQL, or complex ETL logic, the migration is medium-effort.

Time Estimate: 3–5 weeks for end-to-end reimplementation and testing.

Resources Needed: 1–2 Data Engineers, 1 Architect, and 1 QA for validation.

Skill Readiness: Your Synapse team can easily adapt since Fabric uses similar data pipeline concepts and SQL-based transformations.

If you prefer to stay on Synapse:

You can copy the existing code to another tenant using ARM templates or Azure DevOps release pipelines. This approach minimizes rework but won’t leverage Fabric’s unified features or future roadmap. For clients requiring modernization and cost optimization, Fabric offers a more sustainable direction.

Given your background with Fabric and your position as the architect, the best way forward is to start with a pilot migration by moving one of your simpler Synapse pipelines completely into Microsoft Fabric. This lets you test for performance, cost, and governance within your client’s setup before a full migration. If the first phase meets your expectations, you can continue migrating in stages, keeping Synapse available as a backup during the process. Once you’ve confirmed stability and user adoption in Fabric, you can retire the Synapse workloads and use Fabric as your main data platform going forward.

Also Thank you @lbendlin and @GeraldGEmerick for your response.

Regards
CST Member.

[lbendlin]

It is not considered good etiquette to  post the same thread multiple times.

URL

https://community.fabric.microsoft.com/t5/Custom-Visuals-Development/bd-p/CustomVisualsDevelopmentDi...
https://community.fabric.microsoft.com/t5/DAX-Commands-and-Tips/bd-p/DAXCommands
https://community.fabric.microsoft.com/t5/Desktop/bd-p/power-bi-designer
https://community.fabric.microsoft.com/t5/Developer/bd-p/Developer
https://community.fabric.microsoft.com/t5/Power-Query/bd-p/power-bi-services
https://community.fabric.microsoft.com/t5/Service/bd-p/power-bi-web-app
https://community.fabric.microsoft.com/t5/Report-Server/bd-p/ReportServer
https://community.fabric.microsoft.com/t5/Mobile-Apps/bd-p/power-bi-mobile
https://community.fabric.microsoft.com/t5/Translated-Spanish-Desktop/bd-p/pbi_spanish_desktop
https://community.fabric.microsoft.com/t5/Reflex/bd-p/da_reflex
https://community.fabric.microsoft.com/t5/EventStream/bd-p/da_eventstream
https://community.fabric.microsoft.com/t5/Eventhouse-and-KQL/bd-p/da_eventhousekql
https://community.fabric.microsoft.com/t5/Dataflows/bd-p/df_dataflows
https://community.fabric.microsoft.com/t5/Data-Pipelines/bd-p/df_pipelines
https://community.fabric.microsoft.com/t5/Mirroring/bd-p/df_mirroring
https://community.fabric.microsoft.com/t5/Data-Engineering/bd-p/ac_dataengineering
https://community.fabric.microsoft.com/t5/Data-Science/bd-p/ac_datascience
https://community.fabric.microsoft.com/t5/Data-Warehouse/bd-p/ac_datawarehouse
https://community.fabric.microsoft.com/t5/Fabric-platform/bd-p/ac_generaldiscussion
https://community.fabric.microsoft.com/t5/SQL-Database/bd-p/db_general_discussion

[GeraldGEmerick]

@XhevahirMehalla I would recommend that you rebuild the solution in Fabric natively in parallel to your Synapse solution. This would allow you to confirm that everything matches up between your new and old solutions and wouldn't cost a tremendous amount extra relatively if this is done over the span of a month or two.