Fabric and Data Engineering
Written By: Austin Levine
Last Updated on September 23, 2026
A cloud migration strategy is the plan for moving data, applications and workloads from on-premises infrastructure to a cloud platform without breaking what already works. For a BI or data platform migration specifically, that means deciding what moves as is, what gets rebuilt, and in what order, before you touch a single data source.
This guide covers the decision most organizations actually get stuck on: rehost, replatform or refactor. Then it walks through a concrete case, moving an on-premises data warehouse and its Power BI reports into Microsoft Fabric, and closes with a phase-by-phase checklist.
Rehost, replatform or refactor
Every cloud migration approach for an existing workload reduces to one of three choices. Pick per workload, not once for the whole estate.
Approach | What changes | When it fits |
|---|---|---|
Rehost | Move the workload to the cloud with little or no change to its structure. Sometimes called lift-and-shift. | The workload already works, the deadline is tight, or the app or database has no cloud-native equivalent worth building yet. |
Replatform | Move the workload and swap specific pieces for a cloud-native equivalent, without a full rebuild. | The data source itself is moving (for example, an on-premises SQL Server warehouse to Fabric Warehouse) but the reports and models on top of it do not need to change shape. |
Refactor | Rebuild the workload to take advantage of the cloud platform, such as splitting monolithic ETL into pipelines and Spark notebooks. | The current design is a known bottleneck, such as nightly batch jobs that no longer fit their window, or a model that cannot scale past its current data volume. |
A single migration project can mix all three. A dashboard that just needs its source moved is a replatform. A brittle set of overnight SSIS packages feeding it might be a refactor, done separately on its own timeline.
A worked example: on-premises warehouse to Fabric
Take a common starting point: a SQL Server data warehouse on a local server, with Power BI Desktop reports published to the Power BI service and refreshing through the on-premises data gateway.
Assess what actually needs to move. List every table the Power BI reports use, not every table in the warehouse. A migration is a good time to drop tables nothing queries.
Land the data in Fabric. Build a Data Factory pipeline that copies the source tables into a Fabric Lakehouse or Warehouse. The on-premises data gateway that Power BI already uses for scheduled refresh works for this pipeline too, so no new network path is required. For pipeline mechanics, see our Data Factory showdown: Fabric vs. Azure.
Point the semantic model at the new source. Repoint the existing Power BI model's data source to the Fabric Warehouse's SQL endpoint, or rebuild it against the Lakehouse if the table shapes changed. Keep the DAX layer; only the source changes.
Decide Import or DirectQuery for the new source. Fabric's SQL endpoint supports both. See our guide to Import versus DirectQuery for the trade-off; most migrated warehouse reports keep Import unless a specific report needs near-live data.
Run both systems in parallel before cutover. Refresh the new model on the same schedule as the old one and compare row counts and key totals until they match for a few consecutive refreshes.
Cut over and decommission. Repoint report consumers, then retire the on-premises source only after nobody has queried it in a full reporting cycle.
This is a replatform: the reports do not change shape, but the source moves from a self-managed SQL Server instance to a Fabric item with its own compute, and the pipeline now runs on Fabric capacity instead of a scheduled agent job. For background on what that capacity buys you, see why choose Microsoft Fabric.
Phases of a migration
Phase | What happens |
|---|---|
Assessment | Inventory the sources, reports and pipelines in scope. Confirm who owns each one and whether it is still used. |
Planning | Pick rehost, replatform or refactor per workload. Set a cutover order and a rollback point for each step. |
Migration | Move the data, rebuild what needs rebuilding, and validate against the source system before anyone relies on the new one. |
Parallel run | Keep both systems live and compare outputs until confidence is high enough to cut over. |
Cutover and decommission | Repoint consumers, then retire the old system on a schedule, not immediately. |
Common problems, and what causes them
No owner for the decision rule. Without an agreed rehost/replatform/refactor rule per workload, different people migrate similar things differently, and the estate ends up harder to maintain than before the migration.
Skipping the parallel run. Cutting over before the new system has been validated against the old one for at least one full reporting cycle is the most common cause of a migration that has to be partly redone.
Treating the gateway as disposable. The on-premises data gateway that fed the old reports is often still needed during migration, since the new pipeline needs to reach the same on-premises source before anything moves.
FAQs
What is a cloud migration strategy?
It is the documented plan for which workloads move to the cloud, how each one moves (rehost, replatform or refactor), and in what order, so the migration does not become ad hoc decisions made mid-project.
What is the difference between rehosting and replatforming?
Rehosting moves a workload with no structural change. Replatforming moves it and swaps specific pieces for a cloud-native equivalent, such as pointing a Power BI model at a Fabric Warehouse instead of an on-premises SQL Server instance, without rebuilding the model itself.
How long should a parallel run last before cutover?
Long enough to cover at least one full reporting cycle on the new system, comparing its output against the old one on every refresh, so a discrepancy shows up before anyone downstream relies on the new numbers.
Sources
Cloud Adoption Framework: migrate methodology - Microsoft Learn
OneLake overview - Microsoft Learn
Related to Fabric and Data Engineering