Dataverse Capacity Got Bigger This Year. Your Storage Governance Still Needs to Catch Up

IT director reviewing a Dataverse storage capacity dashboard showing database, file, and log usage

An IT director we spoke with recently pulled up the Power Platform admin center in January expecting the same tired warning banner about Dataverse capacity that had been sitting there since October. It was gone. Database storage for their Dynamics 365 Finance and Supply Chain Management environment had jumped from 90 GB to 125 GB overnight, with no purchase order, no change request, and no email from their partner. The natural conclusion was that the capacity problem had quietly solved itself. Four months later, the same environment tripped a new kind of alert: a file storage overage notice, even though database usage looked flat. Nothing had been deleted or migrated. The ground underneath the numbers had simply moved.

That is roughly where most Dynamics 365 and Power Platform customers stand right now with Dataverse storage. Microsoft raised default capacity entitlements significantly in December 2025, restructured how that capacity is reported and managed, and then made a second, narrower adjustment in the spring that reclassifies certain metadata between storage types. Individually, each change is well documented. Together, they change what a capacity plan built a year ago actually means, and CIOs and IT directors who treat the December Dataverse capacity increase as a problem solved rather than a system redesigned are going to be surprised by their own admin center in a quarter or two.

What changed in Dataverse capacity this December

The default database capacity increase was substantial and varied by product. Copilot Studio, Power Apps per-app plans, and Power Automate process licenses moved from a 5 GB to a 15 GB baseline. Dynamics 365 CRM applications, including Sales, Customer Service, Field Service, and the Contact Center, moved from 10 GB to 30 GB. Dynamics 365 Customer Insights went from 25 GB to 45 GB. On the ERP side, Standard tier products including Finance, Supply Chain Management, Project Operations, Commerce, and Human Resources rose from 60 GB to 90 GB, while the Premium tier for Finance and Supply Chain Management increased from 90 GB to 125 GB. File storage roughly doubled across most of these same products, though Microsoft did not publish the same level of per-product detail it did for database capacity. Log storage was left untouched.

The more structurally important change sits underneath those numbers. Finance and Operations customers previously managed two separate storage pools: one for the Operations database and one for Dataverse. As of December, those pools merged into a single combined entitlement. For an organization that had been carefully tracking two distinct capacity ceilings, this is not a cosmetic simplification. It changes how consumption trends read, and it means a team that spent the last two years building spreadsheets or Power BI reports to track Operations and Dataverse separately needs to rebuild that tracking around a single number.

Three capacity types, not one

Alongside the entitlement increase, Microsoft has been rolling out a new capacity reporting model that separates Dataverse storage into three distinct types: database, file, and log. This is not universal yet. Organizations still on the legacy model see a single blended capacity figure, while those on the new model get per-type visibility along with a mechanism called cross-capacity-type borrowing. Under that mechanism, unused database capacity can offset a log or file overage, and unused log capacity can offset a file overage, but file capacity cannot offset shortfalls anywhere else. A tenant only registers as officially over capacity after all of that eligible borrowing has already been applied.

Abstract illustration of database, file, and log storage blocks connected by data flow lines representing Dataverse capacity

This matters for budget owners specifically because it changes what an overage notification actually tells you. A file storage warning on an environment that appears to have plenty of headroom in its combined number is not necessarily a sign that the tenant needs more storage overall. It may simply mean the tenant has database or log capacity sitting unused that isn’t automatically flowing to cover the file shortfall, either because the environment hasn’t moved to the new model yet or because the borrowing rules genuinely don’t apply in that direction. Before anyone approves a purchase of additional capacity, it is worth confirming which reporting model the tenant is actually on and whether the specific storage type in the alert is one that borrowing rules can even help with.

The April reclassification nobody budgeted for

In April 2026, Microsoft moved solution-aware tables and related metadata out of database storage and into file storage. Total consumption for an organization does not change as a result of this move, but the split between the two numbers does, and it does so without any corresponding change in what the organization is actually storing. A team that set a database utilization threshold as an internal early-warning trigger, say 70 percent of entitlement, may find that number drop for reasons that have nothing to do with actual data growth, while file utilization climbs for the same non-reason. Anyone reviewing a capacity trend line that spans this period without accounting for the reclassification is going to draw the wrong conclusion about whether their data growth rate is accelerating or slowing down.

Sales Premium customers got a further, separate adjustment in the same window: per-user file storage entitlement doubled from 250 MB to 500 MB, and the underlying tenant base storage figures for those environments moved as well. Microsoft’s own framing for these changes has been candid about the driver: AI-assisted features, Copilot experiences inside Dynamics 365 applications, and the broader push toward agentic workflows all generate metadata, context, and interaction history that traditional transactional storage planning never had to account for. Storage capacity planning built around transaction volume alone is now measuring the wrong thing.

What a capacity plan actually needs to do differently

None of this means the December increase was a bad deal for customers. Bigger entitlements at no additional cost are, on their own terms, a straightforward win, and organizations that were previously purchasing supplemental capacity to cover a gap that the new baseline now closes should go back and cancel or right-size that spending. The mistake is treating a larger number as the end of the exercise rather than the start of a different one.

The more durable response is to rebuild storage governance around the actual mechanics Microsoft has put in place rather than around the old assumption of one number that only ever goes up when you buy more. That starts with confirming, environment by environment, whether the tenant is on the legacy single-figure model or the new three-type model, since the two require genuinely different monitoring approaches. It continues with capturing a clean baseline now, broken out by database, file, and log where that visibility exists, so that the April reclassification and any future ones can be isolated from genuine consumption growth rather than blended into it. It also means understanding the capacity extension option Microsoft makes available once an environment crosses 80 percent utilization: a 45-day window to reduce usage or purchase additional capacity, capped at three extensions in a rolling 365-day period, which is a real safety valve but not one designed to be leaned on indefinitely. And it means deciding, deliberately and in advance rather than reactively during an incident, whether pay-as-you-go billing tied to an Azure subscription is the right overage mechanism for a given environment or whether reallocating from tenant pool capacity is preferable.

For finance and IT leaders who fund these environments, the practical takeaway is that Dataverse storage has moved from a mostly static line item to something closer to a cloud consumption model, with the reporting granularity and billing flexibility that implies, but also the volatility. That is a governance conversation as much as a technical one, and it is worth having before the next reclassification lands rather than after a budget line quietly moves for reasons nobody remembers agreeing to. At Routeget, the engagements that go smoothest are the ones where a client’s storage monitoring gets rebuilt around the new model proactively, rather than the ones where the first real conversation about it happens after an unexpected overage notice.

#Dataverse #DataverseStorage #PowerPlatformLicensing #ITGovernance #DynamicsFinanceOps #CloudCostManagement

Power Platform License Enforcement Has a Deadline: February 2027

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

A Power Platform administrator at a mid-size manufacturer got an odd notice in her Microsoft 365 message center in March. It referenced managed environments, a governance feature she associated with premium licensing decisions her CIO had deliberately deferred two budget cycles in a row. She assumed it was routine noise and archived it. Six months later, the same governance feature had been switched on for a dozen production environments without a single approval meeting, because those environments happened to be deployment targets in the organization’s new Power Platform pipelines setup. Nobody had connected the dots between an ALM modernization project and a licensing enforcement clock that started ticking the moment it went live.

That disconnect is becoming common, and it points to a real Power Platform license enforcement deadline that CIOs and IT directors should be treating as a budget line item rather than a footnote in an admin center notification. Microsoft has been quietly retiring the ALM Accelerator for Power Platform, the free, GitHub-based reference implementation many organizations used to bolt source control and deployment automation onto Azure DevOps. In its place, Microsoft is steering everyone toward Pipelines, the native, in-product ALM experience built directly into the Power Platform admin center. The pipelines feature itself is a genuine improvement for most organizations. The licensing mechanics it triggers are the part that deserves scrutiny before anyone signs off on the migration.

Why the ALM Accelerator Is Going Away

The ALM Accelerator was never meant to be permanent. Microsoft built it as a canvas app and Azure DevOps extension pairing, a reference pattern for makers who wanted Git-backed source control and staged deployments without hiring a professional DevOps team. Microsoft’s own documentation now marks it deprecated: no new features, and issues raised against it are no longer reviewed or fixed. The stated successor is Pipelines, described in Microsoft’s guidance as the strategic, in-product experience for maker-initiated application lifecycle management, extensible into Azure DevOps or GitHub when a team needs deeper customization.

For a lot of teams, that is a reasonable trade. Pipelines can be configured in minutes rather than the days or weeks a hand-built Azure DevOps release pipeline typically takes, and it comes with pre-validation, staged approvals, and automatic solution backups out of the box. The tradeoff is that Pipelines requires its non-host target environments, meaning the QA and production environments a solution deploys into, to be managed environments. Development environments are exempt, and the pipeline host itself does not have to be managed, but everything downstream of it does.

IT director and finance leader reviewing a software licensing compliance dashboard together in an office

The Auto-Enablement Nobody Voted On

Here is where the administrator’s ignored notice becomes relevant. Microsoft’s documentation states plainly that starting in February 2026, it began enabling managed environments automatically for any pipeline target environment that was not already configured that way. Tenant admins can opt into a setting under Deployments, Settings in the Power Platform admin center that converts pipeline targets to managed environments proactively, and Microsoft recommends doing so. But the underlying enforcement is not contingent on that opt-in. If a solution is deployed through a pipeline into an unmanaged production environment, Microsoft’s rollout will convert that environment regardless of whether an admin ever flipped the setting.

That matters because managed environments are not a purely technical governance toggle. They carry a licensing dimension that most conversations about ALM modernization skip entirely.

The Licensing Dimension Most ALM Conversations Skip

Managed environments themselves do not cost extra on top of the right license. They come bundled as an entitlement with standalone Power Apps Premium, Power Automate Premium, Copilot Studio, Power Pages, and most Dynamics 365 licenses, along with pay-as-you-go meters for per-app and Copilot Studio consumption. That sounds harmless until you account for how many production apps in a typical enterprise are actually running on seeded or included rights rather than a standalone license: a Power Apps use right bundled into an Office 365 plan, or Power Automate capability included with a Dynamics 365 Pro license and scoped only to that application’s context. Those included rights were never built to satisfy managed environment licensing requirements on their own, and Microsoft’s own FAQ language on the topic notes that Power Apps or Power Automate capability tied to a Dynamics 365 Pro license is meant to be used only within that licensed application, not as a general-purpose citizen development platform.

Managed environments carry an autoclaim policy that automatically assigns the correct license to a user who accesses an app there, provided the tenant has license capacity to draw from. Autoclaim solves the paperwork problem of manually assigning licenses one user at a time. It does not solve the budget problem of simply not owning enough qualifying licenses to autoclaim against, and it does nothing for a user whose only access to Power Apps or Power Automate comes through a seeded right that was never designed to extend into a managed, governed production environment.

Abstract illustration of a countdown clock merging with a network of cloud environment nodes, some locked and some unlocked

The Power Platform License Enforcement Timeline You Are Already Inside

This is not a distant, hypothetical deadline. Microsoft’s published timeline shows administrative notifications through the Microsoft 365 message center and Power Platform admin center beginning in March 2026. In-app notifications aimed directly at end users without an appropriate license started in June 2026, following a staged escalation: an informational message on day one, a warning after seven days, and an error state after fifteen, each urging the user to request a license from an admin. The hard stop lands in February 2027: users who still lack an appropriate license at that point are blocked from opening the app entirely, shown a standard message telling them they need a Power Apps license to use it. Apps are not deleted and access resumes automatically once a qualifying license is detected, but for that window, whatever workflow depended on that app simply stops working for that user.

Given today’s date, that means the notification phase is already well underway inside most tenants that run pipelines against production environments, and the enforcement date is now closer than most annual license renewal cycles.

What This Means for the Business Case

None of this is a reason to avoid Pipelines or to keep patching together an already-deprecated ALM Accelerator deployment. The practical response is to treat the license audit as part of the ALM modernization project plan rather than as an afterthought that surfaces after go-live. That means pulling a current list of every user who accesses production apps sitting in, or scheduled to sit in, a pipeline-managed environment, and checking each one against a standalone qualifying license rather than assuming a Microsoft 365 or Dynamics 365 seat covers it. It means asking whether apps currently running on included, scoped rights actually need to move to standalone Premium licensing, get rearchitected to stay within their original licensed application’s context, or get retired if nobody can justify the cost. And it means giving finance and procurement enough lead time to true up license counts well before February 2027, rather than discovering the gap when a plant floor supervisor gets locked out of a production app and escalates it as an outage.

Organizations that have gone through this kind of ALM transition tend to find the technical migration to Pipelines is the easy part. The harder, more valuable work is the license and governance audit that should have accompanied it from the start, which is usually where firms like Routeget Technologies get pulled into these engagements: less to configure a pipeline, more to make sure the environments behind it do not quietly turn into a compliance problem eleven months later.

#PowerPlatformPipelines #ManagedEnvironments #ALMGovernance #PowerPlatformLicensing #LicenseComplianceAudit #EnterpriseGovernance

The AI Builder Credits Transition Has a Deadline: November 1, 2026

Finance and IT leaders reviewing Power Platform licensing budget charts on a laptop in an office setting

A Power Platform administrator at a mid-market distributor recently walked into her CFO’s office with a number nobody had budgeted for. Her company’s invoice-processing flow, built on AI Builder’s document processing models three years ago, had been running on credits bundled quietly into a Power Automate Premium renewal. That renewal comes up again in October. She had just learned that whatever gets signed this fall will be the last one to include those free credits at all, and that the resulting seeded credits and add-on option would disappear entirely for anyone who renews after November 1, 2026. Nobody in finance had flagged it as a line item, because for three years it had never been one.

That scenario is becoming common across organizations that adopted AI Builder early, when its credits shipped as a quiet inclusion in Power Apps, Power Automate, and Dynamics 365 licenses rather than a metered, purchased capacity. The AI Builder credits transition Microsoft is now enforcing retires that model outright, and the cutoff sits close enough on the calendar that IT Directors and finance leaders currently mid-negotiation on a Power Platform renewal need to understand it before they sign, not after.

What the AI Builder credits transition actually changes

Abstract illustration of digital credit tokens flowing between two separate licensing systems

AI Builder, the low-code AI layer inside Power Apps and Power Automate that handles document processing, form extraction, sentiment analysis, and prediction models, has historically been funded two ways: seeded credits bundled into premium licenses at no extra cost, and AI Builder capacity add-ons purchased separately when an organization’s usage outgrew the bundled amount. Microsoft’s documentation lists specific seeded allotments: Power Apps Premium includes 500 AI Builder credits, Power Apps per-app licenses include 250, Power Automate Premium and its RPA add-ons include 5,000 each, and Dynamics 365 Finance and Operations includes 20,000. A standalone AI Builder capacity add-on carries 1,000,000 credits.

Starting November 1, 2025, Microsoft closed new-customer sales of AI Builder capacity add-ons and shifted AI Builder features onto a dual-currency consumption model: an environment draws down its AI Builder credits first, and if those run out, the system automatically falls back to Copilot Credits before blocking the operation. Existing add-on customers could still renew and purchase through that window. November 1, 2026 is the harder cutoff. On that date, existing AI Builder capacity add-ons reach end of life: customers with an active add-on keep using the credits tied to it, but can no longer renew it or buy a new one. Separately, any Power Platform or Dynamics 365 license purchased or renewed on or after that date stops receiving seeded AI Builder credits altogether. If your renewal lands in September or October, you’re likely getting the last cycle that includes them at no incremental cost. If it lands in November or later, that inclusion is gone for the new term.

Microsoft has been explicit that it will honor entitlements already under contract. Licenses and add-ons purchased before the cutoff keep their credits for the remainder of that specific contract term, whatever length that is. What changes is the next renewal, not the current one already in force. That distinction matters enormously for budget planning, because it means the financial exposure isn’t immediate for most organizations. It arrives at whatever renewal date happens to fall after November 1, and for some finance teams that’s uncomfortably close.

Why this is a budgeting problem, not a technical one

The mechanically important detail, and the one most likely to catch a finance team off guard, is that there is no automatic conversion between the two credit systems. Microsoft’s own documentation states plainly that AI Builder credits and Copilot Credits are separate currencies with separate consumption rates per action, and unused AI Builder credits don’t roll over or translate into an equivalent number of Copilot Credits when the seeded allotment disappears. An organization that has been running document processing workloads for years on a bundled 20,000-credit Dynamics 365 F&O allotment, or a 5,000-credit Power Automate Premium allotment, needs to separately estimate what the equivalent workload costs once it draws exclusively on purchased Copilot Credits, because the published rate cards for the two currencies aren’t set up to produce the same effective cost per document or per prediction. Assuming last year’s consumption simply carries forward at the same dollar cost is the exact assumption this transition breaks.

This is where the business risk actually lives. AI Builder adoption inside Dynamics 365 F&O and Business Central environments tends to concentrate in exactly the processes finance departments care most about protecting: accounts payable invoice capture, receipt and expense processing, contract data extraction, vendor document classification. These are high-volume, repetitive workloads that were attractive to automate specifically because the seeded credits made the marginal cost of processing another document effectively zero. Once that seeded allotment is gone, the marginal cost stops being zero, and depending on volume, it can become a meaningful new operating expense that nobody modeled into the automation’s original ROI case.

What CIOs, CFOs, and Power Platform administrators should do before their next renewal

The first step is straightforward but frequently skipped: pull actual AI Builder consumption data from the Power Platform Admin Center, under Licensing and Capacity add-ons, before the renewal conversation starts rather than during it. Monthly consumption resets and doesn’t accumulate, so a single month’s snapshot understates volume during seasonal peaks like month-end close or year-end 1099 processing. Look at a full quarter, not a spot check.

The second step is checking renewal timing against the cutoff with more precision than “sometime this year.” A Power Automate Premium license renewing October 15 keeps its seeded credits for that full new term even though the term extends past November 1, since Microsoft’s honoring rule is tied to the contract’s start date, not to a mid-term calendar boundary. A license renewing November 15 does not get that benefit. For organizations with renewal dates close to the line, it’s worth confirming the exact contractual start date with a Microsoft partner or account team rather than assuming based on the calendar month alone.

Third, for teams that expect to keep growing AI Builder-dependent automation rather than shrinking it, purchasing or renewing an AI Builder capacity add-on before November 1, 2026 locks in access to that add-on’s credit pool and its associated rate for as long as the add-on contract runs, even though new add-on purchases stop being available afterward. That’s a genuine one-time window, not a recurring option, and it’s worth evaluating now rather than assuming it will still be available closer to the deadline.

Finally, this is a reasonable moment to model Copilot Credit costs for AI Builder workloads specifically, rather than treating Copilot Credits as an abstract budget line shared across every AI feature in the tenant. Document processing, form extraction, and prediction actions each draw against Copilot Credits at their own published rate once AI Builder credits are exhausted, and an organization running several automated document workflows across F&O, Business Central, and Power Automate should size that consumption separately from whatever Copilot Studio agent or Copilot chat usage is already drawing from the same pool. Treating them as one undifferentiated bucket is how a finance team ends up with a Copilot Credit shortfall it didn’t see coming from an entirely different application.

None of this requires panic, and it doesn’t require ripping out working automation. It requires treating a licensing calendar date the way a solution architect would treat any other deprecation notice: as a planning input with a hard date attached, not a vague future concern. At Routeget Technologies, the licensing transitions we’ve helped clients navigate tend to follow the same pattern: the technical migration is manageable, but the budget surprise is what actually causes friction with finance. Getting ahead of the renewal date, and getting real consumption numbers in front of the people who sign the contract, is what turns this from a surprise into a line item.

#DynamicsAIBuilder #CopilotCredits #PowerPlatformLicensing #ERPBudgetPlanning #EnterpriseAI #FinanceAutomation