Before you buy a Microsoft Fabric capacity, check five things: what your refresh and usage patterns actually look like (measured, not assumed), what the capacity will cost over three years rather than per month, which of your workloads genuinely need Fabric, which parts of your estate should not move at all, and who in your team will run the platform once it exists.
Most Fabric problems I see are not technical. They are purchases made on momentum: a roadmap slide, a conference talk, a nervous feeling about being left behind. Momentum is not a business case, and a capacity bought before those five checks becomes expensive quietly, months after everyone stopped paying attention.
I've written separately about when a move to Fabric makes sense and why capacity bills balloon. This post is the step before both: the pre-purchase checklist.
What should you check before buying a Fabric capacity?
There is no honest market statistic that tells you whether your business is ready, so here is the checklist as a structured table instead. Every row is something you can verify yourself before spending anything.
| Check | How to verify it | What skipping it costs |
|---|---|---|
| Measured refresh and usage patterns | Pull actual refresh times, dataset sizes and user counts from the Service, over weeks not days | A capacity sized on guesswork, wrong in either direction |
| Three-year cost vs staying put | Model the capacity, licensing and migration effort against what today costs | A monthly number that looked fine and a total that didn't |
| Workloads that actually need Fabric | List what you'd use beyond Power BI: pipelines, lakehouse, warehouse, real-time | Paying for a platform and using one corner of it |
| What should not move | Identify reports and sources that work fine where they are | Migration effort spent making nothing better |
| Skills and ownership | Name who administers capacity, monitors consumption and owns cost | An unwatched meter, and a bill that surprises finance |
| A rollback position | Know what you'd do if the trial numbers don't hold | Committed before the evidence arrived |
If you can fill in every row with evidence rather than opinion, you are further ahead than most organisations that already bought a capacity.
Do you actually know your refresh and usage patterns?
This is the check that decides whether the capacity is sized right, and it is the one most often skipped, because everyone assumes they already know the answer.
What you assume: the big sales model refreshes overnight and people look at reports in the morning. What the measurements usually show: several models refreshing hourly because someone once asked for "up to date numbers", two of them refreshing identical data, a report nobody has opened since March consuming a daily refresh, and a usage spike every Monday at 9am that the capacity has to survive.
Capacity consumption in Fabric is driven by what actually runs, so sizing from what actually runs is the only method that works. Pull the real numbers from your tenant over several weeks. Anything less is a guess wearing a spreadsheet costume.
What will it cost over three years, not per month?
The monthly price of a capacity is the most visible number and the least useful one.
The honest comparison is three-year total cost of each realistic path: staying exactly where you are, moving partially, and moving fully. That means capacity cost at the size your measured patterns need (including headroom for the Monday spike), plus licensing for your users, plus the migration effort itself, plus the running cost of whoever administers it. Against that, the true cost of today: current licensing, current workarounds, current people-time.
Two things reliably surprise people in this exercise. The path where you stay put is sometimes cheaper for years, and admitting that early is far less painful than discovering it in year two. And the migration effort is usually the biggest line in year one, bigger than the capacity itself. Microsoft's list prices move too, so check them on microsoft.com on the day you model, and date the model.
Which parts of your estate should not move at all?
Not everything belongs in Fabric, and a good migration plan is defined as much by what it leaves alone as by what it moves.
Strong candidates for staying put: reports that work, refresh reliably and serve their users, connected to sources that aren't changing. Moving these makes nothing better and risks making something worse. Also anything scheduled to be retired within the planning horizon, because migrating a report you're about to switch off is effort with a negative return.
Strong candidates for moving: workloads that are actively hurting where they are. Refreshes hitting limits, data engineering held together with manual steps, genuinely large data that Power BI Pro workspaces struggle with, or a real need for the parts of Fabric that aren't Power BI at all.
Sequence by risk, not by what is easiest to demo. The demo-friendly migration first is how estates end up half-moved, with the hard half still ahead and the budget behind.
Who will run it once it is live?
A Fabric capacity is not a purchase, it is an operational commitment. Somebody has to watch consumption, investigate spikes, decide when to scale, manage workspaces on the capacity, and own the relationship between usage and cost. In a lot of SMEs, the honest answer to "who does that?" is nobody, because the reporting estate has been running on the goodwill of one Excel-literate person in finance.
That is not a reason to avoid Fabric. It is a reason to name the role before you buy, even if the answer is a support arrangement rather than a hire. An unwatched capacity does not fail loudly. It just consumes, and the bill arrives as a fact rather than a decision.
What does a formal readiness assessment cover?
You can do everything above yourself, and for a small estate you probably should. Where the estate is bigger, or the decision has to survive a board, there is a case for doing it formally.
My Fabric Readiness Assessment is £5,950 fixed: five days of work delivered over about three weeks. It produces a maturity benchmark across data, platform, operating model and skills (scored, so you can re-run it in a year and show what moved), a target architecture with the reasoning written down, capacity sizing with a three-year cost model built from your actual refresh patterns and user counts, a 90-day plan, an 18-month roadmap sequenced by risk, and an executive deck with the cost model in it. Half the fee comes off a migration booked within 90 days, and I sell no licences or seats, so nothing in the recommendation is shaped by resale.
The part I'd stress, whether you buy it from me or build it yourself: "not yet" is a valid outcome, and sometimes the valuable one. An assessment that concludes you should wait, or move far less than proposed, has paid for itself just as thoroughly as one that green-lights the migration. The three-year cost model is usually what changes the conversation, because it is the first time anyone has put the real number next to the plan.
Common questions
What should I check before buying a Microsoft Fabric capacity?
Five things: your measured refresh and usage patterns, the three-year cost of moving versus staying, which workloads genuinely need Fabric rather than Power BI alone, which parts of your estate should not move, and who will administer the capacity and own its cost. Each one can be verified with evidence before you spend anything, and each one skipped tends to resurface as a bill.
How do I know what size Fabric capacity I need?
Measure, don't assume. Pull real refresh durations, dataset sizes, refresh frequencies and user activity from your tenant over several weeks, including the peaks, and size against that with headroom. Capacities sized from a hunch end up wrong in one of two expensive directions: too big and you pay for idle compute, too small and you meet throttling in your first month.
Is Microsoft Fabric worth it for a small business?
Often not yet. If your estate is a handful of Power BI reports on Pro licences, refreshing reliably, Fabric adds cost and operational load without solving a problem you have. It earns its keep when you have genuine data engineering needs, data volumes Pro struggles with, or several workloads that would otherwise each need their own tooling. I've covered the timing question fully in the when to move post.
Can I try Fabric before buying a capacity?
Yes, and you should treat a trial as evidence-gathering rather than a demo: run your real workloads, at real sizes, on real refresh schedules, and record the consumption. A trial that only ever ran a sample dataset tells you how the sample behaves. Check the current trial terms on microsoft.com before you plan around them, because Microsoft adjusts them from time to time.
What makes Fabric capacity bills so unpredictable?
Consumption. A capacity is a pool of compute that everything you run draws from, so a new hourly refresh, an inefficient query or an enthusiastic new user changes the draw without anyone approving a purchase. The fix is ownership and monitoring, which is a pre-purchase decision. The full mechanics are in why is your Fabric capacity bill so high.
Do I need to move everything to Fabric at once?
No, and you almost certainly shouldn't. The stronger pattern is to move the workloads that are actively hurting first, leave working reports where they are, and sequence the rest by risk. A partial move that runs well beats a total migration that stalls halfway, and some things never need to move at all.
What does a Fabric readiness assessment cost?
Mine is £5,950 fixed for five days of work over about three weeks, covering a scored maturity benchmark, target architecture, capacity sizing with a three-year cost model, a 90-day plan and an 18-month roadmap. Half the fee comes off a migration booked within 90 days. Whoever you use, insist the output includes a cost model built from your measured usage, because that is the piece a board will actually ask about.