Microsoft Fabric, run as a platform you can afford to keep

Microsoft Fabric is the platform: the capacity you buy, the compute that runs on it, the OneLake storage your data sits in and the security boundary drawn around all of it. It is not your data model, and it is not your reporting. Three layers, and confusing them is the single most expensive mistake in a Fabric programme: the platform (Fabric), the reconciled model layer that sits on the platform, and the reporting that sits on top of that.

Buying Fabric does not give you numbers you can trust. It gives you somewhere to put them. Fabric will store data that does not reconcile just as happily as data that does, and it will charge you the same for the privilege. The platform decision and the trust decision are different decisions, made by different people, and they need to be made in the right order.

This is the platform pillar. It owns the capacity, the compute, the OneLake security model, the networking, and the bill. The two layers above it have their own pillars, because they are genuinely different work.

If you are not yet sure which of the three you are actually buying, the routing panel below shows where each piece of the Fabric lifecycle sits, and the readiness assessment is designed to answer exactly that question before you spend anything.

Because Fabric is sold like SaaS and charges like PaaS. You buy a capacity, not a bill of materials, and every workload in the tenant draws on the same pool: a badly written query, a semantic model that quietly falls back to DirectQuery, a Spark job nobody switched off. Any one of them can throttle the entire tenant and spend the month's capacity over a weekend, and nobody finds out until Monday.

This is the part of Fabric that no licence conversation prepares you for. Capacity is shared, consumption is smoothed rather than capped, and the platform is designed to keep working right up to the point where it visibly stops. The failure is not technical. It is that nobody owns the capacity.

So here is the honest version of what we sell. You are not paying us to build pipelines. You are paying us to police the capacity: to size it, watch it, throttle the things that misbehave, and tell you before the bill does.

• Pause and resume is an F-SKU feature. It does not exist on P. If your capacity cannot be paused, you are paying for evenings, weekends and the fortnight nobody logged in.
• On-demand resizing is F only. Size up for month end, size back down afterwards. On a P SKU that lever is not in the cab.
• Spark autoscale billing is F only. The one control that stops an experimental notebook eating a production capacity.
• F64 is the licence threshold. At F64 and above, viewers can consume Power BI content on a free Fabric licence. Below it, every single viewer needs Pro, which is a licence bill hiding inside a platform decision.
• The platform-hardening features are F only too. Trusted workspace access, managed private endpoints, customer-managed keys and workspace-level private links. The security conversation and the SKU conversation are the same conversation.

That is the FinOps case, and it comes straight off Microsoft's own SKU feature matrix rather than a vendor benchmark. The levers that make Fabric affordable to run only exist on the F SKUs. Which is why the cost question and the migration question turn out to be the same question.

• For the IT Director. Fabric is infrastructure, and it lands on your plate: capacity units, Spark compute, OneLake access, networking, private endpoints, and a tenant that can be throttled by any workspace in it. You are the one who has to make it hold. We give you a platform that behaves, and an owner for the capacity that is not you at 11pm.
• For the Finance Director. You are signing for OPEX, and the thing you need from a platform is that it is forecastable. A capacity that can be sized, paused and watched is a number you can put in a budget. A capacity that nobody polices is a number that arrives after the fact and cannot be explained.

There is no market-wide deadline, and anyone selling you one has invented it. The forcing functions are real but they are specific to you: the legacy Export to Data Lake pipe has been retired, so if your Dynamics data still travels it you are already running on borrowed time; and P SKUs can no longer be bought, only renewed, so the conversion to an F SKU lands at your renewal date, not on some industry cliff edge.

The pipe that is genuinely dead. Export to Data Lake, the legacy Dynamics data-export route, has been retired: deprecated in late 2024 and decommissioned from early 2025 under Microsoft's own transition guidance. If that is still how your Finance and Operations data reaches your lake, the clock is not ticking, it has already gone off. That is a migration, and it is the most common front door onto this pillar.

Azure Synapse Link is not going away. We will not pretend otherwise in order to manufacture a deadline, and a technical buyer would rightly throw us out if we tried. Microsoft supports both Link to Fabric and Azure Synapse Link, and has been explicit that customers who want to keep exporting data and running their own pipelines will be able to do so. So the choice between the two paths is an architecture decision, not a countdown.

And the P SKU question. P SKUs can no longer be purchased. They can be renewed, and they are being retired, which means the conversion to F happens when your agreement comes up. Microsoft is clear that no immediate action is required and that you can carry on using your existing Premium capacity until your next renewal. So the honest position is this: you have a date, but it is your date. What matters is that you arrive at it having already decided, rather than converting under time pressure and inheriting a capacity nobody sized.

We run Fabric as a single connected practice: diagnose, move, build, run, with governance and security as the layer that holds across all four. The spine of all of them is the same idea. The platform is only worth having if it is affordable to keep and safe to open up.

The reason to treat it as one practice is that Fabric punishes the piecemeal approach. A migration done without a capacity plan produces a working platform with an unaffordable bill. A build done without a governance model produces a lake that everyone can read. A capacity that nobody runs quietly drifts until the month it does not. Each rung protects the one before it.

1. Diagnose.

   Find out what you are actually on, what it will cost on Fabric and what breaks when you move, before you commit to anything. The low-commitment first rung: the Fabric readiness assessment.

2. Move.

   Get off the retired pipe and onto a supported path, with the SKU, the capacity and the table strategy decided rather than defaulted. Routes to migration to Microsoft Fabric.

3. Build.

   Put the architecture in: OneLake, the medallion layers, the workspace topology, the capacity design that means one team's experiment cannot take out another team's month end. Routes to Fabric architecture and implementation.

4. Run.

   Someone has to own the capacity: watch it, size it, pause it, catch the query that is about to cost you a weekend. Routes to the managed Fabric platform and FinOps service.

5. Govern and secure.

   Across all four rungs: who can see what in OneLake, and whether the controls you think you have actually hold. Routes to Fabric governance and security.

You can enter at any rung. Most organisations enter at the diagnose rung or through a migration, because those are the two moments when the platform question becomes unavoidable.

They sit on one ladder: assess (a readiness assessment to find out what Fabric will actually cost you and what breaks on the way), move (migrate off the retired pipe onto a supported path), build (the architecture, the workspaces and the capacity design), then run (someone owns the capacity and the bill), with governance and security holding across all of it. Most organisations start with the assessment. Pick the card that matches where you are.

• Fabric readiness assessment. You are not sure Fabric is the right move, or what it will cost. A fixed-scope diagnosis of your estate, your likely capacity, your data paths and what breaks on the way. The entry rung. Fabric readiness and strategy
• Migration to Microsoft Fabric. You are on a retired or unsupported pipe, or converting a P SKU at renewal. The move done with the SKU, the capacity and the table strategy decided in advance. Migration to Microsoft Fabric
• Fabric architecture and implementation. You know you are going to Fabric and need it built properly. OneLake, medallion layers, workspace topology and a capacity design that will not throttle itself. Fabric architecture and implementation
• Managed Fabric platform and FinOps. You have Fabric and nobody owns the capacity. A managed platform service that watches consumption, sizes and pauses capacity, and tells you before the bill does. Managed Fabric platform
• Fabric governance and security. You need to know who can actually see what. OneLake security has sharp edges, and several of them hand data to people you thought were excluded. Fabric governance and security

Our deepest specialism, Microsoft Fabric for Dynamics 365, gets its own block below rather than a card here, so it stands out rather than competing with the five.

We are an independent, Dynamics-native Microsoft data specialist, in continuous practice since 2002, with customers across 20+ countries on 4 continents and the full Fabric lifecycle behind us. What qualifies us is not a badge. It is that we have no incentive to sell you more capacity than you need, and two decades of knowing what Dynamics data does when it hits a platform.

The uncomfortable question on a Fabric engagement is whose side your consultant is on when the capacity conversation comes up. A firm whose economics improve when your consumption rises will always find a reason for you to consume more. We are independent, and the whole managed-platform proposition rests on the opposite promise: the capacity gets smaller when it should, and somebody tells you why.

• Independent. No tier to defend, no quota to fill. Our advice on your SKU, your capacity and your architecture is not underwritten by anyone else's incentives.
• Dynamics-native since 2002. Built around Dynamics data from day one, across D365, AX and NAV. We know what breaks between the ERP and the lake because we have been fixing it for over two decades.
• Customers across 20+ countries on 4 continents. The practice travels.
• The full Fabric lifecycle. Assess, migrate, build, govern, run, delivered as one practice rather than a single-point service you have to stitch to four others.
• FinOps as a discipline, not an afterthought. Capacity is watched, sized and paused as a service, so the platform stays forecastable rather than becoming a monthly surprise.
• Platform, model and reporting in one shop. We can run the platform, the reconciled model layer and the reporting together, so nobody gets to blame the layer below them.

For the depth behind this, see the Microsoft Fabric for Dynamics 365 programme. If you would rather start with your own numbers, the readiness assessment is the cheapest way to find out where you stand.