QUICK SUMMARY
We cut a 90-minute Power BI Import refresh tail to ~4 minutes in a 14-week Microsoft Fabric migration with zero production downtime. The project modernized a US-based specialty insurance carrier’s fragmented ADF + Synapse + Power BI stack – 14 ADF pipelines, two Synapse workspaces, nine Power BI workspaces, and 40+ Import-mode semantic models – delivered by three full-time data engineers and a part-time Fabric architect across thirteen weeks of phased build and two weeks of parallel-run. The hardest problems weren’t the lift-and-shift: Fabric capacity smoothing penalties, OneLake shortcut RBAC inheritance, Delta schema collisions, a Direct Lake fallback our shadow window missed, and a parity-harness timezone bug that cost two days.
Why a Fragmented Microsoft Data Stack Becomes a Roadmap Blocker
If your team firefights handoffs between Azure Data Factory, Synapse, and Power BI instead of shipping dashboards, if every Power BI Import refresh misses its SLA, and if audits flag lineage breaks across three governance surfaces, you need a phased Microsoft Fabric migration strategy. We saw these symptoms in late 2025 with a US-based specialty insurance carrier – 1,800 employees, $420M in annual premium, eight years of reporting debt across three acquired subsidiaries. Over time, the estate had grown organically: 14 ADF pipelines, two Synapse workspaces, nine Power BI workspaces, three billing relationships, and a daily underwriting dashboard that ran 90 minutes after the 6pm ETL closed.
What Is a Microsoft Fabric Migration?
A Microsoft Fabric migration is the phased replacement of a fragmented Microsoft analytics stack – Azure Data Factory for ingestion, Synapse for warehousing, ADLS Gen2 for storage, Power BI for reporting – with a unified SaaS platform built around OneLake, Fabric Data Factory, Fabric Warehouse, and Direct Lake Power BI. Teams run both stacks in parallel behind workspace-level deployment pipelines and cut over workload-by-workload, gaining end-to-end Purview lineage and eliminating cross-service refresh windows without halting reporting.
Lift-and-shift via the Fabric Migration Assistant would have moved ADF JSON into Fabric Data Factory and called it done – same refresh tail. A full rebuild would have meant a feature freeze. Phased modernization migrated each workload while replacing its Import-mode semantic model with Direct Lake and consolidating governance into OneLake Security. It became the backbone of the engagement.
What Is the OneLake Medallion Architecture?
The architecture had two pieces. First, a standard medallion: a Bronze Lakehouse for raw ingestion, a Silver Lakehouse for cleaned tables, and a Gold Fabric Warehouse exposing T-SQL aggregates. All three layers store data as Delta-Parquet in OneLake – a single logical lake built on ADLS Gen2 that every Fabric workload reads and writes natively. Capacity flows through a single F-SKU, billed in Capacity Units (CUs), covering pipelines, Spark, warehouse, and Power BI under one dial.
Second, the Microsoft Fabric migration relied on a workspace-level deployment pipeline: each Power BI workspace was duplicated into a Fabric workspace, and a stage flag decided which one business users hit. As a result, cutover became a config change, reversible in minutes.
The highest-leverage tool was a Direct Lake compatibility gate that ran before flipping any semantic model. Direct Lake silently falls back to DirectQuery on three conditions – rowgroups exceeding 1M rows, unsupported column types, or tables with uncommitted writes – and the fallback erases the entire latency win.
INFO.STORAGEMODES() is the only reliable way to detect a silent Direct Lake fallback – the report UI doesn’t surface it, and CU consumption only flags it after the damage is done.
The Migration in Six Phases
We avoided a big-bang cutover.
- Phase 1 – Discover (weeks 1-2): inventoried every pipeline and semantic model; a third turned out to be unused orphaned artifacts.
- Phase 2 – Design (weeks 2-3): blueprinted Bronze/Silver/Gold zones and sized F64 capacity against the 95th-percentile concurrent CU draw.
- Phase 3 – Migrate (weeks 3-7): lifted ADF pipelines via the Migration Assistant in an assess-mount-migrate sequence.
- Phase 4 – Refactor (weeks 6-10): converted Power BI Import models to Direct Lake and rebuilt Synapse Spark notebooks.
- Phase 5 – Govern (weeks 9-11): applied Purview labels and OneLake Security at the table and column level.
- Phase 6 – Cutover + Optimize (weeks 11-15): workspace-by-workspace cutover with two weeks of parallel-run before the legacy estate was decommissioned.
Validation and the One Cutover We Rolled Back
Before each workspace flip we ran three gates: contract parity (same DAX, same results within tolerance), latency parity (Direct Lake p95 within 10% of Import baseline), and capacity parity (CU consumption under F-SKU smoothing threshold for 24 hours). Traffic from the previous 24 hours ran in shadow via the Power BI REST API.
Our first version of the contract test harness got it wrong. We hadn’t normalized timezone offsets – Power BI semantic models default to UTC, but the carrier’s Synapse stored procedures had been silently writing in America/Chicago for years. We spent two days chasing what looked like a 0.3% data drift before someone noticed every reconciled row was exactly six hours apart.
One cutover still failed. The underwriting_daily_v2 semantic model passed all three gates, then flipped silently into Direct Lake fallback eight hours into production traffic. Meanwhile, an overnight claims-system upload pushed a policyholder-id column past the 1M-row-group threshold. As a result, P95 latency jumped from sub-second to twelve seconds. However, we flipped the deployment-pipeline stage back in three minutes.
Modernizing a fragmented Microsoft data estate? Our team at ScriptsHub Technologies leads Microsoft Fabric migration programs as part of our Data Analytics services for SaaS, healthcare, financial-services, and insurance clients across the US, UK, and India. Reach out at scriptshub.net or connect with us on LinkedIn.
Results: 90-Minute Refresh Tail Cut to ~4 Minutes
After thirteen weeks of build and two weeks of parallel-run, completing January 2026, the legacy stack served zero production traffic.
SCRIPTSHUB MICROSOFT FABRIC MIGRATION RESULTS – Q1 2026
Daily underwriting dashboard refresh tail cut from 90 minutes to roughly 4 · sub-second visual queries on warm cache · 60-80% storage churn reduction · 5 governance surfaces consolidated to 1 · Zero production downtime across 13 weeks of build and 2 weeks of parallel-run · One Direct Lake conversion rolled back and re-completed inside the same week. Delivered by three engineers and a part-time Fabric architect on an estate of 14 ADF pipelines, two Synapse workspaces, and 40+ Power BI semantic models.
Three Microsoft Fabric Migration Mistakes (and How We Fixed Them)
Three specific things failed during the engagement.
1. Direct Lake silently fell back to DirectQuery on cutover. A column pushed past 1M-row cardinality from an overnight claims-system upload pushed a policyholder-id column past the 1M-row-group threshold. As a result, P95 latency jumped from sub-second to twelve seconds.
Fix: a Direct Lake compatibility gate using INFO.STORAGEMODES() running continuously in production, with an alert on any FallbackReason other than NoFallback.
2. A OneLake shortcut bypassed OneLake Security via inherited ADLS RBAC. A junior actuarial analyst flagged a column showing executive-compensation figures on a report he was QA-ing – the shortcut had inherited the storage account’s broader RBAC, not the OneLake role configured on the destination Lakehouse. Caught within 90 minutes via Purview’s audit log. The CISO insisted on a four-hour security review before the next phase shipped.
Fix: shortcut targets must have OneLake-equivalent RBAC at the source side, or mirror the data into OneLake instead.
3. Direct Lake quietly rejected two datetime2(7) columns into DirectQuery fallback. Beyond the cardinality threshold, Direct Lake also rejects the SQL Server default datetime precision. Two underwriting tables used datetime2(7) for policy-issued timestamps.
Fix: cast every datetime column to datetime2(3) in the Silver-to-Gold transformation, plus a deployment-pipeline schema check that fails fast on precision-7 columns landing in Direct Lake tables.
WHAT WE’D DO DIFFERENTLY NEXT TIME
Three changes. Skip the two-week capacity-modeling exercise – peak CU draw was obvious from the ADF and Synapse billing meter scaled by a 1.4× concurrency factor. Run the Direct Lake compatibility gate inside the deployment pipeline from day one, not as a post-cutover production monitor. And treat OneLake Security as Phase Zero alongside the deployment-pipeline scaffolding, not a Phase 5 governance task.
When to Choose Microsoft Fabric Migration
A Microsoft Fabric migration is a routing problem disguised as a re-platform problem. The legacy ADF, Synapse, and Power BI workloads are not dangerous; the all-at-once cutover is. Run both stacks in parallel behind workspace-level deployment pipelines, and build a contract test harness that includes Direct Lake fallback detection. Then, cut over workload-by-workload with rollback as a stage-flag flip. ScriptsHub Technologies has led Microsoft Fabric migration engagements for SaaS, healthcare, financial-services, and insurance clients across the US, UK, and India. Reach out at scriptshub.net.
Frequently Asked Questions
Q1: How long does a typical Microsoft Fabric migration take?
A 14-pipeline, 40-semantic-model estate migrates in 12-16 weeks using phased modernization. Smaller single-workspace estates finish in 6–8 weeks. Time scales with semantic models and pipelines, not raw data volume.
Q2: Why Direct Lake instead of Import mode?
Direct Lake delivers Import-mode performance on OneLake-resident data without the refresh tail – no scheduled refresh, no F-SKU saturation. Pick Import only for tables outside OneLake or models exceeding Direct Lake’s cardinality limits.
Q3: What’s the biggest risk in a Microsoft Fabric migration?
Hidden state coupling between workspaces – a shared dataset used by two semantic models, or a Synapse view feeding three Power BI reports. Single-model parity tests miss these. Run a workspace-dependency audit and Purview lineage scan before any cutover.
Q4: How does Microsoft Fabric compare to Databricks and Snowflake?
Fabric wins when the estate is Microsoft-native – Power BI, Synapse, ADF, and Azure SQL consolidate into OneLake without re-platforming the BI tier. Databricks suits Spark-heavy ML; Snowflake suits multi-cloud SQL when the BI layer isn’t Power BI.