Azure SQL Database and Microsoft Fabric Warehouse both use T-SQL, so teams assume they can simply swap one for the other. They can’t. They’re built for different jobs, and moving the wrong workload is an expensive way to learn that.
The better question isn’t how to migrate. It’s whether to move at all, copy the data, or leave it where it is.
This guide explains what each platform is for, the four realistic options, how mirroring changes the picture, and what to settle before you move a single table.
Two Platforms, Two Distinct Roles
Azure SQL Database is a transactional engine. It’s built for applications that frequently read and write small amounts of data, with strict consistency and referential integrity. Fabric Warehouse is an analytical engine.
It’s built for large-scale reporting, star schemas and queries that scan a lot of data at once.
Microsoft’s decision guide puts it plainly: operational transactional workloads belong in a SQL database, while enterprise data warehousing and SQL-based BI belong in a warehouse.
Microsoft also rates the T-SQL surface area of a SQL database as broad and that of a warehouse as moderate. In plain terms, code that runs happily on Azure SQL Database may need changes or may not run at all in a warehouse.
The Four Available Options
Most teams think they have two choices: stay or migrate. In practice, there are four.
| Option | What it means | Best when |
| Stay put | Keep everything in Azure SQL Database | The workload is operational, and reporting is light |
| Mirror | Replicate the data into Fabric’s OneLake and keep the original running | You want analytics in Fabric without touching the application |
| Migrate to Warehouse | Rebuild schema and load data into Fabric Warehouse | The data is analytical, and the old database was really a reporting store |
| Move to SQL database in Fabric. | Run the operational database inside Fabric | You want the same engine as Azure SQL Database, closer to your analytics |
The last row catches people out. Microsoft’s guidance states that a SQL database in Fabric uses the same SQL Database Engine as Azure SQL Database and is the recommended Fabric home for operational workloads. It’s a different approach from migrating to Warehouse.
Mirroring Is Often the Appropriate Response
Many teams don’t need to migrate. They need their Azure SQL data available to Power BI, Spark and the rest of Fabric. That’s what mirroring achieves.
According to Microsoft’s announcement, mirroring replicates your Azure SQL Database into OneLake, and Microsoft’s documentation says it avoids complex ETL. The data is converted to an analytics-ready format and kept up to date in near real time.
Each mirrored database also gets an auto-generated SQL analytics endpoint, letting people query it with T-SQL and cross-join the mirrored data with warehouses and lakehouses in Fabric.
Mirroring reached general availability in November 2024. Microsoft’s mirroring documentation also notes that it works with single databases and elastic pools, and that you can mirror a database behind a firewall using a virtual network or on-premises data gateway.
When Migrating to a Data Warehouse Is Appropriate
Migration makes sense when the Azure SQL database has never been operational. If it has served as a reporting store, with data loaded in batches, queried by analysts, and rarely written to by an application, then a warehouse is the better fit.
Signs you’re in that territory:
- Analytical queries dominate. Most of the load is reporting and aggregation, not application transactions
- Data volumes are growing. Reports are slowing down as history builds up
- You want one analytics platform. Power BI, Spark and SQL users should work from the same governed data
- Writes are batch-based. Data arrives in scheduled loads rather than constant small updates
If your application writes to it all day, stop. That’s an operational database, and mirroring or leaving it alone is almost always safer.
Changes Associated with Relocation
This is where most of the effort goes. The two platforms feel similar because the syntax is familiar, but familiar syntax isn’t the same as compatibility.
Some T-SQL features and object types available in Azure SQL Database aren’t supported in Fabric Warehouse, so you need to review stored procedures, functions, and data types individually.
One tool to be careful about: Microsoft’s Migration Assistant for Fabric Data Warehouse is aimed at customers moving from Azure Synapse dedicated SQL pools, not from Azure SQL Database, and it was in preview at the time of writing.
For an Azure SQL source, the usual approach is to refactor the schema and code, then load the data with Fabric pipelines or a copy job. We covered how those pieces fit together in our guide to building modern pipelines in Microsoft Fabric, and if you’re deciding when to transform data, our piece on ETL versus ELT will help.
Security and Governance
Moving data is also an opportunity to tighten access, not just copy it. Decide who can query what, because a platform that brings everything together can also expose everything.
Make sure row- and column-level rules, roles and permissions are deliberately rebuilt rather than inherited by accident.
Give each pipeline its own identity, with only the access it needs. We explain the principle in our guide to securing AI agents with Microsoft Entra ID, and the wider approach in responsible AI in practice. If you’re mirroring, remember that the replicated copy needs the same protection as the source.
What Must Be Correct First
Most of the work sits in the basics, whichever route you choose.
- A workload inventory. A list of what uses the database, split into operational, reporting and mixed
- Clean data. Duplicates and old records travel across happily, so tidy them before you move, not after
- A code assessment. A review of every stored procedure, function and view against Fabric Warehouse’s supported features
- Clear ownership. One owner for each dataset and one for the migration itself
- A capacity plan. An honest estimate of how the new workload will share Fabric capacity
- A narrow start. One database or one reporting workload in a test workspace before anything touches production
If your data is scattered across systems, a single customer view helps keep one customer from living in half a dozen places, and our guide to solving data silos in local government describes a pattern that repeats everywhere.
Once the data is in Fabric, our piece on turning Dynamics 365 data into live Power BI dashboards shows what you can build on top, and you’ll find more guides on our blog.
Final Thoughts
Azure SQL Database vs Fabric Warehouse isn’t a contest with a single winner. One runs your applications, the other powers your analytics, and many organisations are best served by keeping the first and mirroring it into Fabric. Migrate only when the data is truly analytical, and test before you commit.
If you’d like help choosing the right route, our BI and Data Science services and D365 migration team can assess your workloads, plan the move and run the cutover. Our AI Enablement Programme then helps you get that data ready for AI.
As an ISO 27001-certified Microsoft partner, we treat data protection as part of the plan, not an afterthought. Book a free assessment, and we’ll look at your setup and tell you honestly where to begin, no hard sell.
Frequently Asked Questions
Should I migrate from Azure SQL Database to Fabric Warehouse?
Only if the data is analytical, such as a reporting store loaded in batches, if an application writes to it constantly, keep it in Azure SQL Database or mirror it into Fabric instead.
What is mirroring for Azure SQL Database?
Mirroring replicates your Azure SQL Database into OneLake in near real time and exposes it through a SQL analytics endpoint. Your original database keeps running, and the mirrored data can be used across Fabric.
Is Azure SQL Database the same as SQL database in Fabric?
They share the same SQL Database Engine, but they’re separate offerings. SQL database in Fabric runs inside Fabric and is Microsoft’s recommended home for operational workloads there.
Does the Migration Assistant work for Azure SQL Database?
Microsoft built the Migration Assistant for Fabric Data Warehouse for Azure Synapse dedicated SQL pools, and it was in preview at the time of writing. Check the current documentation before relying on it as another source.
Will my T-SQL code run in Fabric Warehouse?
Much of it will, but not all. Fabric Warehouse has a narrower T-SQL surface area than Azure SQL Database, so assess your stored procedures, functions and data types before you migrate.
