Microsoft Fabric

So, this guide is deliberately not a feature tour. It is not a list of every product inside Microsoft Fabric, nor a glossary of every name Microsoft has used for those products this quarter. That kind of detail is best taken straight from Microsoft, where it stays up to date.

What does not change as quickly is the why. Why the platform exists. The problems it solves. The shape of a programme that delivers value. The questions to ask before you start. Those are what this guide is built around.

What this guide covers

• The problems Microsoft Fabric is built to solve.
• The six areas that make it a platform, not a single product.
• How Oakland approaches Microsoft Fabric programmes.
• Two real client stories that bring the platform to life.
• A practical self-assessment to help you see where you are.
• How we can help you.

Read it end to end, or jump to the section that fits your starting point. The next section will help you place yourself.

Rajan Chavda

Senior Solutions Architect / Fabric Architecture Lead

Oakland

Explore Rajan’s thoughts on MS Fabric

Why Microsoft Fabric?

That is not a Fabric problem. That is the problem Fabric is built to solve.

How we got here

The pattern is familiar. Cloud warehouses, data lakes, SaaS tools, streaming data, and AI tools were adopted independently over the last decade. Each one solved the question in front of it at the time. The result is architectural sprawl. Data is scattered across platforms, pipelines multiply, and governance becomes inconsistent. Analytics teams spend more time maintaining infrastructure than generating insight.

Analysts report that two-thirds of businesses see data silos as the biggest barrier to digital transformation. That number is not surprising to anyone who has tried to do a single piece of joined-up reporting across a fragmented estate. What is surprising is that most of those organisations are not short of platforms. They have too many.

The five problems we hear most often

• SQL purgatory. Engineers writing the same joins for the same reports for the same stakeholders, year after year. The work never compounds. The platform changes, the plumbing does not.
• Dashboard sprawl. Hundreds of reports, none of them trusted. Everyone builds their own version because nobody trusts the central one. The same number means three different things depending on which screen you open.
• Lakes that do not talk. Data sits in storage but never reaches a model, an agent or a report. The lake becomes a swamp. Every new use case starts by copying the data again into a new place for a new purpose.
• AI on bad foundations. Copilots and agents are bolted onto data nobody has cleaned. The output looks impressive in a demo and falls over in the real workflow. As we say in our AI Guide, most AI failures are data failures.
• Fragmented systems need specialist skills. Data sits across disparate platforms, each with its own tooling, vendor and learning curve. Teams need specialist skill sets just to keep the lights on, and the cost of recruiting and retaining them keep climbing.

These are not new problems. We have seen this film before. What is new is that Microsoft has put serious money behind a single platform that addresses all five at once.

What Fabric does about it

Fabric brings ingestion, engineering, analytics, AI, real-time data, and governance under one roof, with a single underlying storage layer. Not a marketplace of tools that share a logo. One platform, one copy of the data, one set of permissions. One place where the work happens.

The mechanism that makes this work is a single, governed data layer underneath everything that Microsoft call OneLake. Think of OneLake as a single, shared copy of your business data. OneDrive for the organisation, one place every workload reads from rather than yet another silo to fill. Stop copying the data into a new place every time someone wants to use it differently. Less plumbing, less drift, and less audit panic.

The result, when it lands well, is that the work compounds rather than fragments. A model built today uses the same data that the dashboard reads tomorrow. A new agent inherits the governance that already exists in the platform. The boring foundations stop being something you do alongside value and become what enables you to deliver value.

That is the case for Microsoft Fabric. Not transformation, not revolution, just an end to all the stitching.

Why teams choose Microsoft Fabric

Five practical reasons keep coming up in conversations with clients. They align with what Microsoft says about the platform and with what we have seen land in real engagements.

• Effort. Microsoft Fabric is delivered as a SaaS service. That minimises up-front implementation time and the engineering resource needed to stand it up.
• Connectivity. Deep Microsoft and Azure integration is built in. If your estate is already Microsoft-leaning, much of the integration work is already done.
• Simplicity. Unified analytical workloads and a single data source out of the box. The platform arrives shaped, rather than asking you to shape it from scratch.
• Accessibility. Low-code and generative AI interaction drive data democratisation. Business users can do more without waiting in the engineering queue.
• Affordability. Low overhead and simple, capacity-based pricing. The commercial model matches the platform model.

You have heard of Microsoft Fabric, but you do not know what it is or how to make use of it.

You know the name and can list two or three components. But you cannot draw the platform on a whiteboard or say where Microsoft Fabric stops and your existing data estate begins. You are not sure if it replaces what you have or sits alongside it.

This guide is for you.

You have not heard of Microsoft Fabric at all.

It has not crossed your desk yet, or only in passing. You want a plain English starting point that does not assume you have already drunk the Kool-Aid.

This guide is for you.

You have adopted Microsoft Fabric, but you cannot see the value.

You have bought capacity. You have a workspace or three. You may even have a couple of dashboards live. You can sense there is value in there somewhere, but you are not sure how to get to it. This is the audience that needs the most honesty.

This guide is for you.

Your Data Supply Chain

The metaphor we keep coming back to with clients is a supply chain. Raw materials come in. They get cleaned, shaped, and assembled. Finished goods leave, with quality checked at every stage. The whole thing is governed and auditable end-to-end.

Apply that to data: raw data lands, then it gets cleaned, joined, and reshaped. Reports, models, and agents are produced. The lineage is visible, and the permissions follow the data, not the tool. The work that goes in at one end shows up as value at the other.

Platform, not product.

Microsoft has used the word “platform” carefully here. They mean it: Microsoft Fabric is not one product with a fixed feature list at launch. It is a set of capabilities Microsoft will keep adding to.

Once you invest in the platform, you also benefit from every new capability Microsoft ships to it. The Microsoft Fabric you buy this year is not the Microsoft Fabric you will use in three years.

We will confess we love this approach. Too often, what gets called a platform is really a collection of adjacent products with new things bolted on as they ship. Microsoft set out to build a platform from the start. And, just as importantly, licensed it that way too.

The Named Framework

We describe Microsoft Fabric using the same approach we use on the data platform we present in person. Four areas that follow the data from the raw source through to the delivered value. Four foundations that run underneath all of them.

Think of these four areas as our foundational pillars.

01 Integrate

What it is. Bringing data into Microsoft Fabric or making it available without moving it. Streaming feeds, unstructured documents, semi-structured files, databases, and third party services can all be ingested through pipelines or integrated using mirroring and shortcuts so the data stays where it lives and Fabric reads it directly. Whatever shape the data arrives in, this is the door it comes through.

What good looks like. A fresh source can be onboarded in days, not weeks. Streams and batches use the same platform. Engineers do not have to reinvent the connection pattern for every new system.

Foundation that matters most here: Governance and controls. The decisions made at integrate set the tone for everything downstream. Classify data, record its origin, and apply access controls at the door. You do not then spend the next two years untangling who owns what.

02 Store

What it is. One storage layer on which everything else builds. Raw, conformed and curated data, all in one place. Microsoft calls this OneLake. Data is stored once and used many times.

What good looks like. Data is stored once and read by every workload that needs it. No copying between tools to make a new use case work. Storage capacity grows with use, not with effort.

Foundation that matters most here: Monitoring and alerting. Storage at scale is observable storage. Know what sits where, how fresh it is, what it costs to keep, and which workloads are pulling on it.

03 Process

What it is. Cleansing, mastering, classifying, preparing and analysing the raw data so it is ready for a person, a model or an agent to use. The boring, essential work that makes the rest possible.

What good looks like. Pipelines are visible to the business, not buried in code. Errors should surface in minutes. Engineers spend their time building new and repeatable transformations rather than maintaining old ones.

Foundation that matters most here: Medallion. Raw, conformed, curated aka bronze silver gold. Adding quality and reusability to the data.

04 Serve

What it is. Turning the prepared data into something useful. Reporting, analytics, AI models, APIs, copilots, and agents. The bit the business sees.

What good looks like. One source of truth. Self-serve analytics for users who do not write SQL. Models and copilots running on the same data that the dashboards read. New questions answered without new pipelines, using the same data.

Foundation that matters most here: Workflows and collaboration. Serve is where the platform meets the user. If the platform delivers the right data to the wrong people, or the right people through the wrong tool, the value never lands. Workflow design turns a capability into a habit.

This is a lot. A lot to consider, a lot that could go wrong. That is why we exist. To help organisations get the most from the investment, not once but for the long term.

Microsoft Fabric: Incremental Delivery

The principles before the phases

A few things hold true under everything that follows.

Start with the business question. The most common Microsoft Fabric mistake we see is starting with the platform. Teams stand up workspaces, set up capacities, run a demo, and then look around for something to do with it. The platform sits there waiting for a use case to find it. Reverse the order: start with one business question that is worth answering and that you cannot answer well today. The platform’s shape follows from the question, not the other way round.

Lighthouse projects, not big bang. We call our first Microsoft Fabric projects Lighthouse Projects, the same name we use across our AI and data work. Not because they are flashy, but because they show the way. A Lighthouse Project is small enough to land in eight to twelve weeks. Specific enough that the value is obvious. Real enough that the work survives the demo. It does three things at once.

• It proves Microsoft Fabric in your context.
• It builds capability in your team.
• It gives the platform an early advocate, which is worth more than any roadmap.

Scale on early wins. Your first Lighthouse does more than solve one problem. It teaches you what your version of Microsoft Fabric looks like. Which patterns work, which do not, and where the friction sits. The lighthouse project is then a catalyst for incrementing value, the second wave builds on the first, and the third on the second. Each project gets faster, cheaper and more confident. This is the compound effect, and it is how a Microsoft Fabric programme gets out of the pilot phase. Not a five-year roadmap. A series of focused wins that build on each other.

Protect with governance. Governance is the bit teams skip and later regret. On Microsoft Fabric specifically, the temptation is to skip it because the platform makes it easy to spin up a workspace and start working. That ease is a gift in the right hands and a problem in the wrong ones. Build the governance from the first Lighthouse. Not a heavy framework. The minimum that says who owns what, who can see what, and how data leaves the platform. Done early, this is hours of work. Done late, it is a re-platform.

Our five phases

A phased approach to implementing Microsoft Fabric, onboarding initial data sources, and activating first use cases. The Define and Deploy phases get the platform ready. Activate lands the first Lighthouse. Scale compounds the value. Transition lets the business take it on.

Our approach to Fabric technical implementation

Define – Existing estate and requirements

What happens: We understand the current environment and estate, map data sources, gather requirements, and design the solution’s shape.

How: Discovery workshops, requirements gathering, and data source mapping. A walk through the technical estate. Use case solution designs. Architecture documentation, signed off securely.

Outcome: Requirements and design documented and signed off. The team is ready to begin Microsoft Fabric deployment in the next phase.

Deploy

What happens: We deploy the Microsoft Fabric capacities and configure the Fabric environment in line with the architecture agreed in the Define stage.

How: Workspaces and security model deployed. Tenant settings configured, user personas enabled, platform ready to go.

Outcome: A base Microsoft Fabric platform that is implemented and ready for data source onboarding and use case development in future phases.

Activate – Your lighthouse project

What happens: This is where the first Lighthouse Project lives. We onboard selected initial data sources, transform as required, and deliver the first use case on top of that data.

How: Connection and ingestion of priority data sources. Data conformed and curated. Delivery of the first use case on top of the data layers. Solutions served to users.

Outcome: Users are getting value from the data through a range of analytics and the first delivered use case, unlocking the initial insights and analytics from the Microsoft Fabric platform.

Scale – Further use design cases and controls design

What happens: Once the first Lighthouse has landed, we will onboard the next priority data sources. We transform the data to align with the models and deliver further use cases per the agreed designs.

How: Data source onboarding and solution development for the next priority use cases. User engagement and platform monitoring. The future operating model and controls can be developed here if not already in place.

Outcome: Additional insights and analytics are delivered to users through new use cases and gold-standard reports, with each release compounding the value that the Microsoft Fabric platform delivers across the business, therefore driving ROI on your Fabric adoption.

Transition – Handover to BAU and embed

What happens: We transition the Microsoft Fabric platform to business-as-usual operations and ongoing support and maintenance.

How: Documentation, knowledge transfer, and handover to the support team. Transition from project to BAU. The operating model and controls land here if they were not completed in Scale.

Outcome: A Microsoft Fabric platform that is now a valuable, growing part of business as usual at your organisation.

The Oakland Fabric Accelerator

Some organisations are still working out where to begin. Others already have Fabric in place but have yet to turn the platform into something the business genuinely uses. The challenge is rarely the technology itself. It is choosing the right starting point, putting the right foundations in place and delivering a first use case that proves the investment is worthwhile.

That is what the Oakland Microsoft Fabric Accelerator is designed to do.

In ten weeks, we help you move from intent to a secure, production-ready Fabric platform, with priority data connected and a valuable first use case in the hands of users. The engagement also includes knowledge transfer and supported handover, so your team is equipped to keep building once the first delivery is live.

What you come away with

A production-ready Fabric platform

Built with security, governance, and future growth in mind.

Up to three priority data sources connected

Creating the foundation for reporting, analytics, and AI.

One priority business use case delivered.

Proving value early rather than waiting for a long transformation programme to finish.

A team ready to take the next step

Supported by all of the documentation, knowledge transfer, and practical guidance you’ll need to get maximum value from your technology investment.

The Accelerator at a glance

~10 weeks  →  Production-ready Fabric  →  3 priority data sources  →  1 Lighthouse use case  →  Supported handover

Why we start this way

The Fabric Accelerator follows the same principle as our Lighthouse approach: start with value, not technology. We identify the business problem that matters first, then shape the platform around it. That creates a faster route to value while establishing the architecture, governance, and delivery patterns your wider Fabric implementation can build on.

The first use case isn’t the end. It’s the foundation for the next one. Once the platform and delivery pattern are established, additional data sources, reporting, analytics, and AI use cases can be added.

Driving Lasting Value

01 Cost Management

The organisations that keep their costs sensible build a capacity strategy from day one. They have administrators reviewing performance and utilisation on a regular cadence, and they size for real usage rather than for peaks they hit twice a year.

Why this works: Microsoft Fabric is licensed by capacity rather than per query, so most of the spend is tied to the capacity you reserve, not to scaling automatically with every job. The flexibility of a capacity changes this at the edges. Features including Bursting and Smoothing allow for this. Sizing the base capacity well still matters most.

02 Workload management

The winners treat workload control as an operating model decision, not a billing one. They put the right controls in place, so the platform’s breadth supports adoption rather than overwhelming it.

Why this works: Workloads inside Microsoft Fabric cannot be enabled or disabled individually. The capacity-based model means you buy the entire platform once and pay for all of its functionality.

03 Feature maturity

The teams that do well track Microsoft’s roadmap actively rather than discovering changes by accident. They know what is in preview, what is coming, and what is safe to build production work on.

Why this works: Microsoft is investing heavily in Microsoft Fabric, with new features arriving most weeks. Many of those features land in preview before they go into general availability.

04 Migration to the platform

The organisations that get this right break down their existing workloads before they start the move, deciding what to refactor, what to redesign, and what to rebuild.

Why this works: Microsoft Fabric is a SaaS platform, so moving to it from on-premises or PaaS estates is not a lift-and-shift. It is an architectural change.

05 Governance

The winners design workspace strategy, information protection and endorsements from day one. They balance accessibility against control, rather than picking one and later apologising for the other.

Why this works: Microsoft Fabric has a relatively low technical barrier to entry compared with most analytics platforms. That is a gift in the right hands and a problem in the wrong ones.

06 Platform breadth

The teams that land lasting value design for that breadth deliberately. They make sure engineers have what they need, business users have what they need, and the same set of controls works for both.

Why this works: Microsoft Fabric serves a wide range of users, from pro-code data engineers through to business users consuming finished data.

How to recover a Microsoft Fabric project that has not landed

We said at the start that this guide is also for people who have Microsoft Fabric but do not yet see its value. If your Microsoft Fabric programme has stalled, you do not need to start again. You should do four things in this order.

• Pick one painful problem. Not five, one. The one your operations team or finance team would pay to solve.
• Define your value. How do you ensure Fabric delivers what you intended? Are there process efficiencies to be realised, or faster time to insight?
• Strip the platform back to what that problem needs. Switch off the workspaces nobody uses. Concentrate spending where it delivers value.
• Ship one Lighthouse project end-to-end. Use it to rewrite the story that the business tells itself about Microsoft Fabric.

This is where we can help, providing experience and insight. Many times, stalled programmes do not have a technology problem. They have a focus problem; fix the focus, and the rest follows.

Oakland Value Drivers

Oakland’s recommended approach to Microsoft Fabric adoption is grounded in the following value drivers:

Creating trust in data

Established through clear top-down governance, meaning that the data used for reporting and decision making is reliable and managed consistently across the organisation.

Empowering users

The bottom-up approach enables self-service access to data in a controlled way. This allows users to have access to the data they need to make the decisions they need to make.

Evolving our capabilities

As Microsoft Fabric continues to evolve, governance and ownership models should evolve with it, ensuring that new capabilities are adopted deliberately and safely.

Driven by the business

Delivery of analytics products should be led by the business, meaning data solutions are shaped around real business needs and outcomes. The business knows its data better than an IT team.

Integrated planning

Coordinated planning is needed across finance, product, and platform teams to ensure capacity, roadmaps, and priorities are aligned and understood end-to-end.

Building for the future

Establishing firm foundations now will mean that the platform is prepared for AI-enabled use cases without the need for significant rework or remediation later.

Lasting value is one-half of the conversation. The other half is the question every executive is asking right now: when are we shipping our first agent?

Microsoft Fabric: AI & Agents

Here is the awkward part. Most of what gets sold as agentic AI is a glorified script with a chat interface. Microsoft Fabric does not protect you from that, and we will not pretend it does. But what Microsoft Fabric does is give you a place to build the real version. The version that lasts.

Why this matters for the data team

Most AI failures are data failures. We have written about this in our AI Guide. A copilot trained on stale data gives stale answers. An agent that cannot see lineage cannot be trusted with anything that matters. A model with no governance behind it gets switched off the first time legal hears about it.

Microsoft Fabric collapses the gap between the data layer and the AI layer. The same governance applies. The same lineage shows up. The same security rules apply to the data as it enters the model. That is not glamorous. It is the boring foundation that makes the agent worth running.

What Microsoft Fabric does for the agent programme

When you build agents on Microsoft Fabric, five things move in the right direction. They are the five things the CEO will ask about by the end of the year.

Development. A single platform to build, test, and ship agents on. The data the agent needs is already there, governed and trusted. No three-week procurement cycle for a new tool. No new pipeline to feed it.

Single source of truth. One governed, managed dataset that people and agents can rely on, removing the temptation to keep parallel copies or work around the platform.

Ongoing evolution. Agents are not one-and-done. The data behind them changes. The questions they answer change. The platform supports this without a re-platform. New data sources slot in. New models swap in. New use cases inherit the foundation rather than rebuilding it.

Security. The same identity, access, and encryption rules that govern your data govern your agents. An agent cannot see what a person cannot see. Security policies travel with the data into the model.

Governance. Lineage shows where every answer came from. The catalogue records what the agent is using. Controls record who built it and when it last changed. When the audit comes, the answer is not a panic. It is a screen.

Where agents earn their place

In the same three places, we see them work everywhere else, drawn from the Oakland AI Guide.

The information tsunami

• Logs, alerts, and tickets that humans cannot read fast enough. Agents handle the volume, so people handle the judgment.

The document mountain

• Years of reports, lessons learned, and proposals nobody can find. Agents make them searchable in plain English.

The expert shortage

• One specialist’s knowledge made available to a hundred users, around the clock, without burning out the specialist.

None of that is new. What is new is the easier path Microsoft Fabric gives you. Build agents on the data you already have, with the governance you already need.

Agents on, governance on, the platform shaped to scale. None of which is free. Now for the truth about cost.

The Commercial Picture

Cost grows as usage grows

Microsoft Fabric runs on capacity-based licensing. You buy a unit of capacity and size it up as usage grows, then down as it settles. You can also pause and resume capacity outside working hours, so you only pay while it is running. Once in production, we look to reserve a capacity to allow for cost optimisation.

Microsoft has also added finer controls. Autoscale Billing for Spark charges only for the Spark compute you use.

Bursting lets you temporarily exceed capacity through short spikes instead of being throttled, and surge protection caps runaway background activity.

This is by design. With the right project selection, the cost tracks the value rather than running ahead of it. With the wrong project selection, you pay for a platform nobody uses.

What to expect in year one

Year one is rarely the cheap year. There is platform spend, migration work, governance setup, and the time the team needs to learn the platform. Set the expectation that year one is an investment year, with value building through it as the first Lighthouses go live.

By year two, the picture typically improves. Capacity gets sized to real usage. Old platforms get decommissioned. The work compounds. The bigger benefit, and the harder one to put a clean number on, is faster decisions and engineers who are no longer drowning in plumbing.

Where capacity sizing goes wrong

• Buying for peak and paying for the trough. Sizing capacity for a once-a-month, month-end report means paying for that headroom every other day of the month.
• Not pausing capacity in development. Development workloads do not need to run 24/7. Pausing them outside working hours is a meaningful saving.
• Treating capacity as a one-off decision. Capacity should be reviewed every few months, not signed off at launch and forgotten.

If this sounds like a lot of attention to pay to a single line item, it is the same discipline that any cloud data platform demands. Snowflake, Databricks, BigQuery and Azure compute all need the same regular review. Microsoft Fabric just consolidates it into one capacity number.

None of these are reasons not to use Microsoft Fabric, but they are reasons to size it carefully, measure it honestly, and revisit it regularly.

Knowing what it costs is one half of being ready. The other half is knowing where you stand today.

Next is a quick honest check.

Are You Ready For Microsoft Fabric?

Data integration and storage

• Can you list every system that feeds your data estate, and who owns each one?
• Could you connect a new source in days, or would it take a quarter?
• Do you know which data you would move first, and why?

Data engineering and transformation

• Are your pipelines visible to the business, or only to the people who built them?
• When a pipeline breaks, do you know within minutes or within days?
• Could a new engineer pick up your transformation work without two weeks of handover?

Analytics and reporting

• Is there one source of truth for the numbers the board sees?
• When two reports disagree, can you tell which one is right and why?
• Do business users build their own analysis, or is it always a ticket to the data team?

Data science and AI

• Are your models trained on the same data the dashboards read?
• Do you know which models are live and which have drifted?
• Is there one place where AI workloads are governed, or are they scattered?

Real-time and operational data

• Are operational decisions made on live data, or yesterday’s batch?
• When something breaks in operations, does the data team see it before the customer does?
• Is your real-time work on the same platform as your reporting, or running in parallel?

Governance, security and lineage

• Could you show, in a meeting, who has access to a given dataset?
• Could you show where a given number came from, end to end?
• Is governance enforced by the platform, or written down somewhere nobody reads?

Scoring

If you answered no to more than half, your current estate is doing this work the hard way. Microsoft Fabric can change that. We can help.

Case Study – UK Transport

Sector

One of the country’s leading operators.

Challenge

The data estate had grown organically. Legacy systems and manual processes made business reporting hard to scale, govern, or trust. The organisation was navigating complex changes. Systems, processes, and data needed to be untangled and rebuilt in a new, independent environment. With dozens of data sources spanning ticketing, revenue, timetabling and operations, they needed a structure that could handle complexity, fast and future-proof.

Approach

A discovery phase across the business set requirements, prioritised use cases, and defined a clear path forward. A future-state architecture and roadmap brought clarity to a landscape of over 20 data sources. A structured technology evaluation followed, in which Microsoft Fabric emerged as the logical choice. Delivery ran in phases. Platform development and key dataset onboarding. The move from manual processes to automated pipelines. All inside a governed environment.

Why Microsoft Fabric

Integration with the client’s existing Microsoft estate unified data and reporting into a single experience. The architecture allowed the platform to scale. The commercial model helped manage cost. The client wanted something powerful but practical, not heavily bespoke. Microsoft Fabric struck that balance.

Result

Reporting is centralised, automated and governed. Teams access consistent, timely insight across revenue, passenger demand, and operational performance. Data quality and consistency have improved, increasing trust in the data. The move away from legacy systems and manual processes has delivered efficiency gains and cost savings. Additional data sources continue to be onboarded in a controlled, prioritised way. The organisation is now exploring more advanced analytics and AI use cases.

“Oakland did well to apply their knowledge of data warehousing to that of our business, helping build a modern, scalable data platform in Fabric.”

– Client Programme Lead, UK Transport Operator.

How we can help

We support the full lifecycle, from architecture and deployment through to adoption and governance.

• Architecture and platform design.
• Deployment and environment set-up.
• Ingestion and data engineering.
• Solution development on Microsoft Fabric.
• Adoption and enablement.
• Governance, security and lineage.

Microsoft Partnership