Migration from Synapse to Fabric

 Hi xgm2109​,

Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.

Thank you.

HI xgm2109​,

Checking in to see if your issue has been resolved. let us know if you still need any assistance.

Thank you.

Hi xgm2109​,

The phased approach suggested above is definitely how I would tackle this. With your footprint, I would avoid treating it as a single "Synapse to Fabric" migration and split it into pipeline, connectivity, storage, database, SSIS and networking workstreams.

A few points from your inventory are particularly important.

For the 184 pipelines, Microsoft now has a Synapse pipeline migration assessment and upgrade experience. I would run the assessment first rather than manually rebuilding pipelines. It classifies activities as Ready, Needs review, Coming soon or Not compatible, and supported pipelines can then be migrated with their linked services mapped to Fabric connections. The migration experience is currently Preview.

If the "~430 datasets" are Synapse pipeline datasets, there is also an architectural difference to be aware of. In Fabric Data Factory, datasets are no longer separate reusable objects in the same way as Synapse/ADF. Their properties are generally defined inline within activities, so I would specifically assess how much you currently depend on parameterized/reusable datasets.

The biggest blocker I see is SSIS. Microsoft's current ADF versus Fabric Data Factory comparison still lists Azure-SSIS Integration Runtime support in Fabric as "to be determined". There is no direct Fabric SSIS IR/SSISDB replacement today. I would therefore treat SSIS as a separate migration stream and either refactor those packages or retain ADF/Synapse for them temporarily.

For Oracle, Fabric's current Oracle connector uses the On-premises Data Gateway. Since you already have SHIR/gateway infrastructure, I would first determine whether a single properly sized gateway cluster can replace some of that footprint rather than assuming all gateway infrastructure disappears.

I also would not automatically move the Azure SQL Database in the first phase, especially since two applications depend on it. Fabric can consume Azure SQL where it is. SQL database in Fabric is now GA and may be worth evaluating separately, but changing an operational application database at the same time as the analytics platform increases the migration risk unnecessarily.

For your ADLS raw/staging area, OneLake shortcuts to ADLS Gen2 can also be useful during transition. That lets Fabric access existing lake data without immediately copying everything into OneLake. Just review the networking limitations if that storage account is private-endpoint-only.

I would therefore start with something like:

1. Run the Synapse pipeline assessment.
2. Inventory the unsupported/Needs review activities and parameterized datasets.
3. Create a Fabric DEV environment and establish connections/gateway/networking.
4. Migrate 10-20 representative pipelines first.
5. Measure those workloads using the Fabric Capacity Metrics guidance before choosing the production F SKU.
6. Move the remaining compatible pipelines in batches with DEV/Test/Prod validation.
7. Keep Azure SQL and SSIS stable initially, then modernize those separately.
8. Run critical workloads in parallel before cutting Synapse off.

One other point: I would not assume the current €1,600/month automatically translates into a lower Fabric cost. Fabric uses shared Capacity Units, so representative workload testing is the safest way to size the capacity and compare costs.

Given that you have no Spark today, I also would not introduce Spark simply because Fabric offers it. Fabric Data Factory + Warehouse/Lakehouse + your existing SQL skills may be enough for most of this estate.

AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.