The Hidden Costs of a Microsoft Fabric Migration Nobody Tells You About

Nothing here is an argument against Fabric. It is an argument against a business case built only from the licence cost and the implementation fee. The pattern is consistent across mid-market manufacturing, FMCG, logistics and EPC estates: the implementation quote is usually close to right, but the total cost of getting from a working legacy stack to a decommissioned one is not.

Most of the missing money sits in the overlap period, in the capacity you consume while migrating rather than when steady, and in your own people's time. This is the layer on top of the base implementation cost and SKU sizing.

The full register, with the operational reason each line appears and the clause that removes the argument later:

The legacy stack cannot be switched off on Fabric go-live day. Finance and operations need at least one full monthly close reconciled on both platforms before trusting the new one — that means paying for two data platforms, two sets of support, and two teams reconciling differences, typically for one to two quarters. The overlap is not a failure of planning; it is what a responsible cut-over looks like. What goes wrong is that the business case assumes a single switch-over date, so the second platform's cost sits nowhere.

Two things extend the overlap in practice: a reconciliation difference nobody can explain — a margin figure that differs by 0.4% because the legacy view silently excluded credit notes — and a downstream consumer nobody inventoried, like a spreadsheet a regional finance lead has refreshed every Monday for four years. The contract answer is to make the decommission date a deliverable with an evidence test, not an aspiration, and to hold a payment milestone against it.

A migration consumes capacity twice: business-as-usual refreshes plus historical backfill and repeated reprocessing. Fabric smooths background operations over a 24-hour period, so a heavy overnight backfill raises the consumption floor into the following business day rather than clearing at midnight. Translate that into an operating day: the backfill of four years of production orders finishes at 05:00, the plant manager opens the OEE report at 06:30 and it takes 20 seconds longer to load, and by the following week a mid-morning refresh is rejected outright. The conclusion in the room is "Fabric is slow" rather than "we sized the capacity for steady state and ran a migration on it".

The practical answer is a separate capacity for migration work, or a temporary SKU step-up with a named scale-down date written into the plan. Both cost money; neither costs as much as a stalled adoption. Set capacity-level surge protection thresholds and workspace-level CU ceilings so the migration workspace cannot monopolise the capacity. Buying a bigger SKU to cover an inefficient Silver layer is the most expensive way to solve that problem.

It is scoped as a lift-and-shift of existing views and turns out to be a remodelling job. Legacy warehouse views encode years of undocumented business logic — exclusions, overrides and hard-coded date ranges — that must be rediscovered, agreed with the business and rebuilt as conformed dimensions and facts rather than copied. In an ERP-heavy estate the symptom is familiar: eleven definitions of "net sales", each correct for the report it was built for. Moving them to Delta tables does not resolve them; it puts them side by side, where the disagreement becomes visible and someone has to decide.

That decision work is the real cost, and it is not an engineering cost. It is a series of half-hour conversations with the people who know why the exclusion exists — the demand planner, the credit controller, the plant scheduler. Scope this by artefact count rather than by report count. "Eight conformed dimensions and five fact tables" is a scope. "Migrate the existing reports" is a liability.

Direct Lake does not support calculated columns, calculated tables, user-defined hierarchies or user-defined aggregations on Direct Lake tables. Binary and GUID types are unsupported. Import-mode models rely on several of these. Every mature Power BI estate contains the same habits: a calculated column flagging a row as "returnable", a date table from auto date/time, a hierarchy built in the model, an aggregation table added when a visual got slow. Each has to be re-engineered — most often by pushing the logic upstream into the Silver or Gold Delta table, which is the correct place for it and also a change to the pipeline, not just the model.

Two further constraints: Direct Lake carries per-SKU guardrails (F2–F8 allows 300 million rows and a 10 GB model; F64 allows 1,500 million rows and 25 GB), and a Direct Lake model cannot be created in a workspace in a different region from the data source — a genuine constraint for a group operating capacities in the UAE and India. Direct Lake on SQL also falls back to DirectQuery on non-materialised views and SQL-based access control; a model that performs well in a demo and badly in production is usually one silently falling back. The de-risking clause is a model-by-model conversion assessment before signature. Import mode remains a legitimate answer — it is not a migration failure.

Three of the largest lines never appear on any invoice. Internal subject-matter time — the people who can confirm why OTIF excludes intercompany transfers are the operations and finance leads running the business this quarter, and a migration needs perhaps two days a week of that attention across a 12–16 week programme. Where that time is not named in the SOW, the programme does not stop — it slows, and slow is billed. FinOps ownership — someone must watch consumption weekly and decide whether to optimise or scale, and the Capacity Metrics app retains only 14 days of compute data, so a spike from three weeks ago is not investigable.

Training and the productivity dip — analysts fluent in Power Query and Excel must learn notebooks, Delta table behaviour and semantic model discipline, and output falls for four to eight weeks before it rises. And the cost of decisions deferred — a migration that stalls for six weeks because nobody will decide who owns the definition of "active customer" is paying for delivery capacity, consumption and parallel running throughout. This is a sponsorship problem, not a technical one, and the most common way a data programme fails.

A cost register does not make the costs go away. Naming parallel running honestly means the business case shows a higher number than the competing proposal that ignored it — and some buyers will pick the lower number. Fixed-scope contracts move risk, they do not remove it: a partner who fixes the price on an estate they have not profiled will either pad the number or manage the scope down when it hurts, so a short paid discovery before the fixed-price build is the honest structure.

Consumption is a moving target — Copilot rates are published today, but AI feature adoption is not forecastable from a pilot, so model a range and monitor weekly. Reservations reduce the rate, not the exposure — they commit you for one or three years, do not cover storage or networking, and pausing a reserved capacity may not lower cost at all. Some data quality problems are not fixable in the platform — if the plant enters downtime reasons as free text, no medallion layer creates a clean reason code retrospectively; you fix it forward from the day the master data changes, and history stays approximate. And none of this covers a bad architecture decision — putting the lakehouse in the wrong region is a rebuild, which belongs in week one of design, not a cost register.

Five questions to answer this week, before the next proposal is signed:

• What is the earliest date the legacy platform can actually be switched off, and what evidence would finance need — one reconciled close, or three?
• What is your current capacity consumption at the 90th percentile, and how much headroom is left for backfill? The Capacity Metrics app answers this in ten minutes
• How many semantic models contain calculated columns, calculated tables, hierarchies or aggregations? That count is your Direct Lake rework estimate
• Who is named as the capacity owner, and what happens in the week they are on leave?
• Which three business definitions are currently disputed between departments — and who has authority to settle each one?

If question five has no answer, fix that before signing anything. It is the cheapest problem on this list today and the most expensive in month four. We run Fabric migrations on a fixed-scope basis after a short paid discovery, because that is the only structure where naming these costs up front is in both parties' interest.