Migrating Azure Synapse Analytics Pipelines to Fabric - What We've Learned

Microsoft has been pushing hard on Fabric as the successor to several overlapping data services, and Azure Synapse Analytics is squarely in the migration crosshairs. If you're running Synapse pipelines today, you've probably already seen the nudges - documentation pointing you toward Fabric, feature announcements skewed toward the new platform, the general sense that Synapse's days as the primary investment area are numbered.

We've helped several Australian organisations work through this migration over the past year. Some went smoothly. Others didn't. Here's what actually matters when you're moving Synapse Analytics pipelines to Fabric Data Factory.

Why the Migration Is Happening

Let's be direct about this. Microsoft isn't going to turn off Synapse tomorrow, but the writing is on the wall. New features are landing in Fabric first. The integration story between data ingestion, transformation, warehousing, and reporting is tighter in Fabric. And Microsoft's licensing model increasingly bundles Fabric capacity with other services, making it the path of least financial resistance for organisations already paying for Power BI Premium or Microsoft 365 E5.

The practical reason to migrate isn't that Synapse is broken. It's that staying on Synapse means you'll be maintaining pipelines on a platform that's receiving less attention while Fabric gets the investment. That's not a crisis today, but it's a strategic risk over the next two to three years.

The Microsoft documentation on upgrading Synapse pipelines to Fabric covers the mechanical steps. This post covers everything around those steps.

What Moves Cleanly

Not everything about this migration is painful. Some things actually translate well.

Pipeline Definitions

If your Synapse pipelines use standard Data Factory activities - Copy Data, Data Flow, Lookup, ForEach loops, Web activities - most of these have direct equivalents in Fabric Data Factory. The pipeline structure, the control flow logic, the sequencing - it all maps over fairly directly. Microsoft provides a migration tool that handles a lot of this automatically.

We've found the automatic conversion works well for about 70-80% of pipeline activities in a typical organisation. That last 20-30% is where the work lives.

Data Flow Logic

Synapse mapping data flows translate to Fabric dataflows, though there are differences in the runtime and some transformation functions. Simple to moderate data flows - filters, joins, aggregations, derived columns - come across without much trouble. Complex data flows with custom expressions, conditional splits involving numerous branches, or heavy use of surrogate key patterns sometimes need reworking.

Linked Services to Connections

Fabric uses a "connections" model instead of Synapse's "linked services" model. The concept is similar - you're defining how to connect to a data source. The migration tool can create Fabric connections from your existing Synapse linked services, but you'll need to re-authenticate them. Credentials don't transfer, which is a security feature, not a bug.

What Doesn't Move Cleanly

Spark Notebooks

If your Synapse pipelines call Spark notebooks - and many do - this is your biggest migration headache. Fabric has its own notebook experience with a different runtime environment, different library management, and different compute model. You can't just move a Synapse Spark notebook into Fabric and expect it to run.

The SparkSQL syntax is mostly compatible, but the PySpark library versions may differ, custom library installations work differently in Fabric, and the compute context (how the notebook connects to data) follows Fabric's lakehouse model rather than Synapse's workspace model.

Budget real time for this. We've seen notebook migration take longer than all the pipeline migration work combined.

SQL Pool References

If your pipelines interact with dedicated SQL pools in Synapse, you need a plan for those too. Fabric has its own SQL analytics endpoint and warehouse, but they're architecturally different from Synapse dedicated SQL pools. This isn't a lift-and-shift. It's a rearchitecture of your data warehouse layer.

For organisations with significant investment in Synapse dedicated SQL pools, this is often the reason to phase the migration rather than doing it all at once. Move the pipelines that don't depend on SQL pools first, then tackle the SQL pool migration as a separate project.

Triggers and Scheduling

Synapse triggers and Fabric scheduling work differently. Synapse supports tumbling window triggers, event-based triggers, and schedule triggers. Fabric's scheduling model is simpler in some ways but different enough that you can't just copy trigger configurations across.

Tumbling window triggers, which are common in data warehouse loading patterns, don't have a direct Fabric equivalent. You'll need to redesign the scheduling logic, typically using a combination of scheduled triggers and pipeline parameters to achieve the same incremental loading behaviour.

Planning the Migration

Inventory First

Before touching anything, catalogue everything. How many pipelines do you have? What activities do they use? Which ones call Spark notebooks? Which ones reference SQL pools? What triggers them?

We build a compatibility matrix for each client - every pipeline activity mapped to its Fabric equivalent, flagged as green (direct migration), yellow (needs minor changes), or red (needs rearchitecture). This inventory drives the migration plan and gives everyone realistic expectations.

Phase It

Do not try to migrate everything at once. We typically recommend three phases:

Phase 1 - Migrate standalone pipelines that use standard Data Factory activities and don't depend on SQL pools or Spark notebooks. These are your quick wins, and they build confidence in the Fabric environment.

Phase 2 - Migrate pipelines with Spark notebook dependencies. This requires setting up the Fabric lakehouse, migrating notebook code, testing thoroughly, and then switching over.

Phase 3 - Migrate pipelines tied to dedicated SQL pools, which usually means migrating the SQL pool itself to Fabric's warehouse or deciding to keep it running in Synapse alongside Fabric.

Run in Parallel

During migration, run both environments in parallel for a period. This costs more in compute, but it lets you validate that Fabric pipelines produce identical results to their Synapse equivalents before you cut over. Skip this step and you're gambling with your data processing accuracy.

We recommend at least two full data processing cycles in parallel - typically two weeks for daily pipelines, two months for monthly pipelines. Compare output row counts, key metrics, and checksums.

Fabric-Specific Considerations

Capacity Planning

Fabric uses a capacity-based pricing model. Your Synapse pipelines consumed resources from your Synapse workspace. Your Fabric pipelines will consume capacity units from your Fabric capacity. These are not the same thing, and costs may differ.

Run your migrated pipelines in Fabric and monitor capacity consumption before decommissioning Synapse. Some organisations have found that certain workloads cost more on Fabric capacity, while others cost less. The aggregate might be better, but individual pipelines can surprise you.

Workspace Organisation

Fabric workspaces work differently from Synapse workspaces. In Fabric, a workspace can contain pipelines, dataflows, notebooks, lakehouses, warehouses, reports, and more. There's a tendency to throw everything into one workspace. Resist this.

Organise your Fabric workspaces around functional boundaries - one for data ingestion, one for transformation, one for reporting. This keeps permissions clean and makes it easier to manage capacity consumption.

Git Integration

Fabric has git integration for version control of pipeline definitions. If you weren't using git with your Synapse pipelines (and honestly, many organisations weren't), the migration is a good opportunity to set this up properly. Version-controlled pipeline definitions make future changes safer and more auditable.

The Honest Assessment

The migration from Synapse to Fabric is not optional in the long term. Microsoft has made the direction clear. But it's also not urgent for most organisations. Synapse isn't being deprecated tomorrow, and rushing the migration creates unnecessary risk.

The best approach is methodical: understand what you have, plan the phases, start with the easy wins, and tackle the hard problems (Spark notebooks, SQL pools) with proper attention and testing.

If you're planning a Synapse to Fabric migration, our Microsoft Fabric consulting team and Data Factory specialists can help you assess your current Synapse environment and build a realistic migration plan. We've done enough of these now to know where the surprises hide, and helping you avoid them is a lot cheaper than discovering them mid-migration.