What the Power BI PBIR Format Means for Dynamics 365 Reporting Teams

A solution architect reviewing a code diff and a business analytics dashboard on dual monitors in a modern office

A finance reporting team running Power BI over Dynamics 365 Finance and Operations data has a familiar problem: exactly one person can safely have the working capital dashboard open at a time. Everyone else waits, or worse, someone opens the file anyway, makes a change, saves over a colleague’s unsaved edits, and nobody finds out until a client asks why a visual disappeared. That is not a hypothetical. It is how nearly every Power BI report built on top of Dynamics 365 or Dataverse data has been managed since the tool existed, because a .pbix file is a single binary blob. There is no diff, no merge, no pull request, just a file lock enforced by social convention. The Power BI PBIR format changes that mechanic directly, and as of May 2026 it became the default way Power BI Desktop saves new reports, which makes this less a curiosity for early adopters and more a decision every Dynamics 365 reporting practice needs to make on purpose.

PBIR stands for Power BI enhanced report format, and it replaces the older single-file report.json approach (itself an earlier attempt at the same problem, now referred to as PBIR-Legacy) with a folder of small, human-readable JSON files. Microsoft first shipped it as a Desktop developer mode preview several years ago, but the May 2026 update made it the default for both new PBIX files and PBIP projects, meaning teams that never opted into the preview are now creating PBIR reports without necessarily realizing the storage model underneath them has changed.

What the Power BI PBIR Format Actually Changes on Disk

Open a PBIR report’s project folder and you will find a definition directory containing a pages subfolder, a bookmarks subfolder, a report.json for report-level settings, and a version.json that records which format version the report requires. Inside pages, each report page gets its own folder with a page.json and a visuals subfolder, and inside that, every single visual on the page gets its own visual.json file describing its position, formatting, and query. A bookmark becomes its own file too. This sounds like a lot of small files for what used to be one, and it is, but that granularity is the entire point: a change to one chart’s conditional formatting now shows up as a one-file diff instead of an unreadable delta buried inside a compressed binary.

Each of these JSON files declares a public schema URL at the top, and Microsoft has published those schemas on GitHub, which means a report can be opened, validated, and even edited in VS Code with real IntelliSense rather than guesswork. Objects get 20-character generated identifiers by default (something like 90c2e07d8e84e7d5c026), which is ugly to read in a diff but can be renamed to something meaningful through Power BI Desktop, with the caveat that renaming requires restarting Desktop for the change to stick. There is also a lesser-known annotations feature: name-value pairs that Power BI itself ignores completely but that a deployment script can read, which turns out to be useful for marking which page should be the default landing page in a given environment or flagging a visual for environment-specific suppression.

Abstract illustration of branching and merging version control lines connecting to report dashboard blocks

The Git Workflow This Finally Enables

None of the file structure matters much without source control actually using it, and this is where the practical shift happens. A pull request against a PBIR report can now show a reviewer exactly which visual changed and how, the same way a code review shows a diff of a function. Two developers working on different pages of the same report can genuinely work in parallel and merge without one silently overwriting the other, something that was structurally impossible with a monolithic .pbix. Fabric’s own Git integration, which connects a workspace to Azure DevOps or GitHub, extends this further by tracking reports and semantic models at the workspace level and preserving folder structure in the repository, though it is worth being precise here: the file format reaching general availability in Desktop and Fabric’s Git integration support for report and semantic model items reaching full production maturity are two different milestones, and as of this writing the latter is still documented as preview for several connection scenarios, including reports tied to Analysis Services live connections.

A report’s connection to its semantic model is itself stored declaratively, through either a byPath reference that opens the model in full edit mode alongside the report, or a byConnection reference that opens the report in live connect mode with only report-level measures editable. Which one a team chooses affects how much of the semantic model layer gets included in the same Git history as the report, and it is worth deciding deliberately rather than by whatever Power BI Desktop defaulted to on first save.

Why This Matters More for Dynamics 365 Reporting Portfolios

Generic Power BI advice tends to treat this as a nice-to-have for BI teams in general. For a Dynamics 365 F&O or Business Central reporting practice specifically, it addresses a sharper pain point. These environments accumulate large report portfolios fast: financial statement packages, inventory and demand dashboards, project cost tracking, often built by a rotating cast of internal analysts and external consultants over several years. Ownership gets murky, undocumented changes creep in before a board meeting, and when something breaks nobody can say with confidence what changed or when. Power BI Desktop’s version history feature, which also reached general availability in the May 2026 wave alongside the default PBIR change, gives that audit trail natively inside the desktop tool for the first time, which is directly relevant to any organization treating financial report changes as something that needs a change management trail rather than an honor system.

Deployment pipelines benefit in a related way. A report promoted from a development workspace to test and then production can carry annotation-driven configuration differences (a different default page, a different data source binding) without manual reconfiguration at each stage, and the promotion itself becomes something a pipeline log records rather than something a person remembers doing.

Rolling Out PBIR Without Breaking Anything

The rollout mechanics are straightforward but deserve a plan rather than an ad hoc toggle. PBIR is enabled through Power BI Desktop’s preview features under Options, and existing PBIR-Legacy reports convert automatically on the next save, with Desktop creating a backup copy first. That backup detail matters because there is no supported rollback path once a report has converted; the backup is the rollback path, and it lives in a local temp folder with a 30-day retention window, not somewhere a team should rely on long term. The sensible sequence is to pick one lower-stakes report first, ideally something without heavy custom visual dependencies, convert it, get comfortable with the folder structure and the Git workflow in a sandbox repository, and only then extend the practice to the financial statement packages where a mistake actually costs something. Establishing a branching convention (a feature branch per report change, a pull request before merging to the branch a production workspace tracks) before the first real conversion saves a team from learning that lesson under time pressure.

What Still Doesn’t Work Smoothly

A few limitations are worth knowing before committing a whole reporting portfolio to this model. Edits made directly in a code editor do not sync live; the report has to be reopened in Power BI Desktop for those changes to take effect, so treat external JSON edits as a batch operation rather than a live-editing workflow. Two developers can still step on each other if they edit the same page at the same time rather than different pages, since the conflict resolution is granular but not infinite. Service-side limits apply too: a report tops out at 1,000 pages and 1,000 visuals per page, and resource packages are capped at 300 MB, ceilings that rarely matter for a typical operational dashboard but are worth knowing about before designing something unusually large. And a handful of connection types, including push datasets, live connections to on-premises Analysis Services, and older model versions, are excluded from Git integration support entirely for now.

None of that undermines the core shift. Power BI reports built on Dynamics 365 data have functioned for years as single-owner artifacts, reviewed by nobody, versioned nowhere, and handed off through tribal knowledge. PBIR does not fix that automatically, but it removes the technical excuse for not fixing it. The teams that treat this as an application lifecycle management decision, with branching conventions, review checklists, and a deliberate rollout order, will get real governance out of it. The teams that flip the preview toggle and keep working exactly as before will just have smaller binary files. At Routeget, we have been sequencing client Dynamics 365 F&O reporting portfolios through this conversion starting with the highest-change-frequency reports rather than the highest-visibility ones, on the theory that the reports changing every month are where a missing audit trail actually costs someone time.

#PowerBI #PBIR #GitVersionControl #DynamicsFinanceOps #ReportGovernance #MicrosoftFabric

Direct Lake Semantic Models for Dynamics 365 F&O Data

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

A BI developer at a manufacturing client rebuilt their Dynamics 365 Finance and Operations reporting as a Direct Lake semantic model the week Fast Fabric rolled out, expecting the same near-instant refresh everyone had been promised in the release notes. For the first ten days it worked exactly that way: framing updates that used to take an overnight BYOD job finished in seconds, and finance users watched inventory valuation numbers move in something close to real time. Then a month-end load pushed one fact table past a few hundred million rows, a refresh failed outright with no warning beyond a guardrail error code, and the model sat unqueryable until someone tracked down which table had tripped which limit. Nothing about Direct Lake had changed. What changed was that nobody had modeled for its ceilings before the data volume found them.

That gap between “Direct Lake is fast” and “Direct Lake behaves differently enough from Import mode that it needs its own design discipline” is where most F&O teams get tripped up right now. Fast Fabric has genuinely solved the latency problem that made near-real-time F&O reporting impractical for years, cutting sync times that used to run one to two hours down to under fifteen minutes in most observed cases, according to Microsoft’s own Dataverse and Fabric integration update. But building a semantic model on top of that faster pipe is a different exercise than plugging Power BI into a data warehouse, and the differences matter most exactly when a model is otherwise working well enough that nobody is looking closely at it.

BI developer reviewing a Direct Lake semantic model diagram for Dynamics 365 F&O data on a widescreen monitor

What actually lands in OneLake now

F&O data doesn’t write to OneLake directly. It flows through Dataverse, which is the layer that transforms F&O table data into Delta Parquet and exposes it to Fabric through shortcuts and mirroring, without the customer managing any Spark compute or Azure infrastructure themselves. That’s the architectural distinction from the older Synapse Link pattern, where a customer’s own Spark jobs did the transformation. Fast Fabric, now in public preview with global rollout completed and an automatic upgrade for existing customers planned for the first quarter of 2026, is what tightened the sync cadence on that same Dataverse-to-OneLake pipeline. Anyone still comparing today’s F&O-to-Fabric numbers against the old BYOD or Data Export Service benchmarks is working from a stale mental model of what the pipeline can do.

The practical consequence for a solution architect is that F&O tables show up in a Fabric lakehouse as Delta tables with a Dataverse-flavored schema underneath them: GUID-based keys, some binary columns, and complex types that don’t map cleanly onto every Direct Lake data type. That schema inheritance is the first thing worth checking before any modeling work starts, not after a refresh fails.

Choosing a Direct Lake semantic model: OneLake or the SQL analytics endpoint

Fabric currently gives two ways to put a semantic model directly on top of those Delta tables, and the choice isn’t cosmetic. Direct Lake on the SQL analytics endpoint reads through the lakehouse or warehouse’s SQL layer, supports non-materialized views, and, critically, falls back to DirectQuery automatically when a table can’t load in Direct Lake mode, for example when SQL-based row-level security is enforced. Direct Lake on OneLake skips that SQL layer and reads Delta tables directly from any Fabric source, which unlocks composite models that mix Direct Lake with Import or DirectQuery tables, calculated tables, and calculated columns (both still in preview and, for calculated columns, limited to user-context evaluation). The tradeoff is that Direct Lake on OneLake has no fallback path at all. If a query exceeds a guardrail, it fails. There is no quietly-slower DirectQuery safety net to catch it.

For most F&O reporting models, that argues for a specific default: use Direct Lake on OneLake when the model genuinely needs composite modeling or calculated tables over F&O data, and reach for Direct Lake on the SQL analytics endpoint when the model is closer to a straightforward reporting layer where a DirectQuery fallback is worth more than the extra flexibility. Architects who pick OneLake mode by default because it’s the newer, more capable option often find out about the missing fallback during a production incident rather than during design review.

Framing, transcoding, and what a guardrail failure actually costs

Direct Lake’s refresh model is fundamentally different from Import, and it’s worth explaining precisely because the difference is what makes the failure mode above so disruptive. A traditional refresh in Import mode copies the underlying data. Direct Lake framing copies only metadata: it analyzes the latest Delta table version, points the model’s references at the current files in OneLake, and finishes in seconds rather than minutes or hours. Data itself loads column by column, and only the columns a given query actually touches, through a process Microsoft calls transcoding. That’s what lets a Direct Lake model handle data volumes larger than a capacity’s memory ceiling; it never has to hold all of it at once.

Abstract visualization of real-time data synchronization from Dynamics 365 F&O into Microsoft Fabric OneLake

Capacity guardrails are what set the boundaries on this, and they scale meaningfully by Fabric SKU. An F2 through F8 capacity caps out at 1,000 Parquet files and 1,000 row groups per table, 300 million rows, and a 10 GB model size limit. Step up to F64 or above and those ceilings jump to 5,000 files, 5,000 row groups, and 1.5 billion rows, with model size effectively unlimited. A large F&O fact table, general ledger transactions or inventory movements on an enterprise instance, can realistically approach those lower-tier limits, which means the F-SKU a Fabric workspace runs on isn’t just a cost decision anymore. It’s a modeling constraint that should be checked against actual F&O table row counts before a Direct Lake model design gets finalized, not discovered when a guardrail breach takes the model offline.

The newer Manage Tables capability, now in public preview for existing Fabric links, gives architects a lever here that didn’t exist a year ago: selecting which F&O-sourced tables actually sync to Fabric, rather than replicating an entire dataset and hoping guardrails hold. Narrowing the synced table set to what a given semantic model actually needs is one of the more direct ways to keep a Direct Lake model inside its capacity’s guardrails without upgrading the SKU.

Data type conversions worth doing before, not after, deployment

Direct Lake doesn’t support every Delta data type. Complex Delta types, binary fields, and GUID columns need to be converted, typically to strings, before a Direct Lake model can use them cleanly. Because F&O data reaches OneLake through Dataverse’s schema, GUID-based surrogate keys and occasional binary fields show up more often than they would in a purpose-built warehouse schema, so this conversion step tends to hit F&O-sourced models harder than it hits models built from cleaner, purpose-designed lakehouse tables. Handling these conversions in a lakehouse notebook or a Fabric pipeline before the semantic model is built, rather than discovering the unsupported type at model creation time, avoids a rebuild cycle that’s easy to skip when a project is already behind schedule.

A few other constraints round out the pre-deployment checklist: Direct Lake has no gateway support, so on-premises data can’t participate directly; the semantic model’s workspace has to sit in the same region as the data source workspace; and Direct Lake isn’t available in personal workspaces at all. None of these are exotic edge cases for an enterprise F&O deployment, but each is the kind of thing that’s far cheaper to confirm during architecture review than to discover during a go-live weekend.

Building for the ceiling, not just the average day

Fast Fabric removed the latency excuse that used to justify slower, batch-oriented F&O reporting architectures, and that’s a real and welcome change. But a semantic model designed only against yesterday’s data volumes, without a look at capacity guardrails, fallback behavior, and the schema quirks Dataverse introduces, is a model that works fine until the month it doesn’t. Routeget Technologies has walked several clients through exactly this kind of pre-deployment guardrail check on F&O Direct Lake models, and the pattern holds: the projects that skip it don’t usually fail on day one. They fail on the first month-end close that actually stresses the numbers the design assumed would stay small.

#DirectLake #MicrosoftFabric #DynamicsFinanceOps #PowerBI #DataModeling #FabricGuardrails

Your Dynamics 365 Power BI Dashboards Are Getting Faster, Not Instant

IT and finance leader reviewing a real-time analytics dashboard on a wall-mounted monitor in a modern office

An IT Director I know sat through a Monday operations review where the COO pointed at a Power BI inventory dashboard and asked why it still showed Friday’s numbers. The dashboard was labeled “real-time” in the workspace title, a name someone had chosen two years earlier and nobody had revisited since. It wasn’t a bug. It was the honest output of a reporting pipeline that moved data from Dynamics 365 Finance and Operations to Power BI through several intermediate stops, each one adding its own delay before a transaction became a chart.

That gap between when something happens in the ERP and when a decision-maker can see it is the actual cost center in most Dynamics 365 analytics programs, even when nobody puts a dollar figure on it. Microsoft closed a meaningful part of that gap this year with a change that makes Dynamics 365 Power BI dashboards measurably fresher, and the result is worth understanding before your team assumes “real-time” now means what the word implies.

Where the lag actually came from

Most organizations running Dynamics 365 Finance and Supply Chain Management have historically moved data into Power BI through some version of the same pattern: an export process pulls records out of the operational database, writes them as flat files, a separate conversion step turns those files into the columnar format analytics tools actually want, and only then does the data land somewhere Power BI can query it efficiently. Under the older Fabric Link architecture, that meant Dataverse writing data out as CSV first, then a second process converting that CSV into Delta Parquet before it reached the Fabric lakehouse. Each of those stages is a place where a batch job can queue, a conversion can lag behind incoming volume, or a large table can simply take a while to work through.

Layer scheduled Power BI refreshes on top of that, and the staleness compounds. A report built on imported data can only be as fresh as its last refresh cycle, and refresh frequency has practical ceilings tied to licensing tier and workload size. The net effect for a lot of finance and supply chain teams was dashboards that were accurate but rarely current, off by anywhere from thirty minutes to an hour depending on the day’s data volume and where in the refresh cycle a viewer happened to open the report.

What actually changed for Dynamics 365 Power BI dashboards

Microsoft announced general availability of low-latency sync for Fabric Link in a Power Platform blog post published June 9, 2026, and it targets exactly that CSV hop. The new sync engine writes data from the Dataverse database directly into Delta Parquet format in OneLake, removing the intermediate serialization step entirely. Fewer stages means fewer places for a job to fail, less contention on shared resources during the conversion, and a simpler retry path when something does go wrong.

Solution architect at a dual-monitor workstation reviewing an abstract data pipeline and sync architecture diagram

The throughput difference Microsoft cites for Finance and Operations apps specifically is substantial: table sync that previously ran in the range of 100,000 to 700,000 records per hour now reaches upwards of 1 million records per hour per table, under lab conditions the company is careful to note may not match every production environment exactly. Dynamics 365 customer engagement apps see a comparable improvement in delta sync latency, though Microsoft hasn’t published an equivalent throughput figure for that side of the platform. Paired with Power BI’s Direct Lake mode, which queries the Delta tables in OneLake directly instead of importing a copy into the report, the combination removes both sources of staleness at once: the pipeline delay and the refresh-schedule delay.

The rollout followed a staged regional schedule rather than a single cutover. Early release stations had it first, European, Canadian, and Indian environments picked it up in late June 2026, Asia Pacific, Japan, the UAE, Australia, and the UK followed in early July, and the remaining stations, including most of the Americas, were targeted for general availability by the end of July 2026. Microsoft flagged those windows as approximate and subject to change based on deployment health, which is a reasonable caveat for any organization trying to plan a go-live date around it.

What “near real-time” actually buys you

Here is the detail worth putting in front of whoever asked for real-time dashboards in the first place: this is a genuine and measurable improvement, but it is not streaming analytics. Practitioner reporting on the feature places typical data freshness in the range of fifteen to forty-five minutes after a transaction posts, down meaningfully from the roughly sixty-minute staleness common under the old architecture and refresh-schedule combination, but still a real interval. If your business actually needs second-by-second visibility into something like a production line sensor feed or a live transaction stream, that’s a different Fabric capability, Real-Time Intelligence, built around event streams and purpose-built for that use case rather than general ERP reporting.

Setting that expectation correctly matters more than the technical detail, because a COO who was told a dashboard is “real-time” and then watches it lag by half an hour during a busy close period will lose trust in the tool faster than one who was told upfront to expect fifteen-to-forty-five-minute freshness and sees exactly that. The fix here is genuinely good news for finance and supply chain reporting. It just isn’t the specific thing the word “real-time” tends to promise in a boardroom conversation.

The decisions this forces onto your roadmap

For organizations already on Fabric Link, adopting the new engine isn’t automatic. Existing links have to be unlinked and reconnected once a given environment’s region has been enabled, and Microsoft is explicit that relinking triggers a full initial resynchronization of every configured table, not an incremental catch-up. For a large Finance and Operations environment with years of transaction history, that’s not a trivial operation to schedule during business hours, and it’s worth treating as a planned cutover with its own change window rather than a background toggle. You can confirm a link has moved to the new engine by checking the Azure Synapse Link section in the admin experience for a “low-latency mode” flag against the profile.

There’s a version dependency to check before assuming your environment even qualifies. Microsoft’s guidance points organizations to verify their Finance and Operations build against the minimum supported version documented for low-latency sync, commonly cited around release 10.0.46 and later builds; if your environment hasn’t been kept current, that’s worth confirming with your applications team before the migration gets scheduled rather than after.

There’s also a budget conversation worth having early. Fabric Link’s replication model increases Dataverse storage consumption, since the platform is now maintaining a synchronized copy of operational data inside the Fabric environment; the compression Delta Parquet provides offsets some of that, but not all of it, and IT Directors sizing next year’s Fabric capacity should factor that in rather than discovering it in a usage report. Organizations that specifically need data exported into storage accounts they control, rather than accessed through Fabric shortcuts, still have Azure Synapse Link as an alternative path, though it carries its own Spark pool compute costs that scale with refresh frequency and change volume.

Finally, this is a reasonable moment to revisit whether your organization is still running the older Export to Data Lake integration. Microsoft’s messaging has been consistently pointing customers toward Fabric Link as the forward path, and while no hard retirement date has been published as of this writing, an environment still depending on the older CSV-based export is not going to benefit from any of the improvements described here. Rolling that conversation into the same project as the low-latency migration, rather than treating them as separate initiatives six months apart, saves a second round of testing and stakeholder communication.

Getting the rollout right

None of this requires a rebuild of your analytics estate. It requires a version check, a scheduled relink with real downtime planning around the resync, an honest conversation with the business about what “near real-time” will and won’t deliver, and a capacity plan that accounts for the storage shift. Organizations that have gone through a few rounds of Dynamics 365 and Power BI platform changes tend to treat this kind of update as routine infrastructure work rather than a special project, which is generally the right instinct. Routeget has walked several clients through exactly this kind of Fabric Link migration, and the pattern that separates a clean cutover from a messy one is almost always the same: confirm the prerequisite build first, schedule the resync deliberately, and set the freshness expectation with stakeholders before the new dashboard goes live, not after someone notices the timestamp.

#PowerBI #MicrosoftFabric #DynamicsFinanceOps #DataLatency #DirectLakeMode #FinanceReporting

The Power BI Premium Retirement Has a Fabric Capacity Migration Trap Most Budgets Miss

Finance and IT leader reviewing a cloud capacity and cost analytics dashboard, representing the Power BI Premium to Fabric capacity migration decision

Somewhere in the last few months, a Power BI Premium renewal notice landed on a procurement desk with a number that didn’t match last year’s invoice, and nobody could immediately explain why. That scene is playing out across a lot of finance and IT organizations right now, because Power BI Premium’s per-capacity SKUs (the familiar P1 through P5 tiers) are being phased out in favor of Microsoft Fabric capacity, and a Fabric capacity migration for many enterprises is landing at the exact moment their Enterprise Agreement comes up for renewal. Non-EA customers lost the ability to renew Premium capacity back in January 2025. EA holders have had more breathing room, but only until their current agreement term ends, and a wave of three-year EAs signed in 2023 are hitting that wall throughout 2026.

The mechanics of the transition get covered reasonably well in Microsoft’s own migration documentation: reassign workspaces to a Fabric F-SKU, validate refreshes and gateways, decommission the old capacity. What gets far less attention, and what has already caught more than one IT Director off guard mid-negotiation, is a licensing detail buried a few layers into the SKU comparison: not every Fabric capacity size preserves the free-viewer access that Power BI Premium customers have taken for granted for years.

Why F64 Is the Number That Actually Matters

Under Power BI Premium, any user with the Free license could view content in a workspace backed by Premium capacity, so long as they had a Viewer role. That was one of Premium’s core value propositions for large organizations: a single capacity purchase covered report consumption for hundreds or thousands of employees without individual Pro licenses.

Finance and IT leader reviewing a cloud capacity and cost analytics dashboard, representing the Power BI Premium to Fabric capacity migration decision

Fabric capacity does not carry that benefit uniformly across its SKU range. Free-user viewing only returns at F64 and above. Anything from F2 through F32, the sizes that map to smaller or mid-sized Premium deployments on paper, requires every single viewer to hold a Power BI Pro or Premium Per User license. For an organization whose consumption metrics suggest a P1-equivalent capacity would be plenty, the naive read-across is F64 anyway (Microsoft’s own sizing guidance maps P1 to F64), so this often isn’t a problem for P1 customers specifically. The real exposure shows up for organizations that assumed they could right-size downward, based on actual utilization data, into an F32 or smaller footprint to save on the recurring Fabric bill, only to discover that doing so would require issuing several hundred new Pro licenses to preserve the same viewer population that costs nothing today.

That’s not a hypothetical. It’s the kind of number that shows up in a board deck as a line item nobody budgeted for, and it’s precisely the sort of decision that needs to be modeled before a renewal date forces a choice, not after.

The Real Timeline Pressure

Microsoft’s transition isn’t open-ended once a Premium term lapses. There’s a 30-day grace period after a P-SKU subscription ends, during which capacity keeps functioning while a migration gets finalized. After day 30, access starts getting throttled, meaning interactive operations slow down or get delayed. Past day 90, every operation against that capacity gets rejected outright. The underlying data isn’t deleted, but it becomes fully inaccessible until either the migration completes or the capacity is retired for good.

For a CIO or IT Director, the practical implication is that “we’ll deal with the Fabric migration next quarter” is not a safe posture once an EA renewal date is visible on the calendar. The sequencing matters too: the recommended path is to provision the new F-SKU capacity, reassign workspaces to it, validate that refreshes and reports behave correctly, and only then cancel the old Premium subscription, because that cancellation doesn’t happen automatically and the two capacities can run in parallel briefly during validation. Treating this as a same-week swap invites exactly the kind of outage that turns a licensing decision into an incident review.

Sizing the Fabric Capacity Migration Instead of Guessing at It

Solution architect reviewing a stepped bar chart representing Fabric capacity sizing tiers on a workstation monitor

The good news is that Microsoft doesn’t leave the sizing decision to intuition. The Fabric Capacity Metrics app, which connects to a tenant’s actual consumption history, is the mechanism most consulting teams now use to baseline 30 to 45 days of real Premium usage before committing to an F-SKU size. Organizations with sustained utilization near the ceiling of their current capacity generally need an equivalent or larger Fabric SKU to avoid throttling. Organizations with long stretches of low activity, evenings, weekends, month-end lulls followed by spikes, are often better served by a smaller capacity paired with Fabric’s pause and resume functionality, something Premium never offered. Pausing a capacity during genuinely idle hours stops billing entirely, which is a real lever for reducing the annual spend rather than just shifting it from a Microsoft 365 line item to an Azure one.

That said, the free-viewer threshold at F64 has to be weighed against pure utilization math. A tenant whose usage data suggests F32 is technically sufficient may still come out ahead financially by sizing up to F64 and avoiding a mass Pro license rollout, and that comparison is specific enough to the organization’s own viewer count and existing Pro license penetration that it needs to be run as an actual cost model, not assumed either way.

What Else Changes Beyond the Bill

A few other differences are worth putting in front of a decision-maker evaluating this migration, because they shape both cost and risk. Fabric capacity is billed through Azure, on a pay-as-you-go or reserved basis, rather than through the Microsoft 365 commitment model Premium customers are used to, which means the invoice shows up in a different place and often gets reviewed by a different team. Capacity-level settings, things like semantic model memory limits or custom workload configurations, don’t carry over automatically during migration and need to be recreated on the new capacity, so a lift-and-shift assumption can leave gaps in governance that only surface later. And for organizations considering a cross-region move as part of the migration, perhaps to consolidate capacity somewhere with better Azure pricing, large-format semantic models and other Fabric items generally don’t survive that move intact; they need to be backed up and recreated, which introduces real downtime that a same-region migration wouldn’t require. For most organizations, the operational cost of that rebuild outweighs whatever regional pricing delta prompted the idea in the first place.

Getting Ahead of the Renewal Date

None of this argues against moving to Fabric capacity. The pause and resume billing, the built-in Power BI Embedded rights, the tighter Azure governance integration through managed private endpoints and RBAC, these are genuine improvements over what Premium offered, and the migration itself is generally low-risk when it stays within the same tenant and region. The argument is against treating this as a routine renewal to be handled by whoever owns the Microsoft relationship without IT and finance jointly reviewing the sizing math first.

The organizations getting this right are starting the Capacity Metrics baseline well before their EA renewal conversation, running the free-viewer cost comparison as an actual spreadsheet rather than an assumption, and building the migration into a maintenance window rather than a renewal-week scramble. We’ve walked several clients at Routeget Technologies through exactly this exercise this year, and the pattern holds: the technical migration is rarely the hard part. The licensing model change underneath it is what catches finance teams by surprise, and it’s avoidable with about a month of preparation.

If your Power BI Premium renewal or EA term ends anytime in the next twelve months, that preparation should be starting now, not when the notice arrives.

#PowerBI #MicrosoftFabric #FabricCapacityMigration #ITBudgetPlanning #DataAnalyticsStrategy #CloudCostManagement

Export to Data Lake Migration: Fabric Link or Synapse Link Before the November Cutoff

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Somewhere in your Dataverse environment, or bolted onto Dynamics 365 Finance and Operations through Lifecycle Services, there is probably a data pipeline that has been quietly exporting records to Azure Data Lake Storage for years without anyone touching its configuration. That pipeline stops working for good on November 30, 2026. Microsoft has confirmed there will be no further extensions past that date, which means any architect or BI team still running the legacy Export to Data Lake add-in needs an Export to Data Lake migration plan in motion now, not a vague intention to “look at it before year end.” With roughly eleven weeks left on the clock as of this writing, the practical question is not whether to move, but which of the two supported replacements to move to, and what actually breaks in the schema when you do.

The confusion around this deprecation runs deeper than most Microsoft retirements, largely because the naming has changed twice in the last two years and the marketing language has blurred two genuinely different services into one. It is worth being precise about what is actually going away before touching any configuration.

What Is Actually Being Retired

Export to Data Lake, the LCS-installed add-in that let finance and operations apps write entity data directly into a customer’s Azure Data Lake Storage Gen2 account, was marked deprecated back in October 2023 and stopped accepting new adopters on November 1, 2024. What has not been widely understood is that existing customers were allowed to keep running it on a grace period, and that grace period ends permanently on November 30, 2026. After that date, no further data lands in the lake through that pipeline. Downstream Synapse pipelines, Power BI datasets, and any custom ETL jobs reading from that storage account simply stop receiving updates, with no error thrown anywhere obvious enough to trip an alert.

What is not retiring, despite frequently being confused with the legacy add-in, is Azure Synapse Link for Dataverse itself. Microsoft has stated plainly that Synapse Link is a long-term supported service. The naming has shifted again as of the July 2026 UX refresh: the feature is now presented under a unified “Link data” page in Power Apps, split into “Fabric Links” as the recommended path and “Other Links” covering the Azure Synapse option. If your team has been searching documentation for “Export to Data Lake” and finding nothing current, that rename is why.

Cloud data architecture visualization showing data streams flowing through an enterprise server environment, representing Dataverse and Azure data lake integration

Fabric Link or Synapse Link: The Decision That Actually Matters

Once the rename is out of the way, the real architectural decision is between two genuinely different integration models, and picking the wrong one for your organization’s actual downstream consumers is the most common mistake we see in migration planning.

Link to Microsoft Fabric is a no-copy model. Data stays inside Dataverse’s managed storage and is exposed to Fabric and Power BI through OneLake shortcuts rather than being physically copied into a separate account you control. Setup is fast: a four-step wizard handles workspace identity authentication (now the recommended method over service principals, since Microsoft’s own release notes describe it as removing “the most common Fabric link setup failure mode”), table selection, and initial sync, which typically completes within about sixty minutes for moderate data volumes. The tradeoff is that you do not own the underlying storage account, table selection for non-system tables is largely automatic rather than admin-curated, and any custom pipeline tooling outside the Microsoft Fabric ecosystem has no direct file-level access to the data.

Azure Synapse Link for Dataverse, by contrast, continuously exports data as Delta Parquet files into a storage account your organization owns and controls. If your analytics estate depends on non-Microsoft tools, custom Spark jobs reading raw Parquet, or an existing Synapse workspace with pipelines your team has already built and tuned, this is almost always the correct choice, and it remains fully supported going forward. The tradeoff is that you take on more operational responsibility: managing the storage account, its firewall rules, and eventually a private endpoint migration if your organization needs one (a related but separate deadline, the trusted-services firewall exception for private link configurations, retires August 1, 2027, so build that into planning if it applies to you).

Where the Export to Data Lake Migration Breaks Existing Pipelines

This is the part of the Export to Data Lake migration that catches teams off guard even after they have chosen a replacement path, because the schema produced by Fabric Link and Synapse Link is not a drop-in replacement for what the legacy add-in produced. Several changes will break any downstream job written against the old CSV-based output.

The most disruptive change for finance and operations data is that the primary identifier field, previously exposed simply as ID, is now surfaced as FnO_Id. Any view, stored procedure, or Power Query step that hard-codes the old column name will fail or silently return nulls after cutover, and this is worth grepping for across your entire analytics codebase before you flip the switch, not after. Time zone identifier (TZID) fields, which were largely unused legacy artifacts in the old export anyway, have been dropped entirely. Binary data columns are no longer included in the export at all, and nvarchar(max) fields are truncated at 2,000 characters, which matters if any process was relying on long free-text fields such as notes or descriptions coming through intact. On the positive side, the new format adds a proper isDelete flag for row-level soft-delete tracking, which the legacy CSV export never handled cleanly, so reconciliation logic that used to infer deletions by diffing snapshots can often be simplified.

There is also a prerequisite that trips up more migrations than the schema differences themselves: only tables with the Track Changes property enabled will appear as selectable in either Fabric Link or Synapse Link. A meaningful number of legacy finance and operations entities were never configured for change tracking, and some cannot have it enabled without developer involvement to extend the entity definition. Audit which tables your current pipeline depends on and confirm change tracking status on each one before you assume the new link will simply mirror what you already have.

Solution architect reviewing a cloud data pipeline migration diagram on a monitor in an office setting

Sequencing the Cutover Without a Data Gap

The safest sequencing we recommend is to stand up the replacement link in parallel with the legacy export while both are still functional, rather than decommissioning the old pipeline first and troubleshooting the new one under deadline pressure. Run both for at least one full reporting cycle, ideally a month-end and quarter-end close if the data feeds financial reporting, and reconcile row counts and key totals between the two outputs before cutting anything over. Microsoft’s FastTrack team publishes two open-source transition tools worth using rather than building your own equivalents from scratch: a SQL Analytics Endpoint tool for validating Fabric Link output against expectations, and a Virtual Data Warehouse tool for Synapse Link migrations. Both are available through the Dynamics 365 FastTrack Implementation Assets repository and can shortcut a meaningful amount of validation work.

Two configuration details are also worth checking before you commit to a path: profiles that were originally set up in CSV format cannot be linked forward to Fabric, and profiles secured with managed identities have the same restriction. Both require a fresh setup rather than an in-place conversion, so factor that into your timeline if either applies to your current configuration. Once the new link is validated and running cleanly, the legacy Export to Data Lake add-in itself should be formally uninstalled through Lifecycle Services rather than simply left dormant, both to avoid confusion for the next person who inherits the environment and to remove a component that will stop functioning anyway once November 30 passes.

Where This Leaves Architecture Teams

None of this is a difficult migration in isolation. A Fabric Link setup for an organization with modest data volumes and no custom storage requirements can realistically be completed in a day, including validation. What makes this deprecation worth taking seriously now rather than in October is the schema drift buried inside it: the ID field rename alone is enough to quietly break a Power BI model or a downstream integration that nobody has looked at closely in over a year. We have walked several clients through this exact transition at Routeget Technologies, and the pattern holds consistently: the technical setup is fast, but finding every place the old schema was assumed to be permanent takes the real time. Start that inventory now, while there are still weeks to spare rather than days.

#ExportToDataLake #AzureSynapseLink #MicrosoftFabric #DataverseIntegration #CloudArchitecture #ERPGovernance