A Fabric platform built once, and built to hold

A Fabric implementation builds the platform. OneLake as the storage foundation, the lakehouse and warehouse items on top of it, the medallion layering that structures the data as it moves, Data Factory orchestration to move it on a schedule you can trust, the workspace and capacity topology the whole estate runs inside, and the Dynamics data path wired in on a supported link. It is the foundation the reconciled model and the reports later sit on. It is not the reconciled model, and it is not the reports.

Fabric is a platform decision, not a tool purchase. That is the thing most buyers are not told before they sign. A licence gives you a capacity and a blank tenant. What you do with the next ninety days decides whether you have a platform or a mess.

The failure shape is consistent enough to describe in advance. A team stands Fabric up themselves, or hands it to a generalist who treats Finance and Operations as just another SQL database. Data gets copied instead of shortcut, so the same table now lives in three places. Direct Lake, which is the whole performance argument for Fabric, quietly falls back to DirectQuery because the model no longer meets its conditions. A Spark job someone left running eats the capacity, reports start queueing, and by month three the platform is throttling and the bill is a surprise.

None of that is a Fabric problem. It is an architecture problem, and it is entirely designable away at the start.

A Fabric implementation runs as a phased build: platform architecture and target design, the Dynamics data path decision, OneLake and the medallion layers, orchestration with Data Factory, the workspace and capacity topology, then governance, source control and handover. Each phase lands something you can use, and the scope and the cost are shown before the work starts.

The order matters. Almost every troubled Fabric estate we are called into was built in the wrong order: workloads first, topology last, capacity as an afterthought. This is the order that holds.

1. Platform architecture and target design

   We design the estate before we build any of it. Domains, workspaces, the dev, test and production separation, naming and tenancy, and which Fabric items each workload actually needs. The point of this phase is that nothing later gets bolted on.

2. The Dynamics data path

   We choose between Link to Fabric and Azure Synapse Link deliberately, on your governance posture and how much of the pipeline you want to own, not on whichever one the last consultant defaulted to. Both are supported and both are live. The choice has consequences, and we set them out before you make it.

3. OneLake and the medallion layers

   We structure OneLake as the single storage foundation and lay the bronze, silver and gold layers on it in Delta, using shortcuts rather than copies, so the data has one home and Direct Lake keeps working the way it is supposed to.

4. Orchestration with Data Factory

   We build the pipelines that move and refresh the data: incremental loads on a change-tracking basis rather than full reloads, run logging, failure handling and alerting, so the platform runs to a schedule you can hold a team to.

5. Workspace and capacity topology

   We separate the noisy engineering work from the capacity your reports run on, size and lay out the capacity so it can be paused, resized and monitored, and design the topology knowing exactly which cost levers exist and which do not.

6. Governance, source control and handover

   Git source control on the Fabric items, deployment pipelines across dev, test and production, workspace roles set deliberately, and documentation with a named owner, so the platform is governable and survives the person who built it.

Where speed matters and the scope is tight, a fixed-scope foundation build sits beside the full implementation. Whichever shape fits, the cost is scoped and shown before you commit.

Both are supported, and both are live. Link to Fabric is no-copy and no-ETL, and the data stays inside the Dataverse governance boundary, but every non-system table with Track changes enabled is selected automatically, so you cannot cherry-pick, and it consumes additional Dataverse storage. Azure Synapse Link exports continuously to your own storage account, where you own the pipeline and you can choose which tables come across. The right path depends on your governance posture and how much of the plumbing you want to own.

This is the decision a generalist gets wrong, because they treat it as a connector choice rather than an architectural one. It is architectural. It decides where your data physically sits, who governs it, what it costs to store, and how much of the pipeline you are on the hook for.

Link to Fabric. No copy, no ETL, fully managed. The data stays inside the Dataverse governance boundary and authorised Fabric users query it through OneLake. It is the fastest route to a bronze layer and it removes an entire class of pipeline maintenance. The trade is control: every non-system table with Track changes enabled is auto-selected, so you cannot pick and choose, and it consumes additional Dataverse storage. If your Dataverse storage position is already tight, that matters, and it should be modelled before you switch it on, not after.

Azure Synapse Link for Dataverse. Continuous export into your own storage account, in your subscription, with your own pipelines on top. You choose the tables. You own the pipeline, which means you also own its maintenance. For teams with a real data function, an existing Azure estate, or a governance requirement to hold the data in their own tenant boundary, this is often the better answer, and it is not the legacy option.

If you are still on a legacy pipe, moving off it is its own motion with its own risks, and we treat it as one, on the migration to Microsoft Fabric.

No. The link is transport, not transformation. Neither Link to Fabric nor Azure Synapse Link performs the Finance and Operations engineering that makes the data usable: the financial-dimension work, the RecId relationships, the enum translation. The data arrives, and it arrives with schema changes you have to design around. That engineering is still owed, and the platform has to be built to carry it.

This is the single most expensive misunderstanding in a Fabric project. The link works. The data lands. Someone opens a lakehouse, sees tables with familiar names, and declares the hard part done. It is not done. It has not started.

Here is what actually arrives, and what a platform has to be designed around.

• Reserved words get renamed. Names that collide with SQL reserved words come across altered, so Level arrives as Level_ and Resource arrives as Resource_. Anything downstream that assumed the original name breaks quietly.
• ID is not ID any more. The ID column is renamed to FnO_Id. Every join, every lookup and every piece of documentation written against the old name has to be re-pointed.
• Soft deletes are retained, not removed. Deleted rows do not disappear. They are retained and flagged with isDelete. Fail to filter them and you double-count, and the number that comes out is wrong in a way nobody notices until a board pack.
• Fields are dropped in transit. TZID fields and binary fields do not come across. If a downstream process depended on them, it needs redesigning, not patching.
• Long text gets truncated. nvarchar(max) columns are truncated at 2,000 characters. For most fields that is harmless. For the one field where your team has been storing something important, it is not.
• The tooling exists, and we use it. Microsoft FastTrack ships transition tooling on GitHub for exactly this work. We use it rather than reinventing it, and we test what it produces rather than trusting it blindly.

Handling these is not clever. It is just knowledge, and it is the knowledge a Fabric generalist has never needed and a Dynamics specialist cannot avoid. We have been doing the second thing since 2002.

Where a pre-built, pre-reconciled extraction foundation fits the job better than bespoke engineering, Reveal is our productised option, which reduces implementation time and risk.

Topology is a cost decision as much as an architecture one. Workspaces and domains are laid out so that engineering work cannot throttle the capacity your reports run on, environments are separated so a test job cannot take production down, and the capacity is designed on an F SKU, because the levers that actually control Fabric cost, pause and resume, on-demand resizing and Spark autoscale billing, exist only on F SKUs.

Fabric is sold as software as a service and it bills like a platform. That is the whole of the cost problem in one sentence. The capacity is a shared pool, and anything running inside it competes for the same compute, which means a badly placed Spark job is not just slow, it is a bill and an outage at the same time.

So the topology carries the cost design. Engineering workloads sit apart from the workspaces that serve reports. Development and test are separated from production so an experiment cannot throttle the month-end close. Capacity is sized against real workload evidence, not a guess, and laid out so it can be paused when nothing is running and resized when something is.

This is also where the SKU decision stops being a licensing detail and becomes an architecture one. Pause and resume, on-demand resizing and Spark autoscale billing are F-SKU features. They are not available on P. If your capacity cannot be paused or resized, the cost-control conversation is over before it starts, and no amount of monitoring will fix it. F64 is also the threshold at which your viewers can consume Power BI content on a free licence, and below it every viewer needs their own Pro licence, which is a real number in an organisation with a wide report audience and it belongs in the design, not in a surprise invoice.

Designing the topology is one thing. Policing it every month is another, and it is a run-state job, which is what the managed Fabric platform exists to do.

A Fabric implementation delivers a designed platform: a OneLake foundation with the medallion layers laid on it, the lakehouse and warehouse items your workloads need, the Dynamics data path wired in on a supported link with the Finance and Operations schema realities handled, Data Factory orchestration with incremental load and run logging, a workspace and capacity topology designed to be governed and paused, and a documented, source-controlled handover to a platform you own.

Here is the whole of it, so there is no question about what lands.

• A designed platform, not a pile of workspaces. Domains, workspaces, environments and item types laid out deliberately, with dev, test and production separated, so the estate has a shape someone can still reason about in two years.
• OneLake and the medallion layers. A single storage foundation with bronze, silver and gold laid on it in Delta, using shortcuts rather than copies, so the data has one home and Direct Lake keeps its performance guarantees.
• The Dynamics data path, wired in correctly. Link to Fabric or Azure Synapse Link, chosen on the evidence, with the Finance and Operations schema realities handled rather than discovered later.
• Orchestration you can trust. Data Factory pipelines with incremental, change-tracked loads rather than full reloads, run logging, failure handling and alerting, so the platform runs to a schedule.
• A capacity and workspace topology designed for cost. Engineering separated from serving, capacity sized on evidence and laid out so it can be paused, resized and monitored, with the SKU consequences understood up front.
• Governance, source control and a documented handover. Git on the Fabric items, deployment pipelines across environments, workspace roles set deliberately, and a named owner, so the platform is governable and does not depend on the person who built it.

The build is the middle rung. A readiness assessment comes first, so the platform is designed against evidence rather than assumption. The build stands the platform up. The managed platform service can follow, so the capacity is policed month after month rather than left to drift. You choose each rung on the evidence, with no obligation to take the next one.

Three rungs. You choose each one on what the last one showed you.

1. Diagnose first.

   If you have not yet established what your estate can actually support, start with the Fabric readiness assessment. It produces the evidence the build is designed against.

2. Build.

   This page: the platform foundation, designed and stood up once, phased so each stage lands something usable.

3. Then run it.

   A platform nobody polices drifts, and the first symptom is the bill. When it is live, hand the run-state to the managed Fabric platform.

If a Fabric implementation is one part of a wider Dynamics data programme, the programme wrapper sits at Microsoft Fabric for Dynamics 365.