Four weeks to establish, ten to sixteen to build. What a Fabric implementation really looks like, the five things that derail it, and what to decide first.
A Microsoft Fabric implementation for a mid-market business takes about four months: a four-week Establish phase to agree scope, sources, definitions and the platform pattern, then ten to sixteen weeks to build the ingestion, lakehouse, semantic model and first reports, with adoption running alongside the last few weeks. A single-source proof of concept takes two to four weeks. A multi-entity group with a dozen systems and a migration from an existing warehouse takes six to nine months. Those are the ranges we see across our own delivery, and the spread is explained less by the technology than by five things that go wrong, every one of which can be decided before the first pipeline is built. This post sets out the timeline, the failure points and the decisions.
The timeline
Weeks one to four, Establish. This is where the business decides what it is building. The outputs are a list of in-scope sources with owners, a definitions document that finance has signed (what counts as revenue and when, how margin is calculated, the ageing buckets, the dimensions that matter), a capacity size, a workspace and security design, and a backlog of reports in priority order. It also includes the tenant settings, policies and gateways, which our Fabric policies post covers, so that the build phase starts on a configured platform rather than a blank tenant.
Weeks five to eight, foundation and ingestion. The lakehouse is created with its bronze, silver and gold layers, source control and deployment pipelines are set up, and the first sources are ingested through mirroring, shortcuts or pipelines. The first source is usually the ERP, and by the end of this stage its ledger, customers, items and dimensions are in silver with checks running.
Weeks nine to fourteen, model and reports. Gold tables are built to the agreed definitions, the semantic model is created over them with Direct Lake, and the priority reports are built and tested with the people who will use them. This is also where the second and third sources arrive and are conformed to the first.
Weeks fifteen to twenty, hardening and adoption. Monitoring and alerting are completed, the capacity is tuned, training runs, the old reports are retired and the finance team closes a month end on the new platform with the old one still available. The implementation is finished when they do not go back.
What goes wrong
Definitions were never agreed. The most common cause of a Fabric project running long is a gold layer built to definitions that finance then disputes. The model is technically correct and commercially unusable, and the rework is measured in weeks. The cure is the Establish phase, and specifically a signed definitions document before any gold table exists.
The capacity was sized by guesswork. Both directions fail. An F2 bought to save money throttles on the first Direct Lake query from twenty users and the platform acquires a reputation for being slow; an F64 bought to be safe costs £4,400 a month for a workload that needed an F8. The capacity metrics app, a week of representative load and the capacity guide answer the question in a day.
Workspaces sprawled. Fabric makes it easy to create workspaces, and a tenant with no naming standard, no ownership rule and no policy on who can create what ends up with fifty of them inside a year, each with its own copy of the ledger. The Fabric rollout that quietly goes wrong describes this and the readiness checks that prevent it.
The migration was treated as a lift and shift. Existing Data Factory pipelines, Synapse SQL and Power BI import models do not move unchanged. Mapping data flows become Dataflow Gen2, datasets and linked services become connections, import models become Direct Lake models with different modelling rules, and the time to do that properly is a build phase, not a weekend. Azure Data Factory vs Fabric pipelines sets out what changes.
Nobody owned adoption. A platform that is delivered and not used has cost everything and returned nothing. Adoption needs a named owner in the business, training that is built around the reports people will actually open, and the old reports switched off on a date. We treat the month end closed on the new platform as the acceptance test, not the final pipeline run.
What to decide before you start
Five decisions, in order. Which systems are in scope for the first release, and which are explicitly not. Who signs the definitions, and by when. Which capacity, and whether it is reserved. How workspaces are named, owned and created, and who can create them. Who owns adoption, and what date the old reports are retired. A business that can answer those five in a workshop is ready to implement; one that cannot should spend the Establish phase answering them, because the alternative is answering them during the build at ten times the cost. How to choose a Microsoft Fabric consultancy sets out what to expect a partner to bring to that conversation, and our Microsoft Fabric page describes how we run it.
Related reading
The Fabric rollout that quietly goes wrong: workspace sprawl, shadow BI and the readiness checks
Microsoft Fabric policies explained: tenant and capacity rules, allow lists and what to set up first
How to choose a Microsoft Fabric consultancy in the UK after FabCon Europe 2026
Shauna Duffy
Director of Professional Services
Part of the Hopton Analytics team, delivering governed analytics programmes for UK mid-market organisations.
