A six-week Fabric implementation plan does not deliver a migrated data estate. It delivers a platform that is correctly built, and one data product running in production on it. Anyone promising the first thing in six weeks is describing a different project, and anyone dismissing the second as trivial has not tried to get a single report into production through a governance process.
So the useful question is not whether Fabric can be implemented in six weeks. It is what has to be true on day one for six weeks to be enough, and which decisions taken in week one cannot be undone in week seven.
Week zero is not a data task
The commonest cause of a week-one slip has nothing to do with data. It is access, and it sits with people who are not in the project.
Three things have to exist before anyone opens Fabric:
- An Azure subscription in the right tenant, with the Fabric resource provider registered and enough capacity quota in the region you intend to use. Quota is per subscription and per region, and requesting more is a support process with its own clock.
- A tenant setting switched on. If “Users can create Fabric items” is off, nothing happens, and it is a Fabric administrator’s switch rather than a project decision.
- A named capacity administrator who is not a guest. A B2B guest account cannot hold the role, which surprises organisations running a consultancy through guest access.
None of this is difficult. All of it is somebody else’s queue, which is why it belongs in week zero rather than week one.
Capacity: what to buy, and the one threshold that matters
Fabric capacity is bought in the Azure portal as an F SKU, from F2 upward, pay as you go by default and pausable. For a first implementation the sizing question matters far less than one licensing threshold.
F64 is the line. At F64 and above, a user with a free Fabric licence and the Viewer role can consume Power BI content. Below F64, every viewer needs a Pro or Premium Per User licence. That means a small capacity can be the more expensive option once a read-only audience is counted, and it is a decision about your audience rather than your data volumes.
Two practical notes. Scaling up to F64 is quick in compute terms, but Microsoft states the licence change usually takes up to a day to take effect, and during that window free users may be prompted to upgrade. Do not plan a go-live for the morning after a scale-up. And pausing a capacity does stop billing, but it also sums any outstanding smoothed operations and overages onto the bill at the moment you pause, so an overnight pause during a heavy load window is not the saving it appears to be.
The trial is worth knowing precisely, because it is usually described loosely. It runs 60 days, stores up to 1 TB in OneLake, and Microsoft states that it is “configured as either an F4 capacity (4 capacity units) or an F64 capacity (64 capacity units)” without publishing the rule that decides which you get. Nor is it the full product: Copilot and Trusted Workspace Access are not supported, and neither are the AI experiences such as data agents and AI functions. In the estates we have delivered the trial has arrived as an F64, which is the common experience and probably why the F4 case is so rarely mentioned. Plan for either. It is genuinely useful for proving a pipeline, and it is not a production platform.
For how to size the capacity properly once you are running, and how to charge it back to the business units consuming it, we wrote that up separately in Fabric capacity planning and chargeback.
The decisions that are hard to reverse
Three choices made casually in week one are expensive to change later.
Region is effectively permanent. Only seven item types can be moved between regions: report, semantic model in small storage format, dashboard, Dataflow Gen1, paginated report, datamart and scorecard. Everything else, which is to say the lakehouse, the warehouse, the notebook, the pipeline and the eventhouse, cannot move. In practice a region change means rebuilding. Choose it against data residency and against where your source systems actually sit, in week zero, in writing.
Domains do not control access. This one catches nearly everyone. A domain is a way of organising and discovering data, not a security boundary. Domain assignment does not affect whether an item is visible or accessible, that depends on workspace role and item permissions, and every user in the tenant can see every domain that exists. An implementation that puts finance data in a Finance domain and believes it has restricted it has restricted nothing. Access is a workspace design question, and it should be settled before data lands.
Workspace shape outlives the project. Workspaces are where capacity assignment, access and the deployment path all attach. Splitting them later means moving items, reassigning permissions and rebuilding pipelines, so the medium-effort hour spent drawing this in week one is the highest-return hour in the engagement.
What should actually be in production at week six
A defensible six-week fabric implementation plan has four parts at the end of it:
- A platform that somebody owns. Capacity bought and assigned, workspaces created with roles, region fixed, tenant settings agreed, an administrator named on each.
- One data product end to end. One source, ingested on a schedule, landed in OneLake, modelled, and surfaced in a report a real user opens on purpose. One, not five.
- A path to change it safely. Git integration connected and deployment pipelines stood up between development, test and production. Retrofitting this after a dozen items exist is materially harder than starting with it.
- A written decision log. Region, domain model, workspace structure, capacity size and the reason for each. In our experience this is the artefact that survives longest and is most often missing.
In our engagements so far, three Fabric foundations, the first report has been live in production inside a month. That is not a promise, and three is a small number to generalise from. It does say something about where the time goes: the report is rarely the slow part. What fills the remaining weeks is the change path and the decisions nobody writes down.
What should not be in there: a migrated warehouse, an estate-wide governance model, or a backlog of reports rebuilt from an old platform. If you are moving off Synapse, that is a programme rather than a foundation, and we have written about what actually moves. If Power BI Premium is involved, its P SKU retirement sets your timeline rather than your preferences.
Our position: one workload in production beats a complete platform
In our view the first six weeks should end with one workload live and a deliberately unfinished platform, rather than a complete platform and nothing running on it.
The argument is not about speed. A platform with no production workload has never been tested against the things that actually break an implementation: refresh windows that collide with a close, a source system that rate-limits, a security model that nobody can administer, a report owner who wanted a different grain. Those surface only under real use, and finding them in week five with one workload is cheap. Finding them in month four, after eight workloads were built on the same assumptions, is not.
The corollary is that we would rather cut scope than cut the production step. A six-week engagement that delivers three half-finished data products and nothing a user depends on has bought you a demonstration, not a platform.
Where to start
Four things, before week one:
- Confirm the Azure subscription, the resource provider and the quota in the region you want, and find out who owns that subscription.
- Get the tenant settings decided, particularly who may create Fabric items.
- Choose the region deliberately, knowing it cannot practically be changed.
- Name the first workload, and name the person who will be annoyed if it stops working. If nobody is, choose a different first workload.
Veratas delivers Fabric foundations as a fixed-scope implementation, with the decisions above made in week zero rather than discovered in week three. If you want a second opinion on a plan you already have, talk to our team.
Frequently asked questions
How long does a Fabric implementation take? A foundation with one workload in production is realistic in about six weeks, provided the Azure subscription, quota and tenant settings are in place before the start. A migration off an existing platform is a separate programme and should be planned as one.
Is the Fabric trial enough to start with? For proving a pipeline, often yes. It runs 60 days, stores up to 1 TB in OneLake, and does not include Copilot, Trusted Workspace Access or the AI experiences. Microsoft provisions it as either an F4 or an F64 and does not publish which you will get, so a fabric implementation plan that assumes the larger one is carrying a risk it does not need to. Ours have come through as F64, but that is experience rather than entitlement.
Which Fabric capacity should we buy first? The answer usually turns on your read-only audience rather than your data. At F64 and above, free users with the Viewer role can consume Power BI content; below F64 every viewer needs Pro or Premium Per User, which can cost more than the larger capacity.
Can we change the Fabric region later? Practically, no. Only seven item types can move between regions, and lakehouses, warehouses, notebooks, pipelines and eventhouses are not among them. Treat the region as a permanent decision.
Do Fabric domains control who sees what? No. Domains organise and help people discover data. Access is governed by workspace roles and item permissions, and every user in the tenant can see every domain. Designing security around domains is the most common early mistake we correct.
Should Git and deployment pipelines be set up at the start? Yes. Connecting them once a dozen items exist is significantly more work than starting with them, and without them there is no safe way to change anything that is already live.
Azure and Business Intelligence Architect with 17+ years of experience delivering cloud data and analytics solutions. Focus areas include Azure data platforms, ETL and ELT architecture, and enterprise BI on Microsoft Azure.