Last updated: October 8, 2026
By ZapAI Team
TL;DR: A successful Microsoft Fabric migration depends less on the mechanics of moving data and more on sequencing. Assess before you move anything, size capacity around actual usage rather than guesswork, be clear on OneLake shortcuts versus mirroring before picking one, and cut over in waves with a tested rollback plan. Skip any of these and the migration still “works.” It just costs more and takes longer than anyone budgeted for.
The core Microsoft Fabric best practices are: inventory every workload first, size capacity for sustained use rather than spikes, choose shortcuts, mirroring, or pipelines per workload, land data in a medallion architecture, govern from day one, and cut over in tested waves.
Migrating to Fabric Isn’t a Lift-and-Shift
Most teams start a Fabric migration the same way they’d migrate a database: inventory the source, map it to the target, move it over, done. That approach gets you a working Fabric tenant. It doesn’t get you a good one.
Fabric folds data engineering, Data Factory, warehousing, real-time intelligence, data science, and Power BI into a single SaaS platform built on OneLake. If you want a partner who has run this kind of platform assessment before, our Microsoft Fabric Services team works through exactly this sequencing with clients before a single workload moves.
Treating Fabric as a like-for-like swap for Synapse, Power BI Premium, or a standalone data lake is one of the earliest and most common mistakes enterprises make. Moving to Fabric is an operating-model shift, not a plug-and-play replacement. Workspace taxonomy, governance ownership, and capacity strategy all need to be rethought, not just re-pointed. (New to the platform? Start with what Microsoft Fabric is.)
Most migrations start from one of four places: Azure Synapse, Azure Data Factory, Power BI Premium capacity, or a non-Microsoft platform like Snowflake or Databricks. Each has its own path, but the planning discipline underneath is the same.
Assess Before You Move Anything
Skipping the inventory step is how “simple” migrations turn into six-month slogs. Before touching a workload, catalog every pipeline, dataset, semantic model, and dependency chain that touches it.
Microsoft’s open-source Fabric Assessment Tool, part of the fabric-toolbox repo, does much of this for Synapse. Per Microsoft’s migration planning guidance, it scans a workspace and summarizes Spark pools, notebooks, Spark job definitions, lake databases, linked services, and their configurations before you plan anything.
Once you know the scope, prioritize it. A value-versus-complexity ranking, business impact against migration difficulty, keeps teams from migrating whatever is easiest instead of what matters most. Low-risk, well-understood workloads go first. That builds process muscle before anyone touches a finance dashboard or compliance report.
Getting Capacity Sizing Right
Capacity is where Fabric migrations quietly blow their budget. Every operation in Fabric, whether a query, a refresh, or a Spark job, consumes Capacity Units (CUs), and the F SKU you buy determines how many CUs you have to spend. Under-provision and users get throttled. Over-provision and you’re paying for headroom nobody uses.
The key is understanding smoothing. Per Microsoft’s throttling documentation, interactive operations are smoothed over at least five minutes (up to 64), and background operations like refreshes and Spark jobs are smoothed over 24 hours. Short spikes get absorbed. So size for sustained, smoothed utilization, not for your single worst minute. If utilization sits near 100% for long stretches, though, you genuinely need a bigger SKU.
One cost driver teams consistently underestimate is Copilot. Copilot in Fabric draws from the same capacity, billed per token according to Microsoft’s Copilot consumption guide, so a tenant-wide rollout can move your CU usage noticeably. Pilot it with a limited group, measure the actual cost, then decide whether to scale it.
For a starting point, small F2 or F4 capacities work for pilots, and F64 is the like-for-like replacement for a Power BI P1. Treat that as a starting point, not a purchase decision. Confirm it against Microsoft’s Capacity Metrics app over two to four weeks before committing to reserved capacity. Our Fabric vs Power BI Premium breakdown covers the F SKU pricing math.
Shortcuts, Mirroring, or Pipeline Copy?
Fabric gives you three distinct ways to bring data into OneLake, and picking the wrong one for a given workload creates either unnecessary duplication or unnecessary latency.
OneLake shortcuts reference data in place, in ADLS Gen2, Amazon S3, Google Cloud Storage, or another OneLake location, without copying it. Microsoft’s shortcut documentation describes them as behaving like symbolic links: deleting a shortcut leaves the target untouched. (Deleting files through a shortcut is different. With write access, that does delete them at the source.) This is the right call when you want to avoid a big-bang migration and query data where it already lives.
Mirroring replicates data into OneLake in near real time as Delta tables. Metadata mirroring, by contrast, synchronizes only catalog names, schemas, and tables, and uses shortcuts to reference the source data rather than duplicating it, as Microsoft’s mirroring overview explains. Use mirroring when downstream consumers need a fast, queryable copy without you building and maintaining ETL pipelines.
Pipeline copy is the traditional scheduled-batch approach. It’s still valid, but it’s the option you reach for last, not first, since it reintroduces the duplication and latency the other two were built to avoid.
Most migrations end up using all three at different stages: shortcuts to unblock analytics fast, mirroring for systems that need continuous sync, and pipeline copy for the handful of workloads that genuinely need a scheduled batch pattern.
Land on Medallion Architecture
Whatever your source system, the target data model in Fabric should follow the medallion pattern: Bronze for raw, unprocessed data; Silver for validated and conformed data; Gold for curated, analytics-ready tables. Microsoft calls it the recommended design approach for Fabric. It preserves the original data as a source of truth while pipelines progressively improve quality at each layer.
Migrating into this structure, rather than replicating whatever ad hoc schema existed in the old platform, is the difference between a migration that improves your data estate and one that just relocates the mess.
Migration Patterns by Source System
Power BI Premium to Fabric
This is the lightest lift, but it comes with a deadline. Microsoft stopped selling Power BI Premium per-capacity (P SKUs) to new customers on July 1, 2024. Non-EA customers could renew only until February 1, 2025, and Enterprise Agreement customers can renew until their EA term ends. Once a P SKU subscription ends, Microsoft’s migration decision guide describes a 30-day grace period, throttled access through day 90, and rejected operations after that.
The mechanics are simple. Reassigning workspaces to a new Fabric capacity is most of the work. What routinely gets overlooked is licensing timing, regional constraints on large semantic models, and legacy P SKU cleanup.
Synapse to Fabric
For Spark workloads, Microsoft publishes a four-phase best-practices series, and it’s worth following rather than improvising. Run the Fabric Assessment Tool first. Then the Spark Migration Assistant (in preview) moves Spark pools, notebooks, Spark job definitions, and lake databases. It doesn’t migrate custom libraries, Spark configurations, or custom executor settings, and it can’t migrate workspaces under a virtual network, so those still need manual handling. Our Fabric vs Azure Synapse comparison covers what to migrate first and what can wait.
Azure Data Factory to Fabric Data Factory
This isn’t a straight copy. Microsoft’s ADF upgrade planning guide offers three routes: mount the existing factory in Fabric, use the built-in upgrade experience (which rates each pipeline as ready, needs review, or not yet compatible), or rebuild manually. Before moving a pipeline, review authentication patterns, network requirements, and trigger semantics. Run old and new pipelines side by side to catch discrepancies before they hit production.
For the full step-by-step sequence, including timelines and parallel validation, see our Microsoft Fabric migration guide.
Governance Isn’t Optional, and It’s Not Just Purview
Fabric’s security model is deeper than most teams initially plan for. Access narrows through several layers: workspace roles, item permissions, OneLake security roles, row-level security, column-level security, dynamic data masking, and sensitivity labels.
The layers interact in ways that surprise people. Workspace Admins, Members, and Contributors can read all lakehouse data, but Viewers can’t read data in OneLake at all unless a OneLake security role grants it. Mapping those roles to real people before migration avoids both over-sharing and a flood of access tickets on cutover day.
Sensitivity labels deserve particular attention. Per Microsoft’s sensitivity label documentation, labels and their protection carry over when users export to Excel, PowerPoint, or PDF. But a CSV export, or any other unsupported path, leaves the data unlabeled and unprotected. Plan for those gaps rather than assuming the label follows the data everywhere.
The bigger governance risk shows up before migration even starts: unrestricted workspace creation. When anyone can spin up a workspace, sprawl follows fast. Fabric admins can limit workspace creation to specific security groups through the Create workspaces tenant setting, and the fix is setting up a governed landing zone before ingesting a single dataset, not retrofitting governance after the fact. Many of the same principles behind Power Platform governance carry over directly. Role clarity and least-privilege access matter just as much on both platforms.
CI/CD and Environment Strategy
Fabric separates two concerns that teams often conflate. Git integration handles source control, while deployment pipelines handle release. Using both together builds a reliable path from development through test to production. Skipping Git integration means losing version history and rollback. Skipping deployment pipelines means manually promoting content between environments and hoping nothing breaks.
For teams working in shared workspaces, the collision risk is real, since a direct change in a shared workspace affects everyone in it. Microsoft’s branching guidance recommends that each developer work in their own workspace connected to their own branch, with changes promoted through Dev, Test, and Production via deployment pipelines rather than edited live.
Cut Over in Waves, Not All at Once
Big-bang cutovers are how migrations fail visibly and publicly. The alternative is wave-based: group workloads by business unit or complexity into manageable waves, start with lower-risk workloads to build process confidence, and run old and new systems in parallel during early waves as a safety net for comparison.
Each wave needs a documented rollback trigger, not just a rollback plan but a defined threshold for when you pull it. Test rollback in a non-production environment before the actual cutover window, and tell data product owners and downstream consumers about each wave well in advance. A week’s notice is a sensible minimum.
Budget for What Migrations Actually Cost
Fabric migration budgets fail in a consistent, predictable pattern. The capacity line item gets modeled carefully. Parallel-run costs, training, and Copilot consumption get treated as afterthoughts, and those are exactly the lines that overrun.
Parallel running is the big one. For every week both platforms run side by side, you pay for both, and early waves often need longer overlap than planned because validation surfaces issues. Add training for each role, plus the CU impact of any Copilot rollout, and a year-one budget can drift well past its original number.
The upside case exists too. Consolidating duplicate infrastructure and eliminating sync jobs between separate systems produces real savings once legacy platforms are switched off. The difference between the two outcomes usually comes down to whether capacity sizing and parallel-run costs were modeled honestly before the project started, not after.
Change Management Decides Whether the Migration Actually Lands
A migration can be technically flawless and still fail, because “fail” for the business means people don’t use it. Role-specific training, with separate tracks for data engineers, analysts, and business users and hands-on labs built around real use cases, is what turns a completed migration into an adopted one.
The research backs this up. Prosci’s research found projects with excellent change management were about seven times more likely to meet their objectives than those with poor change management (88% versus 13%). Track adoption after cutover the same way you’d track technical KPIs. Usage rates, support ticket volume, and how many users have quietly gone back to legacy exports are all early warning signs worth watching.
Common Mistakes to Avoid
- Migrating technical debt along with the data instead of using the move as a cleanup opportunity.
- Sizing capacity for momentary peaks instead of sustained, smoothed utilization.
- Enabling Copilot tenant-wide before measuring its CU impact on a pilot group.
- Skipping a governed landing zone and letting workspace creation go unrestricted.
- Assuming sensitivity labels follow data everywhere, including CSV exports.
- Attempting a big-bang cutover instead of wave-based migration with a tested rollback plan.
- Treating parallel-run costs and training as afterthoughts instead of line items.
Wrapping Up
None of these practices is complicated on its own. The hard part is doing them in the right order, before the pressure of a deadline pushes teams to skip assessment, guess at capacity, and cut over all at once.
If you’re planning a move, ZapAI’s Fabric team can assess your estate and map a wave plan before you commit, or you can book a free consultation directly. For more on Fabric, Dynamics 365, and AI, browse the ZapAI blog.
Fabric Migration Questions We Hear Most
How long does a Microsoft Fabric migration take?
It depends on source system complexity and workload count, but most enterprise migrations run in wave-based phases over several months rather than as a single event. Teams that compress the timeline by skipping parallel-run testing tend to pay for it later in rollback incidents.
Can I migrate from Synapse and Power BI Premium at the same time?
Yes, and many organizations do, since they’re often running both. Treat them as separate workstreams with their own assessment, capacity sizing, and cutover plans rather than one combined project, because the licensing deadlines and technical migration paths don’t overlap cleanly.
What’s the difference between OneLake shortcuts and mirroring?
Shortcuts reference data where it already lives without copying it. Mirroring replicates data into OneLake in near real time. Shortcuts avoid duplication, while mirroring avoids the latency of querying data at its source.
Do I need Microsoft Purview for Fabric governance?
Purview integration is how Fabric applies sensitivity labels, tracks lineage, and enforces data loss prevention, so most enterprise governance strategies rely on it. It isn’t a substitute for defining data ownership and access policy. The tooling enforces rules that people still have to write.
What size F SKU should I start with?
Start smaller than you think you need, validate with Microsoft’s Capacity Metrics app over two to four weeks, then scale. Buying for projected peak demand on day one is one of the most common ways Fabric budgets overshoot.