What Is Microsoft Fabric? A Plain-English Guide for Australian Executives
- Matt Lazarus
- Jun 12
- 5 min read
At some point in the past year, a slide has crossed your desk proposing a "migration to Microsoft Fabric". The slide assumed you knew what Fabric is. This guide is for everyone who nodded anyway.
Fabric matters to non-technical leaders for one commercial reason and one strategic one. Commercially, Microsoft is retiring the Power BI Premium licensing many businesses run on, which converts "should we look at Fabric" into a dated decision. Strategically, Fabric changes how the entire data estate is bought, built and governed - which makes it a budget conversation, not a tooling one.
Here is what it actually is, in the language of cost, risk and capability.
Key Takeaways
Fabric is one platform replacing many - pipelines, warehousing, reporting and AI workloads sharing one copy of the data on one capacity.
OneLake is the core idea: store data once, let every tool read it - ending the copy-and-reconcile tax between systems.
Premium retirement forces the timing - the question is no longer whether to decide, but how deliberately.
What Is Microsoft Fabric, in One Paragraph?
Fabric is Microsoft's unified data platform: the tools for moving data (pipelines), storing it (lakehouse and warehouse), analysing it (Power BI) and applying AI to it, all rebuilt to run on a single shared foundation called OneLake, paid for through one pooled capacity rather than separate per-product licences. It is less a new product than a consolidation of the data products you may already own pieces of.
The pitch, stripped of marketing: today your data is copied between systems that each charge, each break and each hold a slightly different version of the truth. Fabric's wager is that storing data once and bringing every workload to it is cheaper and safer than moving data to every workload.
What Is OneLake - and Why "OneDrive for Data"?
OneLake is the single storage layer underneath everything in Fabric, and the OneDrive analogy is genuinely the right mental model: one place where the organisation's data lives, visible to every tool, with no copies to synchronise. A pipeline lands data into OneLake; the warehouse queries it there; Power BI reads it there directly.
The business consequence is the end of a tax you have been paying invisibly: the integration plumbing between systems. Every copy step in today's estate is a cost (engineering time), a risk (copies drift apart) and a delay (data is only as current as the last copy job). Removing the copies removes all three - which is why the OneLake idea, not any individual feature, is the actual product.
What Changes Commercially With Capacity Licensing?
Fabric replaces per-product, per-user licence sprawl with pooled capacity: you buy an amount of computing power (an F-SKU) and every workload draws from it. Heavy use of pipelines this morning and heavy reporting this afternoon share the same purchased pool - and the meter is visible.
What this means in practice for a mid-market budget:
Fewer line items: capacity replaces the patchwork of Premium, separate ETL tooling and warehouse compute - though Pro licences for report authors remain.
A new discipline: capacity is finite, so badly built workloads now visibly crowd out others - inefficiency stops being free.
A forced decision: Microsoft is retiring Power BI Premium P-SKUs in favour of Fabric F-SKUs, so organisations on Premium face a dated migration whether or not they adopt any other Fabric workload.
That retirement is why this is on your desk now: the licensing transition is the same project as the platform decision, and doing it deliberately is the entire case for a planned Power BI to Fabric migration rather than a renewal-deadline scramble.
Does Adopting Fabric Mean Rebuilding Everything?
No - and treating it as a big-bang rebuild is the most expensive way to do it. Existing Power BI reports, models and workspaces carry across; Fabric is additive underneath them. The sensible path is staged: move the licensing foundation first, then adopt workloads one at a time where each pays for itself.
A typical staging for an Australian mid-market estate: capacity and workspace migration first (the forced part), then the highest-pain data pipeline rebuilt into the lakehouse, then the largest model converted to Direct Lake to eliminate its refresh window. Each stage delivers standalone value, and nothing requires betting the estate on day one. The honest costs to plan for: capacity right-sizing takes a quarter of observation, some legacy patterns (heavy gateway dependencies, exotic connectors) need rework, and your team needs lakehouse skills it may not yet have - which is where Microsoft Fabric consulting earns its fee, building the first patterns your team then repeats.
What Should a Board Ask Before Approving the Budget?
Five questions separate a deliberate migration from an expensive drift. What is our Premium retirement date and renewal exposure? What capacity size does our current workload actually need - measured, not guessed? Which workloads move in which order, and what does each stage return? What governance changes when every tool shares one lake? And who on our team will own this platform after the consultants leave?
Good answers are specific and staged. Vague answers - "we'll size it once we're on it", "everything moves together" - are how migrations double their budgets. The platform rewards planning unusually well because the meter makes waste visible from week one.
What Does Fabric Cost a Mid-Market Organisation in Practice?
Fabric is bought as capacity - a pool of compute, sized in F-SKUs, that all workloads draw from. Entry-level capacities cost a few hundred dollars a month on pay-as-you-go; the sizes that comfortably run a mid-market analytics estate typically land in the low thousands monthly, with reserved pricing taking roughly forty per cent off for a one-year commitment.
Two commercial behaviours matter more than the list price. Pay-as-you-go capacity can be paused - a development environment that runs business hours only costs a fraction of one running around the clock. And capacity at F64 and above includes report viewing for unlimited users, which is the crossover point where organisations with hundreds of viewers stop paying per-user licences and the economics flip.
The sizing mistake to avoid is buying for the peak on day one. Start small, measure the capacity metrics app for a month of real usage, and resize - capacity changes take effect in minutes, not procurement cycles. Organisations that size from evidence routinely run one or two SKU levels below their original estimate.
One number worth fixing in the business case: the migration cost for existing Power BI content is near zero, because Premium workspaces and their reports run on Fabric capacity unchanged. The spend buys new capability alongside what you have, not a rebuild of it - which changes the risk profile of saying yes.
The Decision Is Dated - the Strategy Should Not Be
Fabric is a genuine consolidation with a real forcing function attached. The retirement of Premium sets the deadline; the OneLake architecture sets the opportunity. Organisations that treat the two as one deliberate project get a smaller bill and a stronger foundation; organisations that treat the deadline as the whole story migrate their licences and strand the value.
Ask the five questions, stage the workloads, and size the capacity on evidence. The platform decision is being made either way - the only variable is whether it is made on your terms.
