Dataverse storage validation from 9 November 2026: stages, deadlines and options

By Tobias LehmeierPublished Facts as of:

Microsoft is introducing “Dataverse storage validation”. From 9 November 2026, Microsoft restricts tenants that are over their storage entitlement in fixed stages; the rollout is expected to be complete by 4 December 2026. This article summarizes what Microsoft has published on Microsoft Learn and in the message center, who is affected and which options you have.

What changes

Until now, exceeding capacity mostly meant banners and e-mails. Individual operations were blocked, such as copying an environment when less than 1 GB was free in the required storage type. The storage validation adds fixed stages with deadlines.

What counts is effective consumption. Dataverse distinguishes three storage types: database, file and log. Before Microsoft determines an overage, unused capacity is borrowed, but only in one direction: unused database capacity covers log and file, unused log capacity covers file. A database deficit can therefore only be offset with database capacity.

Stages and deadlines

Stages of the storage validation
StageStartsConsequences
Early notificationeffective consumption over 85%informational and warning notifications
Stage 1: Restrictedfirst day over 100% effective consumption (“T0”)creating, copying and restoring environments blocked, including recovering deleted environments
Stage 2: Administration mode30 days after T0affected sandboxes available to administrators only
Stage 3: Disabled60 days after T0 according to the message center post, 90 days according to Microsoft Learnsign-in to affected sandboxes blocked for everyone, including administrators; environment and data are retained

Microsoft gives two deadlines for stage 3. Message center post MC1483519 (last updated 5 October 2026) says 60 days, Microsoft Learn says 90 days (English version updated 7 October 2026, German version 8 October 2026). Until Microsoft aligns the two, it is safer to plan with 60 days.

An example: if T0 falls on 9 November 2026, stage 2 starts on 9 December 2026 and stage 3 on 8 January 2027 (60 days) or on 7 February 2027 (90 days). Microsoft does not describe how it sets T0 for tenants that are already over 100% before the rollout. According to the message center post, the notifications state the date of the first overage and the current stage.

The restrictions end as soon as the tenant is back below 100%; an administrator then re-enables disabled sandboxes. You can take a sandbox out of administration mode in the meantime; the deadline keeps running. In the German interface, the mode is called “Verwaltungsmodus”.

Affected tenants and exceptions

Affected are Dataverse-only tenants, meaning tenants without Dynamics 365 Finance and Operations environments or consumption. Microsoft lists these products: Dynamics 365 Sales, Customer Service, Field Service, Customer Insights, Customer Voice, Contact Center and Project Operations (Dataverse deployments).

Not affected, or affected differently:

  • Tenants with finance and operations environments or consumption are out of scope.
  • Production environments do not enter administration mode and are not disabled. Copying and restoring are blocked for them too, though: as long as the tenant is over 100%, you cannot refresh a sandbox from production or restore a backup.
  • Sandboxes with active pay-as-you-go do not go through the stages. Other sandboxes in the same tenant can still be restricted.
  • According to Microsoft, trial, preview, support, developer and Teams environments do not count toward the tenant’s consumption.

Microsoft does not say explicitly whether Power Apps-only tenants without the Dynamics 365 products listed are affected.

Your options according to Microsoft

Options for an overage
OptionWhat it achievesWhat to keep in mind
Free up storage (delete)permanently lower consumption, no ongoing costsirreversible; the capacity report shows the effect only after up to 72 hours. If “Keep deleted Dataverse records” is turned on, deleted rows keep counting for up to 90 days
Long-term retention (Langzeitaufbewahrung)data stays read-only in Dataverse and takes up about 50% less database capacity on averageonly in Managed Environments; no audit or elastic tables; attachments do not get smaller; cannot be reversed; a run takes 72 to 96 hours, and the report follows 24 hours later at the earliest
Buy capacitycloses the deficit predictablyongoing costs; only the missing storage type helps: file capacity does not resolve a database deficit
Pay-as-you-go for individual sandboxesthe linked sandbox is exempt from the stagesbilled through an Azure subscription; without allocated capacity, only 1 GB of database and 1 GB of file storage per environment are free, and log storage costs from the first GB (list price on Microsoft Learn: $12 per GB per month)
Capacity extensiona reprieve of 25% of consumption for at most 45 daysonly from 80% consumption, at most three times in 365 days; afterwards the blocks apply again
Delete unused environmentsthe whole environment is freedrecovery only within 7 days (production environments with Dynamics 365 apps: 28 days) and, depending on the environment type, only with free capacity; blocked in stage 1

Reallocating capacity between environments does not help. According to Microsoft, it changes neither the tenant’s entitlement nor a deficit.

Checklist: five steps before 9 November

  1. Read your figures per storage type. Note entitlement and usage for database, file and log separately and work out the borrowing yourself (see box). A log overage is only covered as long as database capacity is free.
  2. Identify the largest tables. Microsoft’s cleanup guidance names, among others, AuditBase (log), AsyncOperationBase and WorkflowLogBase (database), and AnnotationBase and Attachment (file). Also check sandboxes that were created as full copies of production.
  3. Schedule operations that need copying or restoring. Sandbox refreshes, restore tests and new environments for projects should not fall into a possible blocked period. Inform administrators, developers and users about the possible restrictions.
  4. Start with low-risk cleanups. Completed system jobs, import history, old duplicate detection jobs and the plug-in trace level are starting points documented by Microsoft with comparatively low risk. Delete audit logs only once it is clear how long you must be able to prove changes. Microsoft recommends keeping them in your own storage.
  5. Decide the rest with a date and an owner. Buying the missing storage type, pay-as-you-go for individual sandboxes or a capacity extension as a stopgap. Allow for the fact that Microsoft shows the effect of deletions only after up to 72 hours.

Sources