Hello @Koritala
Microsoft Fabric isn’t designed as a straightforward lift-and-shift migration tool, but it serves effectively as a managed layer for data movement and transformation. The usual approach involves leveraging Fabric Data Pipelines—similar to ADF—alongside a Self-Hosted Integration Runtime (SHIR) to securely extract data from on-premises SQL Server and load it into Azure SQL Database. This is particularly well-suited for scenarios where you require selective migration of tables, data transformation, or repeatable pipeline processes, rather than migrating an entire server.
Typically, you’d start by assessing compatibility with Azure SQL DB, then pre-create the necessary schemas and tables in Azure. Data is then transferred using Copy Data activities within Fabric pipelines, supporting both full and incremental loads (using a watermark like ModifiedDate or rowversion). While Fabric manages the data movement and orchestration, it doesn’t handle stored procedures, SQL Agent jobs, or server-level objects—these need to be scripted and migrated separately.
For larger migrations or those requiring minimal downtime, it’s common practice to use Azure Database Migration Service (DMS) for the initial migration, then employ Fabric for ongoing incremental synchronisation, validation, and future data engineering needs. In essence, Fabric complements dedicated migration tools rather than replacing them.
This is the official landing page that links all supported migration paths into Fabric, including SQL-related options. It clearly positions Fabric as an analytics platform rather than a classic lift‑and‑shift database tool.
I trust this will be helpful. If you found this guidance useful, you are welcome to acknowledge with a Kudos or by marking it as a Solution.
