SQL Database in Microsoft Fabric is built on the same SQL engine as Azure SQL Database, which leads a lot of teams to treat the migration as a connection-string change. It isn't. The engine compatibility is real, but the platform around it — how data is stored, how security is modeled, how the database integrates with the rest of Fabric — is different enough that a "should just work" migration plan finds its gaps in production.
OneLake Storage Changes What "Your Data" Means
SQL Database in Fabric automatically replicates data into OneLake in Delta Parquet format, making it queryable from other Fabric engines — Spark, Power BI, the SQL analytics endpoint — without a separate ETL pipeline. That's a genuine advantage for analytics scenarios, but it also means data residency, replication lag, and storage cost behave differently than a traditional Azure SQL Database. Teams planning a migration purely as an OLTP lift-and-shift often don't realize they've also just signed up for an analytics replication architecture, with its own monitoring and cost considerations.
The Security Model Isn't a Drop-In Replacement
Fabric's permission model layers Fabric workspace roles and OneLake security on top of (and sometimes instead of) familiar SQL Server permission constructs. Row-level security and column-level security carry forward, but how identity and authorization flow through Fabric's broader workspace model is genuinely different from a standalone Azure SQL Database — and it's worth assessing explicitly rather than assuming existing permission scripts translate directly. This is the same authorization-framework territory that shaped Microsoft Purview policy integration, and it's where migration assessments most often turn up surprises.
Instance-Level Objects Don't Travel With the Database
SQL Server Agent jobs, linked servers, and instance-level configuration have no direct equivalent in SQL Database in Fabric's PaaS model — the same category of gap that affects Azure SQL Database migrations generally, but worth re-verifying explicitly rather than assuming "we already solved this for Azure SQL." Scheduled jobs typically need to move to Fabric's native scheduling and pipeline tools; cross-server queries via linked servers need to be redesigned around Fabric's cross-database query capabilities or OneLake shortcuts instead.
T-SQL Surface Area Is Close, Not Identical
SQL Database in Fabric tracks Azure SQL Database's T-SQL surface closely, but it's a newer platform and feature parity is still catching up in places — particularly around some CLR scenarios and certain system-level configuration options. The practical approach is the same one used for any cross-platform migration: run the actual workload's query set against a Fabric test database early, rather than relying on documented compatibility lists, since edge cases in real production T-SQL surface faster than a feature-comparison table catches them.
Cross-Database Queries Work Differently Than You'd Expect
If your current architecture relies on cross-database queries within the same instance — a common pattern for multi-database applications — verify how that pattern maps onto Fabric's database model before migration, not during it. Some patterns map cleanly; others need to be redesigned around Fabric's cross-database query support or restructured using OneLake shortcuts, and the difference isn't always obvious from documentation alone.
A Practical Migration Sequence
Inventory instance-level dependencies (Agent jobs, linked servers, CLR assemblies) before touching the database itself. Test the actual production T-SQL surface against a Fabric trial database early. Map your security model explicitly against Fabric's workspace-and-OneLake permission layers rather than assuming a clean translation. Only then plan the data migration itself — by that point, the surprises that would have derailed a "just migrate it" timeline are already on the table.
If you're evaluating a move to Fabric and want a compatibility assessment run against your actual schema and workload, get in touch.