Friday Fabric Facts #19
Fabric Is Not SQL Server in the Cloud (And That’s a Good Thing)
The Executive Insight
A lot of Fabric migrations stall on the same wrong expectation: “if it’s Microsoft, it should just work like SQL Server.”
Fabric’s SQL experiences are real, but they are not a drop-in replacement for every feature your team has been quietly depending on for a decade. SQL Agent jobs, linked servers, CLR assemblies, filestream, temporal tables, full-text search. These are the gaps that turn a confident migration plan into a six-month archaeology project.
The opportunity isn’t to force Fabric to behave like legacy SQL Server. It’s to use Fabric’s native patterns (pipelines, shortcuts, notebooks, OneLake) to modernize the architecture instead of reconstructing the old one inside it.
This week’s issue is about the moment most planning conversations actually pivot: “We can move the data, but what about the things our old database used to do for us?” That’s where the real architecture work starts.
The Compatibility Trap
Migrations rarely fail because the data is hard to move. They fail because surrounding behavior was embedded in the platform and nobody catalogued it as application logic.
The usual suspects, and where they typically land in Fabric:
- SQL Agent jobs become Fabric pipelines for orchestration and scheduling.
- Linked servers become shortcuts or pipeline-based federation.
- CLR assemblies get rewritten in T-SQL or Python notebooks.
- Filestream moves to OneLake, referenced from SQL.
- Temporal tables become explicit SCD logic you maintain.
- Full-text search doesn’t map cleanly; the answer is usually Azure AI Search or a T-SQL alternative depending on the use case.
The discipline that saves the project is asking, on every legacy artifact: which parts of this database are actually data, and which parts are application behavior wearing a database costume? Once you separate those two, the migration scope clarifies fast.
What This Means for SMBs
The biggest risk in a mid-market Fabric move is trying to preserve every old pattern. That ends one of two ways: months spent reconstructing SQL Server inside Fabric, or a legacy SQL Server that never gets decommissioned because the migration feels too risky. Neither is the win you sold to your board.
A cleaner approach is to classify every legacy dependency into three buckets:
- Replace directly. Fabric pipelines for SQL Agent. Shortcuts for linked servers. Native equivalents that already exist.
- Rewrite intentionally. CLR logic into notebooks or T-SQL. Stored procedures into pipeline activities or warehouse procedures, depending on the workload.
- Retire or redesign. Features like filestream or deep temporal dependencies often signal an older modeling choice that’s worth revisiting, not porting.
This is where migrations become strategic rather than technical. The question stops being “how do we preserve the old behavior?” and starts being “should we preserve it at all?” That single shift usually pays for the consulting it took to surface it.
The Better Migration Pattern
The strongest Fabric migrations don’t attempt a perfect translation. They follow a modernization sequence:
- Move the core data first into Lakehouse or Warehouse, depending on the workload profile.
- Expose related data with shortcuts to avoid duplicating tables you’ll regret maintaining.
- Rebuild orchestration in pipelines rather than recreating the SQL Agent job graph.
- Refactor logic in layers, with business logic moving into notebooks, SQL transformations, or the semantic model depending on where it actually belongs.
- Retire legacy dependencies intentionally. If full-text search or filestream really matters, design a modern equivalent. If it doesn’t, that’s the call to make.
The advantage for lean teams is that this breaks the migration into a sequence of decisions instead of one all-or-nothing go-live. Each step is independently defensible to the steering committee.
Hope for Lean Teams
Fabric doesn’t require a perfect one-to-one SQL Server clone to be useful. The mindset that unlocks this:
Not every old feature deserves to come with you. Not every process needs to live inside the database. Not every workaround has to remain custom code. Pipelines absorb a lot of scheduling logic, shortcuts absorb a lot of unnecessary data movement, and OneLake absorbs a lot of awkward file storage patterns.
The win isn’t “we migrated.” The win is “we used the migration to remove constraints we’d been working around for years.” That’s the modernization that actually compounds.
Where I Fit In
The easy question in a Fabric migration is whether the workload can move. The harder and more valuable question is what the right Fabric-native replacement is for the behavior that workload depended on. That mapping (legacy feature to native equivalent, and the call on what to retire) is where most migrations either accelerate or quietly stall.
If you’re planning a Fabric move and the list of SQL Server dependencies is making the project feel stuck, and you want to map the old behaviors to Fabric-native alternatives before committing to a path, let’s talk.
Isaac Truong | Founder, Allston Yale
Enterprise-grade analytics for $50M–$100M SMBs
Power BI | Fabric | Azure | Data Strategy
Book a 20-min Fabric diagnostic →
Subscribe to get Friday Fabric Facts in your inbox (plus early access to templates)
LinkedIn: Connect with me for daily Fabric tips
Friday Fabric Facts # 19: Originally Posted on LinkedIn, June 5, 2026