The bottom line
A Fabric implementation checklist covers five sequenced phases: before you buy (decision, sponsor, tested source access, named owner, trial-based capacity sizing), before you build (narrow scope, signed metric definitions, data profiling, workspace topology, Git, security), during the build (weekly demos on real data, reconciliation as a deliverable, capacity monitoring, a decision log), before go-live (parallel run, dated retirement, role-based training, support model), and after go-live (adoption by role, 30/90-day gates, capacity review). The three most-skipped checks — tested source access, written metric definitions, and a dated legacy-retirement plan — are the ones that change architecture and cost after the contract is signed.
In This Article
A technically correct build that nobody uses
The pattern I see most often in mid-market manufacturing is not a failed Microsoft Fabric build. It is a technically correct build that nobody uses. That failure is almost never a technology failure — it is a sequencing failure.
A mid-size manufacturer — 200 to 2,000 employees, two to ten plants, one or two ERP instances, an IT team of three to six people and no dedicated data engineer — has very little tolerance for that. There is no bench. This gives the sequence in five phases, each check written so it can be answered yes or no. "Partly" is a no.
What a Fabric implementation checklist should cover
Five sequenced phases: before you buy (decision, sponsor, source access, owner, capacity sizing); before you build (scope, metric definitions, profiling, topology, source control, security); during the build (weekly demos, reconciliation, capacity monitoring, decision log); before go-live (parallel run, retirement plan, training, support model); and after go-live (adoption by role, review gates, capacity review, backlog by impact).
Phase 1 — before you buy
| Check | What happens if you skip it |
|---|---|
| One named decision that will change, in a sentence a plant manager recognises | Scope expands to whatever each stakeholder wants; the build has no acceptance criterion and never finishes |
| An executive sponsor who can settle a definition dispute in one meeting | The dispute goes unresolved, both definitions ship, and the business concludes the platform is unreliable |
| Source access confirmed by a test extract, not an assurance | You discover in week two that the only supported path is a nightly CSV — architecture, timeline and price change after signing |
| A named internal owner with hours in their calendar, not a name on a slide | The partner makes assumptions to keep moving; every assumption becomes a UAT defect landing in the go-live window |
| Capacity sizing tested on the 60-day trial before committing to an F SKU | You size on a guess — undersize and throttle in month two, oversize and carry cost you cannot justify |
| The F64 viewer threshold understood against your reader count | You size on compute alone, then find 300 shop-floor viewers each need a per-user licence below F64 |
On the last two rows, do not take a partner's SKU recommendation on trust — run the workload on the 60-day trial (F4 or F64, up to 1 TB OneLake, Capacity Metrics app included) and read the numbers.
Phase 2 — before you build
| Check | What happens if you skip it |
|---|---|
| First slice scoped to one decision, one process, one or two plants | The programme runs six months with nothing in a user's hands; the sponsor's attention moves on |
| Metric definitions written and signed by production, finance and supply chain | You rebuild the semantic model twice — manufacturing metrics are especially prone to this |
| Source data profiled and defects listed with counts | Defects surface in UAT as "the report is wrong", and trust is lost for problems that live in the ERP |
| Workspace topology across dev, test and production | Development happens in production; the first breaking change is visible to the whole business before testing |
| Git integration connected on day one | No history, no rollback — when a report breaks after a deploy, you cannot answer what changed and when |
| Security model designed before the first table lands | Everyone becomes a Contributor "for now" and Plant B sees Plant A's margin; retrofitting RLS is materially harder |
Governance beyond this — Purview labels, endorsement, domains, retention, audit — is a separate discipline with its own sequence. Do not compress both into one workstream.
Phase 3 — during the build
| Check | What happens if you skip it |
|---|---|
| Weekly demo against real data, never sample data | Everything looks correct until the week before go-live, when real data breaks the model in ways that need redesign |
| Reconciliation to the source named as a deliverable with a numeric tolerance | Go-live becomes an open-ended argument — with no agreed tolerance, any variance is a defect |
| Capacity monitored from week one via the Capacity Metrics app | You learn about throttling when users complain — 20-second delays after 10 minutes of overage, rejection past 60 |
| Refresh schedules tested at production volume and concurrency | The 06:00 refresh completes at 09:30 on the first busy Monday, and the meeting starts with stale data |
| A decision log with date, decision, owner and rationale | Decisions get relitigated — the same conversation, three times, three outcomes |
Phase 4 — before go-live
| Check | What happens if you skip it |
|---|---|
| Parallel run completed and reconciliation signed by finance and operations | The first month is spent proving the platform rather than using it; every variance reopens trust |
| Legacy report retirement date agreed, with a named owner to switch it off | Both systems run indefinitely; cost doubles, adoption stalls, and the old report wins because it is familiar |
| Training delivered by role, on the live report, with the user's own plant data | Adoption concentrates in two or three power users; everyone else asks them for extracts and the spreadsheet layer regrows |
| Support model and refresh-failure escalation defined in writing | A user finds the failed 06:00 refresh at 08:40 — one silent failure costs more confidence than ten known defects |
| Metric definition documentation handed over, in business language | Institutional knowledge leaves with the consultant; the next change request starts with archaeology |
Phase 5 — after go-live
| Check | What happens if you skip it |
|---|---|
| Adoption measured weekly by role, not a headline user count | You report activity as adoption and never notice the intended audience did not come back |
| Formal review gate at 30 and 90 days, with the sponsor present | Small irritations calcify into reasons not to use the report, unheard until renewal |
| Capacity consumption reviewed against the business-case forecast | The first surprise invoice becomes an argument about the whole programme |
| Backlog prioritised by decision impact, sponsor arbitrating | The roadmap fills with cosmetic changes while the second real decision never gets built |
| Ownership of the metric dictionary transferred to a named internal role | Within a year the documentation and the model disagree, and you are back to arguing about numbers |
The three checks that get skipped most — and cost the most
Source access confirmed by test extract — skipped because someone senior says "of course we have access", and it changes the architecture when the only supported path turns out to be a nightly CSV. Metric definitions agreed in writing — skipped because it feels like a workshop that delays the build, and it causes two semantic-model rebuilds. And a dated legacy-retirement plan with a named owner — skipped because it is uncomfortable, meaning telling somebody their report is going away, and it is why two numbers circulate forever.
Each is skipped because it feels administrative. Each is the thing that changes cost or architecture after the contract is signed.
The three cheapest checks to skip are the three most expensive to skip: tested source access, signed metric definitions, and a dated retirement plan with a name against it.
Where this breaks, and what it does not fix
A checklist does not create authority — if the sponsor cannot compel production and finance to agree a definition, no gate will hold. It does not fix ERP data quality — if material master is duplicated across two plants and nobody owns the correction, Fabric presents that inconsistency faster and to more people. Phase gates assume you can hold the line commercially — on a time-and-materials engagement, a partner has limited incentive to stop at a gate.
It will not survive a plant that does not want to be measured — where shift supervisors believe the data judges them, downtime reason codes degrade within weeks. The 60-day trial does not reflect production perfectly — it excludes Copilot, AI functions, Data agent and Private Link, and does not support autoscale. And two to ten plants is not the same problem at both ends — at two you harmonise definitions in a single workshop; at ten it is a programme.
What to do first
Answer these four questions this week, honestly:
- If the platform worked perfectly, which meeting changes, and who chairs it?
- Has anyone extracted a real table from the ERP into a test environment — not viewed it, extracted it?
- Who settles the argument when production and finance disagree on a definition, and do they know they own that?
- What is the date the current report gets switched off, and whose name is against it?
If the second or fourth question has no answer, fix those before any procurement conversation — they are the two that change architecture and cost after a contract is signed. We run exactly this sequence for mid-market industrial businesses, Microsoft-native and practitioner-led, on a fixed-scope first slice with first value in six weeks.
Two checks change your architecture and cost after the contract is signed: has anyone actually extracted a real table from the ERP, and is there a dated retirement plan with a name against it. Get those right first. Book a diagnostic with Amit — no slides, no pitch deck, no obligation to proceed. Bring your current position and we will work out which gate you have skipped.
Free Assessment
Where does your operation sit on the data maturity curve?
8 questions. 3 minutes. You get a scored breakdown across data infrastructure, analytics readiness, and automation potential — with a specific next step for your industry.