Dynamics 365 storage limits start to bite on 9 November: what gets blocked, how to get out
From 9 November, Dynamics 365 tenants over their Dataverse storage lose copy and restore straight away, then sandboxes close on a 30-day and 90-day clock. Here's how to read your numbers, what each fix really costs, and how long it takes to show.
part 8 of 9 · Running enterprise platforms wellthe ideaGo over capacity and a clock starts. Production stays open, sandboxes don't.
after reading, you can- Read your three storage numbers after borrowing, because that's the figure Microsoft acts on
- Pick a fix for each bucket once you know how long it takes to show and what it'll cost you
- Plan releases around day 0, day 30 and day 90 so a sandbox never closes mid-test
Starting 9 November 2026, Microsoft begins acting on Dynamics 365 tenants that use more DataversedefinitionThe database under Dynamics 365's customer apps. Rows, attachments and logs each have their own bucket, and you pay for each one. storage than they've paid for. Check your database, file and log numbers in the Power Platform admin center now, because going over blocks copies and restores straight away and locks sandboxes out on a 30-day and 90-day clock.
Microsoft is starting to enforce the storage limit your Dynamics 365 licences come with
Your Dynamics 365 subscription comes with a set amount of storage, split into three buckets. Until now, a tenant that drifted over got warning emails and lost copy and restore, while everything else kept running. From this rollout, going over has a schedule attached. Admins can't copy or restore environments from the first day. Test copies of your system, called sandboxes, go admin-only after 30 days and get switched off after 90. Your live system stays open through all of this, and Microsoft says the data in a disabled sandbox is kept. Someone has to look at the numbers, then clean up, archive or pay.
Think of a self-storage contract with a limit you've been quietly over for years. The live unit stays open, but the manager stops letting you rent another unit or roll back to an older one. Your spare units get locked after a while. Your boxes aren't thrown out, though you can't get at them until the bill matches what you're using.
- Dynamics 365 and Power Platform admins
- CIOs and owners of a CRM budget
- Release managers who rely on sandboxes
- Microsoft 365 billing admins
- Partners who manage a client tenant
Why it matters to you
It's tempting to stop at "production isn't affected", and that's true as far as sign-in goes. People keep working. What you lose is your way back. Microsoft won't restore a backup directly onto production: you switch it to a sandbox, restore, then switch it back. Restore needs free capacity, so a tenant that's over can't do it. Picture a bad release on a Friday night with that door shut.
The sandbox stages hurt in a different way. Testers lose access to UAT at day 30, which can land in the middle of a release. Refreshing a sandbox from production stops at day 0. A Sikich consultant described that failure back in 2020, telling a client a production copy wouldn't go over a sandbox because "your tenant is over the limit on data capacity", so the block itself isn't new. The clock on sandboxes is.
-
01 Warnings at 85% and 95%
Emails go out every week, and banners show up in the admin center and the apps. Nobody can opt out of them or hand them to a colleague.
-
02 Day 0: restricted
Past 100%, nobody can create, copy, restore or recover an environment. That goes for production and sandbox alike. Everyone can still sign in.
-
03 Day 30: administration mode
Only admins get in now, and testers without an admin role get turned away. A tenant admin can switch the mode off again, but that doesn't stop the clock.
-
04 Day 90: disabled
Nobody signs in to affected sandboxes, admins included. The data is kept. Microsoft Support will only help with export, and possibly recovery.
-
05 Back under 100%
Nothing else gets restricted, but nothing switches back by itself. An admin has to exit administration mode or re-enable each sandbox by hand.
It's easy to read the limit as three separate numbers. It doesn't work that way. Spare database capacity can cover a log or file shortfall, and spare log can cover file, but never the other way round. So a tenant only counts as over once that borrowing has run out. Microsoft's own example has 100 GB of database with 95 used, and 20 GB of log against a 10 GB entitlement. Database lends its spare 5 GB and the tenant is still 5 GB over, even with 200 GB of file storage sitting idle.
What Microsoft changed, and what it left alone
The change at a glance
A sandbox goes admin-only at 30 days and gets disabled at 90, counted from the day you first went over. Get back under 100% before a stage hits and it won't go any further.
Microsoft's docs already listed these as unavailable over capacity. The notice now spells it out as stage 1, on both sandbox and production environments, for as long as the tenant stays over.
Microsoft says its notices will give the date you first went over and what's coming next. Plan around that date, because it's your clock.
Production doesn't go through this rollout's administration mode or disablement, so users keep working. Microsoft's licence terms do still allow suspension for overuse, with reasonable notice.
A sandbox with active pay-as-you-go billing doesn't move through the stages, even when the tenant stays over. Your other sandboxes still do, so it's a per-environment escape.
If you have any Dynamics 365 Finance and Operations environment or consumption, this rollout doesn't apply to you. Microsoft scopes it to Dataverse-only tenants.
Dates to keep straight
- 30 Sep 2026Notice published
The same text goes out under several IDs, including MC1483519, MC1483524 and MC1483529. Search by title if you can't find yours.
- 26 Oct 2026Latest update
This is the version to trust. It has 90 days and the 14 December finish, so replace any older dates.
- 9 Nov 2026Rollout begins
It can reach your tenant any day between now and 14 December, so don't wait for the last week.
- 14 Dec 2026Rollout complete
Every in-scope tenant should have validation by now.
- T0 + 30 daysAdministration mode
Affected sandboxes go admin-only.
- T0 + 90 daysDisabled
Nobody can get into an affected sandbox now, though your data is kept. Fix the overage and an admin can bring it back.
One thing Microsoft doesn't make plain is when T0definitionMicrosoft's label for the day a tenant first goes past 100% of its capacity, after borrowing. The 30 and 90 days count from there. starts for a tenant that's already over on rollout day. The stage table counts from when the tenant first exceeds capacity, and the notices promise to show that date. Don't assume you get a fresh 90 days from whenever rollout reaches you. Read the date in your own notification and plan from it.
It also doesn't say whether background work carries on in a sandbox that Microsoft puts into administration modedefinitionOnly admins can sign in while it's on, and Microsoft's docs name System Administrators and System Customizers. Everyone else gets kept out, and that usually means your testers.. When an admin sets that mode by hand, background operations are a separate switch. Nor does it say what happens to integration accounts that aren't admins. If a sandbox feeds anything downstream, test this before day 30 instead of finding out then.
Your options, and how long each one takes
Timing is what catches people out here. Nothing below takes effect the moment you click. You'll probably need more than one: a quick fix to stop the clock and a slower one to stay under.
| Option | How soon it shows | What it costs | The catch | Pick it when |
|---|---|---|---|---|
| Delete data or environments | Up to 72 hours in reports | Nothing, apart from what you delete | Hard to undo. Check legal holds first | Old logs, test data and forgotten sandboxes |
| Long-term retention | 72 to 96 hours to run, then 24 hours or more for reports, up to two weeks outside production | No extra storage purchase | One way, read-only, Managed Environment only. No file savings, no audit tables | You have to keep old records but nobody edits them |
| Capacity extension | Banner confirms it once on | No charge mentioned | 25% of what you use, for 45 days, three times in 365 days. Needs over 80% used, and only helps if 25% covers the deficit | You need time while procurement runs |
| Buy capacity | After purchase, in the Capacity page | $40 per GB a month for database, paid yearly, on Microsoft's price page | Buy the bucket that's short. File can't fix a database deficit | What's left is real business data |
| Pay-as-you-go | Once the environment is linked | $48 per GB database, $2.40 file, $12 log, monthly, on Microsoft's meter page | Bills the whole environment if no capacity is allocated. Sandbox only for the clock | One sandbox has to stay open right now |
Watch the pay-as-you-go bill. It looks like a cheap way to save a sandbox, but the meter doesn't charge only for your overage. With no capacity allocated to the environment, everything past the first free 1 GB of database and 1 GB of file goes to Azure, plus any log usage. Do that sum for your sandbox's real size before linking it. At Microsoft's published $48, a sandbox holding 50 GB of database with nothing allocated comes to 49 times that, about $2,350 a month, and your contract may differ. If the tenant has spare capacity in that bucket, allocate some first and only the excess gets billed. If it doesn't, expect most of the sandbox on the bill.
Neither the notice nor the docs say that pay-as-you-go lifts the tenant-wide block on copy and restore. The notice says those stay blocked while the tenant is over. Microsoft Learn says linking a sandbox "removes overage restrictions", which sounds broader. We'd read that as covering the sandbox's own lifecycle, and we'd test a copy before promising anyone it works.
Deletion has its own trap, and it's the one we'd worry about most. Environment recovery is on the blocked list too. Delete the wrong sandbox to clear space while you're still over, and you can't bring it back until the tenant is under again. Microsoft gives you seven days to recover most deleted environments, and up to 28 for production environments with Dynamics 365 apps. Get the owner's sign-off before you delete anything, because those windows won't help you while the tenant is over.
- Weekly emails that are easy to ignore
- Copy and restore already refused over capacity
- Sandboxes stay open however long you're over
- No date attached to the overage
- Notices name your T0 and your current stage
- From day 0 nobody can create, copy, restore or recover an environment
- Testers get locked out of affected sandboxes at day 30, then everybody does at day 90
- Getting back under isn't enough: an admin still has to reopen each sandbox
Find where the space went
Open the Power Platform admin center, then Licensing, then Dataverse or Capacity add-ons. Summary shows the tenant position and the top environments. The per-environment details show top tables and how they've grown. You need to be a tenant, Power Platform or Dynamics 365 admin to see Summary, and if you bought through a partner, they're the one who handles capacity.
The usual suspects, from Microsoft's cleanup docs
- 01Copied sandboxes nobody came back to
Every full copy brings along the data and search indexes, and they rarely get cleaned up afterwards. Start here, since deleting one forgotten copy can beat weeks of row cleanup.
- 02Audit logs and plug-in traces
AuditBase and PlugInTraceLogBase sit in log. Long-term retention doesn't cover audit tables, so the real choices are to export and delete, or buy. Delete by table, access type or date. Deleted audit history is gone for good.
- 03System jobs and workflow logs
AsyncOperationBase and WorkflowLogBase grow with every workflow that runs. Set up a recurring bulk delete for completed jobs, and turn on automatic deletion of completed background workflow jobs so they don't pile up again.
- 04Email and activities
ActivityPointerBase, EmailBase and ActivityPartyBase fill up through server-side sync, and attachments land in file. Long-term retention suits old activities you can't delete.
- 05Search indexes
The DataverseSearch table grows with every column you index. Take low-value tables and columns out of Dataverse search, especially in dev and test.
- 06Look at the storage advisor
This preview feature is rolling out slowly. If you can see it, it estimates what you can reclaim per table and offers an archive policy or a bulk delete. If you can't, use bulk delete and retention policies directly.
Reports lag, and sometimes the space doesn't come back by itself. One Dynamics consultant who blogged an audit log cleanup saw log usage fall from 954 MB to 460 MB after two hours, then to about 5 MB after a day. In an earlier post the same author deleted all but one activity record and ActivityPointer still showed 13 GB, until a support ticket got a backend script run against the table. Don't judge a cleanup on the same afternoon, and don't assume deleted rows give the space back quickly. Microsoft also warns that removing 10 MB of data won't necessarily free 10 MB.
To size a purchase, Microsoft gives a formula: effective deficit, plus expected growth, plus a buffer, minus cleanup you've confirmed that hasn't reached the reports yet. Buying only today's deficit puts you back in the same place a few months on.
Before: three buckets, one shared pool
Production and two sandboxes all draw on the tenant's capacity. Spare database can cover log and file, so one full copy can push the whole tenant over.
After: smaller sandboxes and a retention policy
The dev sandbox is rebuilt as a customizations and schemas copy, old records move to long-term retention, and UAT gets allocated capacity with an alert before it fills.
What to do now, by role
Who does what before and after 9 November
- Ask IT one question: are we over 85% on database, file or log, and what's our first-over date?
- Name one person who owns storage, since warnings go to several roles and nobody assumes it's theirs.
- Agree a small budget for capacity now, so a late purchase doesn't hold up a release.
- Write down each bucket's number from the Summary tab, with and without borrowing. You'll need both.
- Download the environment list and sort by size. Mark every sandbox with an owner or a delete date.
- Delete or archive what you can now, since reports can take 72 hours or more to catch up.
- Watch for the notice with your first-over date, then put day 30 and day 90 on the release calendar.
- Don't count on a sandbox refresh next week until the tenant is clearly under capacity.
- Test what your UAT flows and integration accounts do in administration mode, before day 30 does it for you.
- Move dev work to customizations and schemas copies, so sandboxes stop carrying full production data.
- Find out how you bought, because direct, Enterprise Agreement, Volume Licensing and CSP customers all buy capacity differently.
- Price each add-on on its own, since you only need the bucket that's short. Direct purchases run from one month to three years.
- Get an Azure subscription and budget owner ready, in case one sandbox needs pay-as-you-go.
Keep it from happening again
Durable fixes
- 01Set alerts on the sandboxes
In Manage capacity you can allocate capacity to an environment and get daily emails when it hits a set percentage. Sandboxes are where growth surprises you, so start with those.
- 02Stop making full copies by default
A customizations and schemas copy brings users and schema without business data. Keep full copies for UAT and upgrade testing, and leave audit logs out unless someone needs them. They're excluded by default.
- 03Put cleanup on a schedule
Run recurring bulk deletes for finished system jobs, imports and old trace logs. Test the criteria in a sandbox first and check the job results every so often, because a failed job won't fix itself.
- 04Add retention policies for old records
Long-term retention needs a Managed Environment, so check that before you plan on it. Compression averages about 50% on database and does nothing for files, and retained rows can't come back to live.
- 05Decide how long audit data lives
Log keeps growing with usage until someone sets a limit. Agree a retention period with compliance, export what you must keep to your own storage, and delete the rest on that schedule.
If it goes wrong
When you're over, or a sandbox has already closed
Most of this is timing and paperwork. Get the facts first, buy yourself time, then fix the numbers and reopen by hand.
- 01Get the factsfirst hour
- Find your first-over date in the notice if you've had one, and write down what each bucket shows on Summary.
- Work out which bucket is really short once borrowing is counted. You can't fix a database deficit by buying file.
- Let the release and test teams know which sandboxes are affected, and when the next stage hits them.
- 02Buy timesame day
- If you're over 80% used, turn on the capacity extension. Check that the banner says it's active before you move on.
- If one sandbox has to stay open, link it to pay-as-you-go. Allocate capacity to it first if you have any spare, and check that the link took.
- A tenant admin can exit administration mode, one sandbox at a time, so testers can finish. The clock doesn't stop.
- 03Clear the overagefirst week
- Delete in order of safety: forgotten copies, finished system jobs, old traces, then audit logs once they're exported.
- Start retention policies for records you have to keep, and allow up to a week for reports in production, two in a sandbox.
- Buy more of whichever bucket is still short. Microsoft's formula leaves room for growth, so use it.
- 04Reopenonce under 100%
- Have a tenant admin exit administration mode on each sandbox. Nothing returns to its earlier state on its own.
- Re-enable any disabled sandbox from the admin center, one at a time, after validation shows you're under.
- Open a Microsoft Support ticket if you need data from a disabled sandbox while you're still over. Export is what they'll help with at that stage, and one Learn passage adds recovery.
- 05Learnthis month
- Write down which table or environment pushed you over, and add a recurring job or alert for it.
- Put the capacity review on the same calendar as your release cycle.
What this could look like in your tenant
Four illustrative situations
- the setup
- A company runs Dynamics 365 Sales with one production environment and one full-copy sandbox. Database sits a few GB over entitlement, and the warning emails go to someone who has left.
- what happens
- Stage 1 applies from the start. Nobody notices until a sandbox refresh fails, and at day 30 the sandbox goes admin-only with a change half tested.
- what to do
- Fix the mailing problem first by giving a current admin the right role. Delete the old sandbox copy if nobody needs it, then rebuild it smaller once the numbers are under.
- the setup
- Customer Service has run with auditing on across most tables for years. Log is at 20 GB against a 10 GB entitlement, and database has only 5 GB spare to lend.
- what happens
- After borrowing, the tenant is still 5 GB over. Spare file capacity doesn't help, and long-term retention won't take audit tables. Compliance wants the history kept.
- what to do
- Agree a period with compliance, export the older audit data to storage you own, then delete by date. Cut auditing on tables nobody reviews, and buy log capacity if the rest is required.
- the setup
- A Field Service team is three weeks into user testing when the tenant reaches day 30. Testers aren't admins, and procurement says new capacity needs another month.
- what happens
- Testers are locked out overnight. A tenant admin can exit the mode, but the 90-day clock doesn't stop, and that environment still can't be refreshed.
- what to do
- Exit administration mode so testing can finish, and enable a capacity extension if you qualify. If you link the sandbox to pay-as-you-go instead, work out the bill first, because a tenant that's over might have nothing spare to allocate.
- the setup
- A tenant's log is over its own 10 GB, fully covered by spare database, so Summary shows no deficit. Then a planned copy from production to sandbox is refused.
- what happens
- Notifications and stages use the numbers after borrowing, but copy needs room in the actual bucket. The admin spends a day hunting for an overage that isn't on the report.
- what to do
- Check each bucket on its own, without borrowing. Free up or buy enough to leave at least 1 GB of real room in the one that's short, then run the copy again.
How Cohash helps
We look at the tenant's numbers before anyone buys anything, work out which tables and sandboxes caused the overage, and sort data into delete, retain and keep, with compliance signing off. Then we set up the recurring jobs and alerts so it doesn't creep back. See our Dynamics 365 work, the engineers we place on Dynamics projects, or start with a free assessment. If you're also sorting out apps built in Teams, our Dataverse for Teams guide covers how those upgrades land on the same capacity.
What to take from this
- 01
Over 100% after borrowing means no create, copy, restore or recover, from day 0, on production as well as sandboxes.
- 02
Affected sandboxes go admin-only at day 30 and shut at day 90. Production stays open, but you lose your restore route.
- 03
Trust 90 days and 14 December. If you see 60 days and 4 December, someone's working from an old copy.
- 04
Start cleanup early. Deletes take up to 72 hours to show in reports, and retention policies can take a week in production, two in a sandbox.
- 05
Work out the bill before you link pay-as-you-go. With no capacity allocated, it charges for nearly the whole environment.
- 06
Nothing reopens itself. An admin has to bring each sandbox back once you're under.
01Does the Dynamics 365 storage validation affect production?
People keep signing in and working, because production doesn't go through this rollout's administration mode or disablement. Admins still can't create, copy, restore or recover environments while the tenant is over. That includes restoring a backup onto production, which runs through a sandbox switch.
02Is my tenant in scope?
Microsoft scopes it to Dataverse-only tenants running Dynamics 365 Sales, Customer Service, Field Service, Customer Insights, Customer Voice, Contact Center or Project Operations on Dataverse. If you have any Finance and Operations environment or consumption, you're out of scope. Rollout reaches tenants between 9 November and 14 December 2026.
03How do I check how much Dataverse storage we've used?
Go to Licensing in the Power Platform admin center, then Capacity add-ons or Dataverse. Summary gives you the tenant position and the biggest environments, and each environment's details list its top tables. You need a tenant, Power Platform or Dynamics 365 admin role to see Summary.
04Is it 60 days or 90 days before a sandbox gets disabled? I've seen both.
90. A copy of the notice posted on 30 September said 60, and it's still online. Microsoft's current notice and its Learn page both say 90 days from when the tenant first goes over, with administration mode at 30.
05Will Microsoft delete a disabled sandbox's data?
Microsoft says the data is retained and available for recovery after you fix the overage, though it doesn't say for how long. While you're still over, Microsoft Support will only help with export options, and one Learn passage adds recovery. Get back under, then re-enable the sandbox yourself.
06What's the fastest way to stop the clock?
If you're over 80% used, a capacity extension adds 25% of what you use for 45 days, which only helps if that covers your deficit. You get three in 365 days. Buying add-ons is the lasting fix. Deletes take up to 72 hours to show. Microsoft doesn't say whether an extension resets T0 when it lapses, so plan as if it doesn't.
07Does pay-as-you-go solve the storage overage?
It takes that one sandbox out of the 30 and 90-day stages, even with the tenant still over. Other sandboxes keep moving through them. With no capacity allocated, it also bills nearly all of that environment's storage to Azure, so work out the cost first.
08Do developer or Teams environments count?
No. Trial, preview, support, developer and Teams environments don't count toward tenant capacity and can show 0 GB. Default, production and sandbox environments do count. The default environment comes with 3 GB of database, 3 GB of file and 1 GB of log included.
Three questions, about a minute
Pick an answer and we'll tell you if it's right, and why it is or isn't. The score stays in this browser.
-
Q1Your tenant has been over capacity for 40 days and a bad release just hit production. What's your problem?
show the answer
B. You can't restore, because that needs free capacity and you've got none Production stays reachable, but restore is on the blocked list. You also have to switch production to a sandbox type to restore onto it, and the restore needs free capacity you don't have.
-
Q2Log is 10 GB over its entitlement. Database has nothing spare, and file has 200 GB spare. Are you over?
show the answer
C. Yes, because file can't lend to log Capacity only flows from database to log to file. Spare file storage can't cover a log shortfall, so the 10 GB deficit stands.
-
Q3You got back under 100% last night. It's the morning and your UAT sandbox is still admin-only. What's going on?
show the answer
D. Nothing comes back by itself, so an admin still has to exit the mode Microsoft is explicit that environments don't go back to their earlier state automatically. An admin exits administration mode, or re-enables the sandbox, one environment at a time.