The platform under Dynamics 365, built to stay predictable

Microsoft Fabric is the platform your Dynamics data lands on, is stored in, is secured in and is billed for. It is not the reconciled model, and it is not the report. Those are two separate jobs that sit on top of it, and confusing the three is the most common reason a Fabric rollout costs more and delivers less than the business was promised.

Three layers, in the order they stack.

The platform. Fabric itself: OneLake, the capacity you buy it on, the Spark and SQL engines running against it, the workspace and security boundary around it, and the meter that ticks the whole time. That is this page, and it is where the platform risk and the operating cost live.

The model layer. Where Dynamics data is conformed, consolidated across legal entities and instances, and made to reconcile. That is the reconciled model layer that sits on the platform, and it is a separate discipline with its own programme.

The reporting layer. What the business actually looks at, and what everyone judges the whole estate by. That is the reporting on top.

Get the platform wrong and the two layers above it inherit the damage: throttled capacity exactly when the month-end refresh matters most, a security model that hands data to people it should not, and a bill nobody in the building can explain. Get it right and the other two become ordinary delivery work.

Two things have changed, and neither is optional. Export to Data Lake, the pipe a great deal of Dynamics reporting was built on, has been retired by Microsoft. And P SKUs, the capacity Power BI Premium was sold on, can no longer be bought: they can only be renewed, and at your renewal you convert to an F SKU or you lose the capability. There is no market-wide cliff. There is a date in your own contract.

The dead pipe first. Export to Data Lake for finance and operations apps has been retired: deprecated in late 2024, with decommissioning from early 2025. If your reporting still refreshes from it, you are already standing on ground Microsoft has left.

The supported paths are Link to Fabric and Azure Synapse Link, and Microsoft has been explicit that both stay. Its stated position is that customers who want to keep exporting data and running their own pipelines will be able to do so well into the future. If a supplier tells you the second of those two paths is on its way out, they are selling you something. It is not.

Then the licence. P SKUs are renew-only and the family is being withdrawn. Microsoft's own guidance is that no immediate action is required and you can continue on your existing Premium capacity until your next renewal, at which point you move to an F SKU. That is the honest urgency, and it is better than a manufactured one: it is account-specific, it lands on your renewal date, and nobody else can tell you when that is.

One thing worth knowing before the renewal arrives. If a Premium subscription is allowed to lapse, Microsoft gives 90 days of full access to migrate. After that, content reverts to shared capacity, where large models and Premium-rendered reports simply stop working. That is not a conversation you want to be having in week eleven.

There are two supported ways to get Dynamics 365 data into Fabric and they are not interchangeable. 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 and you cannot cherry-pick. Azure Synapse Link exports continuously into storage you own, where you choose the tables and carry the pipelines yourself. The right answer depends on your governance posture and your storage economics, not on which one is newer.

• Link to Fabric No copy, no ETL, straight into Fabric. The data never leaves the Dataverse governance boundary, which is the point of it. The trade: all non-system tables with track changes enabled are selected automatically, you cannot pick and choose, and it consumes additional Dataverse storage.
• Azure Synapse Link Continuous export into a storage account you own. Administrators choose the required tables, you manage the access, and you carry the storage, the compute and the pipelines. More control, more to run, and fully supported.
• What neither of them does Neither path reconciles anything. They move rows. Financial dimensions, intercompany, entity structures and the consolidated group view are modelling work, and that work happens after the data has landed. A platform project that assumes otherwise is already late.
• The finance and operations schema tax Reserved words are renamed (Level_, Resource_). ID becomes FnO_Id. Deleted rows are retained and flagged with isDelete, so a naive count includes them. TZID and binary fields are dropped. And nvarchar(max) is truncated at 2,000 characters. Each of those quietly breaks something downstream.

This is where generalist data shops come unstuck on Dynamics. They treat finance and operations as another SQL database, wire the pipe, declare the platform done, and hand you a lake full of rows that will not agree with the ERP. Microsoft ships transition tooling on GitHub through FastTrack, which helps, but tooling does not know your chart of accounts.

Where a pre-built extraction route is the better call, Reveal, our own Dynamics extraction and connector product, is weighed against a bespoke build rather than assumed. Which one fits is an evidence question, and the assessment answers it.

Fabric charges for capacity, not for users, and capacity is consumed by whatever runs against it. One badly written Direct Lake query or one oversized Spark cluster can throttle a whole tenant and burn a month of budget over a weekend. The levers that actually control that cost, pausing, resizing on demand and Spark autoscale billing, exist only on F SKUs. That is the strongest reason to move, and it comes straight off Microsoft's own feature matrix rather than anyone's benchmark.

For the IT Director, this is platform risk. Capacity is shared. A data engineer testing a notebook and a finance director refreshing the month-end pack are drawing on the same pool, and Fabric will let the first one starve the second without asking anybody's permission. Throttling is not a warning. It is what happens.

For the Finance Director, it is an operating-cost problem, and a nastier one than it looks, because the consumption is invisible until the invoice explains it after the fact. Cost predictability is not a nice-to-have on this platform. It is the reason to have a professional on it.

The F SKU is where the controls live. Pause and resume, on-demand resizing and Spark autoscale billing are F-only and are not available on P. So is trusted workspace access, and so are managed private endpoints, customer-managed keys and workspace-level private links, which is the list your security review will ask for by name.

One threshold is worth planning around before you size anything. At F64 and above, people can view Power BI content on a free Fabric licence. Below F64, every viewer needs a Pro licence. That single line moves the total cost of a Fabric estate more than most architecture decisions do, and it has to be modelled against your real viewer count rather than guessed at.

We publish no capacity figure on this page, because a number that is not built on your workload, your refresh pattern and your viewer count is a guess dressed up as a quote. We will build you the real one.

A Fabric programme for a Dynamics estate runs in five steps, each of which can be funded on its own: assess readiness, migrate off the legacy pipe, build the architecture, run the platform as a managed service, and govern it. Most organisations enter at readiness or at migration, because those are the two with a date attached.

1. Assess the readiness.

   Fabric readiness and strategy is the diagnose step, and it is where nearly everyone should start. It names your current data path, your SKU and renewal position, the workloads that will actually land on the capacity, and the gap between what you have and what Fabric expects. You finish it knowing the shape and the cost of the move before you commit to it.

2. Migrate off the ground that has gone.

   Migration to Microsoft Fabric is the door most clients come through, because the legacy export pipe has been retired and the renewal is coming. The discipline here is not to lift and shift the same unreconciled extract onto a newer pipe. The move you have to make anyway is the moment to put the platform in properly.

3. Build the architecture.

   Fabric architecture and implementation is the build: the workspace and capacity design, the medallion layout in OneLake, the Dynamics data path chosen deliberately, the security boundary, and the finance and operations schema realities handled rather than discovered in production.

4. Run it, and police the capacity.

   Managed Fabric platform and FinOps is where the value concentrates. Monitoring, capacity management, cost control, hypercare, and a named owner for the platform. You are not paying us to build pipelines. You are paying us to police the capacity, so that the bill and the performance both hold.

5. Govern it, across the whole estate.

   Fabric governance and security is the cross-cutting layer: OneLake Security, the access model, lineage, sensitivity and the audit trail. It is the step organisations skip, and the one they most regret skipping.

Each step stands on its own, and where you enter depends on how much ground has already moved under you. That is exactly what the readiness assessment tells you. The full set sits under the Microsoft Fabric pillar.

OneLake Security lets you define table, folder, row and column level access once and have it enforced across every Fabric engine, which is genuinely good and genuinely new. It also has four behaviours that will hand your data to the wrong people if nobody reads the documentation, and none of them is obvious from the admin screen.

• Admins, Members and Contributors bypass it Row-level and column-level security constrain Viewers. Workspace Admin, Member and Contributor roles bypass RLS and CLS entirely. If your finance workspace has generous contributor membership, your row filters are decoration.
• You cannot combine a row rule with a column rule Give a user one role carrying RLS and another carrying CLS and the query errors. The access model has to be designed as a whole, not accreted role by role as people ask for things.
• Filtering is Delta-only Non-Delta objects are not filtered, they are blocked. Which is the safer failure mode, and also means an unplanned rollout will cut access to things people were quietly relying on.
• DefaultReader is doing more than you think The DefaultReader role grants data access to anyone holding ReadAll. If you do not remove users from it, they keep full access no matter what you configure above them. Supported items are still a limited set, so scope matters too.

None of this is a criticism of Fabric. It is what a real security model looks like when somebody actually implements one, and it is the difference between a platform that passes an audit and a platform that only looks like it would. It is a design job, done once, at the start. Fabric governance and security is where that work lives.