A Practitioner's Microsoft Fabric Adoption Roadmap, Quarter by Quarter

Most Fabric rollouts I get called into failed the same way: someone lit up a capacity, migrated forty reports in a weekend, and then spent six months explaining why the numbers did not tie out. The platform was never the problem. The sequence was. What follows is a quarter-by-quarter roadmap with deliverables you can name, owners you can hold accountable, and exit criteria that either pass or do not. If a quarter fails its exit criteria, you do not roll into the next one. You stop, fix, or kill.

How to read this roadmap

Four quarters, four themes, four exit gates. Each quarter has a headline deliverable, a named owner role (not a person, a role you must fill), and a short list of exit criteria. The point of the exit criteria is that they are binary. "Adoption is improving" is not an exit criterion. "The finance subject area reconciles to the general ledger within 0.5 percent for three consecutive month-ends" is. If you cannot phrase your gate as a pass or fail, you have not defined it yet.

I use role names throughout: Programme Lead owns the business case and the gates. Data Platform Lead owns the Fabric tenant, capacity, and workspaces. Domain Analyst owns a single subject area and its semantic model. Data Governance Lead owns naming, lineage, and access. FinOps Analyst owns capacity cost. On a mid-size programme one person often wears two of these hats; the roles still need explicit owners.

Q1: one high-value subject area, end to end, on a trial capacity

The mistake is to start with infrastructure. The right start is to prove one subject area of genuine business value from raw source to a semantic model that a decision-maker actually trusts, running on a trial or lowest-tier capacity so you spend almost nothing while you learn. Do not migrate. Build one thing well.

Named deliverables:

• A single high-value subject area (finance close, or maintenance backlog, or sales pipeline) modelled from source to a certified semantic model.
• A medallion structure (bronze, silver, gold) in one workspace, so the pattern is proven before it is copied.
• One certified Power BI report on top of that gold layer, reconciled to the system of record.
• A written "definition of done" for a subject area that the next domain will reuse.

Owner:

Domain Analyst builds; Data Platform Lead sets up the trial capacity and workspace; Programme Lead owns the gate.

Exit criteria (all must pass):

• The gold layer reconciles to the source system within an agreed tolerance for at least one full period close.
• A named business owner signs the report as their new source of truth, not a parallel check against the old one.
• Trial capacity consumption is measured and extrapolated to a production SKU estimate.
• The medallion pattern and naming are documented well enough that a second analyst could copy them without you.

If reconciliation is the gate for something like a Business Central financial subject area, the mechanics of getting clean data out of BC into a semantic model are worth their own read: see my notes on Business Central and Power BI.

Q2: governance and the first migration wave

Only after one subject area works do you turn on the machinery that lets you scale without chaos. Q2 is governance plus the first real migration wave, moving a defined batch of existing reports and datasets onto the pattern you proved in Q1. Governance first, then wave. Not the other way around.

Named deliverables:

• A domain and workspace topology, with naming standards, sensitivity labels, and endorsement (certified vs promoted) rules written down.
• A conformed master data layer (the asset, customer, or account master from Q1) published as shared, certified items.
• Wave one: a named list of 10 to 20 reports migrated onto the medallion pattern and retired from the old platform.
• Access model in place: security groups mapped to workspace roles, row-level security where the subject area needs it.

Owner:

Data Governance Lead owns naming, labels, and access; Data Platform Lead owns the topology and the migration factory; Domain Analysts do the per-report work.

Exit criteria (all must pass):

• Every wave-one report reads from the conformed master, not a private copy of the dimension.
• Cross-system reports reconcile, because the master is shared. This is only possible if the master shipped first.
• The old versions of wave-one reports are switched off, not left running "just in case".
• An access review confirms no workspace grants "everyone" edit rights.

Migration waves are integration projects wearing a reporting costume. If you are pulling from ERP, EAM, and CAFM into one gold layer, the patterns and traps are the same ones I cover in the enterprise system integrations guide.

Q3: telemetry or a second domain, plus cost controls

By Q3 the platform is real and someone is starting to ask what it costs. This quarter you widen scope, either a second business domain or an operational telemetry stream, while simultaneously putting cost controls in place. Widen and constrain at the same time, because unconstrained capacity growth is how Fabric programmes get killed by their own CFO.

Named deliverables:

• A second subject area (a new domain) or an event/telemetry pipeline, built on the proven pattern.
• Capacity monitoring: the Fabric Capacity Metrics app (or its successor) deployed, with alerts on smoothing and throttling.
• A chargeback or showback view so each domain sees its own consumption.
• A documented policy for when to scale a capacity up, when to add a second, and when to pause dev capacities.

Owner:

FinOps Analyst owns monitoring and chargeback; Data Platform Lead owns capacity sizing; the relevant Domain Analyst owns the new domain.

Exit criteria (all must pass):

• Capacity monitoring is live and has produced at least one real throttling alert that was acted on.
• Every domain can see its own consumption and the number is trusted.
• The second domain passed the same Q1-style reconciliation gate before it went certified.
• A scale-up decision was made using the metrics app, not a gut feel.

Note the dependency: you cannot responsibly run wave two of migration or add a heavy telemetry workload until capacity monitoring exists. Turning on more load blind is the fastest way to a throttled tenant and a room full of angry report users. The specific app name and metrics change; confirm the current tooling in the Fabric documentation before you rely on it.

Q4: decommissioning the legacy estate

A migration that never retires the old estate is not a migration, it is a second system you now pay for twice. Q4 is where you earn the business case: shut down the legacy reporting platform, retire the old gateways, and stop the double-running cost. This is the quarter everyone underestimates, because switching things off is politically harder than turning things on.

Named deliverables:

• A decommission register: every legacy report, dataset, and gateway, with a re-point-or-retire decision against each.
• All remaining in-scope reports migrated or formally deprecated with sign-off.
• On-prem sources re-pointed to their Fabric equivalents; only then are the old gateways retired.
• The legacy platform contract flagged for non-renewal, with the saving booked into the benefits tracker.

Owner:

Programme Lead owns the retirement decisions and the contract; Data Platform Lead owns the gateway and source re-pointing.

Exit criteria (all must pass):

• Zero business-critical reports remain on the legacy platform.
• Every on-prem source is re-pointed and verified before any gateway is switched off.
• The double-running period has a defined end date that has actually arrived.
• The legacy licence or contract is confirmed cancelled or non-renewed, and the saving is in writing.

The dependency map people trip over

Below is the roadmap as a Gantt-style view. The bars show roughly when work runs; the notes column carries the dependencies that sink programmes when ignored. Read the notes column more carefully than the bars.

The three that catch everyone: conformed master before any cross-system report, capacity monitoring before wave two, and gateway retirement only after every on-prem source is re-pointed. Break any one of those and you spend a quarter unpicking it.

Staffing, day rates, and the cost curve nobody budgets

Here is a realistic staffing model for a mid-size programme. Day rates are broad market ranges and vary heavily by region, so treat them as directional and price against your own market. The honest split I see is roughly 60 percent internal effort to 40 percent external at the start, shifting toward 75 internal to 25 external by Q4 as your own people take ownership. If an integrator quotes you 90 percent external for the full year, they are building a dependency, not a capability.

Now the part that gets left out of the business case. During Q4 you are still paying for the legacy platform while the Fabric capacity is already in production. That overlap is the double-running period, and it is a real, budgetable cost that too many plans pretend does not exist. Model it explicitly.

The curve goes up before it comes down. Q3 is the peak, when both platforms run at full tilt. If your business case shows costs falling from month one, it is wrong, and the first CFO who spots it will lose trust in the whole programme. Show the hump honestly and the year-two saving lands as credible. Fabric capacity pricing and F-SKU definitions change frequently, so re-cost this table each quarter against the current Microsoft Fabric pricing.

Kill criteria: three signals that should stop this at the end of Q1

A good roadmap includes permission to stop. If Q1 shows any of these three signals, do not roll into Q2. The cost of stopping after one quarter on a trial capacity is trivial compared to the cost of discovering the same problem in Q4 with the legacy platform already switched off.

1. The number will not reconcile. If one subject area cannot be made to tie out to the source system within tolerance in a full quarter, the problem is your source data quality, not Fabric. Fix the source, or the whole programme inherits the mess at scale.
2. No business owner will sign. If, after a working certified report, no decision-maker will adopt it as their source of truth and keeps running the old report in parallel, you have a trust or change problem that more technology will not solve.
3. The extrapolated capacity cost breaks the business case. If Q1 consumption, scaled to full production, lands far above the SKU you budgeted, stop and re-cost before you migrate anything. Discovering this in Q3 at peak double-running is the expensive way to learn it.

Two or more of these together is a clear kill. One on its own is a hold: fix the root cause and re-run the Q1 gate before proceeding. Killing at the end of Q1 is a success of the process, not a failure of it.

Benefits tracking that makes the year-two renewal a formality

The renewal conversation is won or lost by whether you tracked benefits from day one. Set up this tracker in Q1, populate it every quarter, and by the time renewal comes around the numbers make the decision for you. Baselines are captured before you change anything; if you wait until Q4 to measure the "before", you have no before.

When the year-two renewal meeting happens, you are not arguing that Fabric is good. You are showing a table where the baselines were captured before the work and the targets were met. That turns a debate into a formality.

A note on independence

I do not resell Microsoft licences and I am not paid to recommend Fabric over any alternative. This roadmap reflects my own delivery experience across ERP, EAM, and reporting platforms, nothing more. Microsoft Fabric changes fast: SKUs, preview features, and capacity behaviour that are current today may be renamed or repriced within a quarter. Verify every specific claim against Microsoft's own current documentation before you spend money, and recheck at least once a quarter for the life of the programme.

Conclusion

A Fabric adoption is not a maturity curve you drift along. It is four quarters with gates you either pass or fail: prove one subject area, govern and migrate the first wave, widen scope while you get costs under control, then decommission the old estate and book the saving. Respect the dependencies, budget the double-running hump honestly, keep the kill criteria in reach, and track benefits from the first week. Do that and the platform becomes an asset your CFO defends, not a line item they interrogate.