Leaving a general-purpose v1 storage account alone is treated as consent, and the unattended upgrade lands in Hot

Azure retires the general-purpose v1 storage account type in October 2026. Whatever is left is upgraded to general-purpose v2 automatically, permanently, onto transaction pricing that differs, and Microsoft records the absence of a decision as consent. The default access tier, which decides the bill afterwards, is a parameter of the deliberate upgrade that the automatic one cannot ask anyone for.

Last verified: 2026-08-20.

What the vendor says

Microsoft's general-purpose v1 retirement overview prints one warning twice: "If you do not migrate your general-purpose v1 storage account to GPv2 by October 2026, all existing general-purpose v1 accounts will be auto migrated over to a GPv2 account, which may result in higher billing costs." Both copies carry the same follow-up: "Your decision not to migrate an existing general-purpose v1 account will be construed as consent for Microsoft to migrate the account on your behalf."

The same page adds "Upgrading to GPv2 is permanent." The retirement FAQ gives the direction and its own counterweight in the same answer: "General-purpose v1 has lower transaction prices than GPv2.", "General-purpose v1 has slightly higher capacity prices than GPv2." and "For most workloads, GPv2 is cheaper overall once per-blob tiering and optimized capacity pricing are factored in." Which of those wins on a given account is decided by its operation counts, not by the account kind.

Where the vendor pages disagree

Three questions get different answers on different pages. The third decides this memo.

Why it is easy to get wrong

An administrator reads the retirement page, sees that Microsoft migrates the account anyway, reads the reassurances below it, and files October 2026 as a platform event. What that reading misses sits on the upgrade page: "If you don't specify an account tier during upgrade, the default account tier of the upgraded account is Hot."

What the misreading costs

Every unattended account arrives in Hot because nobody named a tier. The accounts still on that type in 2026 tend to be unowned: boot diagnostics containers, retired log sinks, the dumping ground a script from 2017 still writes to. Whether that costs anything is a question about the individual account: Microsoft warns that costs may rise for workloads "with high read, write, or list operations" and that cold data should not be left in the hot tier, and only that account's own monthly operation counts say whether it matches.

Correcting the tier afterwards costs a full pass over the data: hot to cool is charged as "a charge equal to writing all the data into the cool tier", and the reverse as a read of the whole account.

How to check it

Microsoft publishes this inventory query. Run it in Azure Resource Graph Explorer scoped to the directory, not one subscription. Every column is control-plane metadata and nothing here writes.

// Microsoft's inventory query from the GPv1 retirement overview, projection shortened. Read only.
Resources
| where type == "microsoft.storage/storageaccounts"
| where sku.name in~ ("Standard_LRS", "Standard_GRS", "Standard_ZRS", "Standard_RAGRS", "Standard_RAGZRS")
| where kind != "StorageV2"
| project name, kind, sku, location, resourceGroup, subscriptionId, managedBy, tags

One row per account. kind splits the two tracks it returns: Storage is general-purpose v1, and BlobStorage is the legacy blob account, whose own page states both outcomes without reconciling them, automatic migration to GPv2 and "After the retirement date, data access will be blocked for all legacy blob storage accounts."

Zero rows is not automatically good news: "No results are returned if you don't have at least read permissions to the Azure object or object group", so thin rights give a short list, not an error. Reconcile the distinct subscriptionId values against the subscriptions expected. Reader is enough: its action list is one entry, */read.

Recommendation

Decision: Act now, on the inventory and the tier choice. One date forces it: retirement with automatic migration on 13 October 2026. September 2026 bounds the tooling rather than the estate, because from that month the Azure Resource Manager API stops accepting new general-purpose v1 accounts, so a template or pipeline that still creates one fails. The FAQ closes the alternative: "No. Microsoft won't grant exceptions."

Act now does not mean upgrade everything this week. The query runs now, every account it returns gets an owner, and each gets one answer: which access tier suits the data in it, read from monthly operation counts in Cost Analysis. Accounts needing batching or lifecycle rules first are scheduled. The third outcome is what remains when nobody acts.

flowchart TD
  accTitle: Per account decision tree before the October 2026 retirement
  accDescr: An account row is classified by kind, redundancy, operation profile and whether a tier was chosen. Two branches end in Act now and Schedule; the third is reached only when nobody acts, and the edge into general-purpose v2 is one way.
  A[Account row] --> DBX{Databricks managed group}
  DBX -->|yes| OUT[Out of scope, Microsoft migrates]
  DBX -->|no| K{Value of kind}
  K -->|BlobStorage| LB[Legacy blob, access blocked]
  K -->|Storage| Z{sku.name is Standard_ZRS}
  Z -->|yes| RED[Platform picks the redundancy]
  Z -->|no| OPS{Read, write or list heavy}
  OPS -->|not known yet| M[Measure operations first]
  M --> OPS
  OPS -->|yes| SCHED[Schedule, batch and tier first]
  OPS -->|no| TIER{Tier chosen}
  TIER -->|yes| ACT[Act now, upgrade with a tier]
  TIER -->|no| HOT[Hot by default, not selected]
  LB --> ACT
  RED --> ACT
  HOT -->|nobody acts| G2[13 October 2026, retirement]
  G1 --> G2[13 October 2026, retirement]
  G2 --> AUTO[Automatic migration, what remains]
  ACT -->|permanent| V2[General-purpose v2]
  SCHED -->|permanent| V2
  AUTO -->|permanent| V2

Trade-offs

Acting early costs the measurement, and that read is per account. On an estate of small forgotten accounts the measurement is the whole job, and skipping it to pick Hot deliberately costs the same as doing nothing.

Waiting costs optionality rather than money, since the upgrade is free. Afterwards the kind cannot be reverted, the tier is Hot until someone pays a full pass over the data, and redundancy may have been chosen for the account.

Where it does not apply

The billing change reaches Blob Storage only: "Converting a storage account from GPv1 to GPv2 changes how Blob Storage is billed, but it does not impact pricing for Azure Files or Azure Disks." An account holding only file shares or managed disks appears in the inventory without this exposure. Databricks-managed DBFS accounts are Microsoft's to migrate, an exclusion documented only on the legacy blob page.

Limitations

The inventory query proves what exists, not what it costs. It reads no transaction counts, no capacity and no access pattern, so it cannot name the right tier for any row. Azure Resource Graph is eventually consistent, so a very recent account can be missing, and the query filters on five SKU names that no page calls exhaustive. It was not run against a live subscription for this note.

Two milestones carry no published day, September 2025 for the announcement and September 2026 for the creation block; only 13 October 2026 is published as a day, on the secondary pages. No page read here dates Azure Government or 21Vianet separately.

The Azure cost-control work records a decision like this with the operation counts behind it, so a later invoice question is answered by a document.