# Set the GPv1 tier before Azure finishes the upgrade

> Stop on legacy Standard_ZRS, then choose Hot, Cool, or a recorded auto-migration for each storage account still on kind Storage.

- Canonical: https://www.architecture-logic.com/set-the-gpv1-tier-before-auto-migration
- Published: 2026-10-26
- Updated: 2026-10-26
- Claims verified: 2026-10-26
- Category: Azure architecture
- Tags: Azure, Governance, Architecture Decision Records, Azure Storage

## Revision history

- 2026-10-26 (published): First publication on the GPv1 retirement window and the access-tier decision.
- 2026-10-26 (revised): ZRS is checked first, and the tier claims now cite the page that states them.

## Sources

- [GPv1 storage account retirement overview](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-account-migration-overview) (verified 2026-10-26)
- [GPv1 storage account retirement FAQ](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-account-migration-frequently-asked-questions) (verified 2026-10-26)
- [Upgrade to a general-purpose v2 storage account](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-upgrade) (verified 2026-10-26)
- [General Purpose v1 (GPv1) with ZRS redundancy retirement overview](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-zone-redundant-storage-migration-overview) (verified 2026-10-26)
- [How to upgrade a General Purpose v1 (GPv1) with ZRS redundancy account to GPv2](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-zone-redundant-storage-upgrade-process) (verified 2026-10-26)
- [Legacy Blob Storage account retirement FAQ](https://learn.microsoft.com/en-us/azure/storage/common/legacy-blob-storage-account-migration-frequently-asked-questions) (verified 2026-10-26)
- [Scalability and performance targets for standard storage accounts](https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account) (verified 2026-10-26)
- [Access tiers for blob data](https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview) (verified 2026-10-26)
- [Storage Account Contributor built-in role](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) (verified 2026-10-26)
- [Community policy: Upgrade GPv1 storage accounts to GPv2](https://github.com/Azure/Community-Policy/blob/main/policyDefinitions/Storage/storage-account-upgrade-gpv1-storage-account-to-gpv2/azurepolicy.json) (verified 2026-10-26)
- [Azure Private Link in a hub-and-spoke network](https://learn.microsoft.com/en-us/azure/architecture/networking/guide/private-link-hub-spoke-network) (verified 2026-10-26)

---

General-purpose v1 storage accounts retired on 13 October 2026. If an account still reports kind Storage, Microsoft finishes the upgrade, and none of the retirement docs say which access tier it writes.

The [retirement FAQ](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-account-migration-frequently-asked-questions) treats an account you leave behind as consent for that migration. Data is kept. Access can be interrupted while the work runs. GPv2 prices can show up before the backend conversion finishes, and the FAQ says Microsoft will not grant an exception. When you run the upgrade yourself and omit the tier, the [upgrade article](https://learn.microsoft.com/en-us/azure/storage/common/storage-account-upgrade) says the account becomes Hot.

Hot is a reasonable default for blobs that are read and written through the day. It is a blunt default for an export nobody opens. Write the tier down before the kind changes.

## What you still control

An in-place upgrade is an Azure Resource Manager change of account kind, from Storage to StorageV2. The upgrade article says there is no downtime or data loss and you cannot change the account back. The scale-target page adds that no data is copied, and the retirement overview says data and endpoints remain the same. Azure Files pricing and Azure Disks pricing do not follow the account kind. Blob pricing does.

GPv1 charges less for transactions and a bit more for capacity than GPv2. GPv2 adds hot, cool, cold, and archive for block blobs, and it adds lifecycle management. The [retirement overview](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-account-migration-overview) warns that workloads heavy on reads, writes, or list operations can cost more after the move, and that cold bytes left on Hot are how you waste the lower capacity price. Microsoft links an open-source estimator that uses public prices and ignores your agreement, tax, and reservations. Feed it a month of your own metrics, or do the same comparison in the pricing calculator. A percentage without your transaction mix would be a guess.

Two doc dates disagree about when new GPv1 accounts were blocked. The FAQ, with an ms.date of 30 June 2026, says the portal was already blocked and that ARM creation blocks from September 2026. The upgrade article, ms.date 11 August 2026, says creation was blocked in the first quarter of 2026. Both of those dates are past. The accounts that already exist are the work.

Legacy blob accounts, kind BlobStorage, are on their own retirement. The [legacy blob FAQ](https://learn.microsoft.com/en-us/azure/storage/common/legacy-blob-storage-account-migration-frequently-asked-questions), ms.date 1 July 2026, says October 2026 and does not pin the day to the 13th. Put them on the same inventory list. Do not copy a tier choice onto them until you have read that page. The upgrade article gives it the same command, but the legacy blob FAQ says you migrate to a new account and move the data. Read both before you pick a path.

Bandwidth is a separate reason the kind still matters, and it is not a reason to skip the tier. On the [scale-target page](https://learn.microsoft.com/en-us/azure/storage/common/scalability-targets-standard-account), default GPv1 ingress is 10 Gbps in every region, while default GPv2 ingress is 60 Gbps in a published list that includes USGov Arizona and USGov Virginia, and 25 Gbps elsewhere.

The retirement overview says the retirement takes effect globally across all Azure regions. It does not publish a separate Azure Government date. Run the same inventory in each tenant you operate, including Government, and treat a missing schedule as undocumented rather than as a waiver.

## The rule for each account

Pull the rows, then sort them. One query, scoped where you are allowed to read the management group:

```kusto
Resources
| where type =~ "microsoft.storage/storageaccounts"
| where kind in~ ("Storage", "BlobStorage")
| project name, kind, sku = tostring(sku.name), location,
    resourceGroup, subscriptionId,
    accessTier = tostring(properties.accessTier)
```

The sample query on the retirement overview filters on Standard SKUs and kind not equal to StorageV2, which returns Storage and BlobStorage. This version names the two kinds outright and drops the SKU filter, so a premium account still on kind Storage shows up too.

The branch checks for legacy ZRS first, then for a change window, then sends steady blob traffic to Hot and idle bytes that can sit 30 days to Cool. Figure 1 draws that branch, and the four outcomes below spell it out.

```mermaid
# caption: Stop on legacy ZRS, otherwise pick Hot or Cool, or record an unattended upgrade
flowchart TD
  start[Kind Storage] --> zrs{Standard_ZRS?}
  zrs -->|yes| hold[Confirm region ZRS]
  zrs -->|no| window{Change window?}
  window -->|no| accept[Record auto-migration]
  window -->|yes| rate{Steady blob traffic?}
  rate -->|yes| hot[Upgrade tier Hot]
  rate -->|no| days{Idle 30 days?}
  days -->|yes| cool[Upgrade tier Cool]
  days -->|no| hot
```

For each kind Storage row, pick one outcome and write it down before you change anything.

1. If sku.name is Standard_ZRS, stop. Legacy GPv1 zone-redundant storage is not the modern kind. The [ZRS retirement overview](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-zone-redundant-storage-migration-overview) says GPv2 ZRS replicates synchronously across three availability zones in the region, and GPv1 ZRS does not. The same page says an automatic upgrade moves the account to GPv2 using an equivalent or nearest redundancy the region still offers, which can change the bill and the failure domain. The [ZRS upgrade steps](https://learn.microsoft.com/en-us/azure/storage/common/general-purpose-version-1-zone-redundant-storage-upgrade-process) say a GPv1 ZRS account cannot be converted to or from LRS, GRS, or RA-GRS by the ordinary SKU change, and that a region without GPv2 ZRS cannot take the in-place ZRS upgrade. If the region is not on Learn's list of regions without ZRS, the ZRS upgrade page uses the same in-place command, so run it with the tier from the Hot or Cool outcome. If the region is on the list, open the support request with LRS or GRS as the preferred redundancy, or move the account to a region with ZRS first.

2. If there is no change window this week, accept Microsoft's upgrade and name the person who will read the first GPv2 invoice. The tier stays unknown until that invoice, or until the account properties show one.

3. If the blobs are read or written steadily, upgrade to StorageV2 with access tier Hot. Transaction prices are the part that gets more granular on GPv2. Hot avoids the cool-tier read charge and the 30-day minimum. You still compare a month of transactions with the GPv2 hot meter before you call the outcome acceptable.

4. If most of the bytes sit idle, upgrade with access tier Cool only when those blobs can remain for 30 days. The [access tiers overview](https://learn.microsoft.com/en-us/azure/storage/blobs/access-tiers-overview) sets a minimum retention of 30 days on cool for GPv2, 90 days on cold, and 180 days on archive. Delete, overwrite, or move the blob early and the early-deletion charge applies. Cool is the wrong stamp for a share rewritten every week. Leave that account on Hot, and add a lifecycle rule after the kind has changed, once you know which containers are idle.

Then run the upgrade with the tier in the command. From the upgrade article, PowerShell takes UpgradeToStorageV2 and AccessTier set to Hot or Cool. The CLI sets kind to StorageV2 and access-tier to the same two values. The operation itself is not billed. Changing the tier later is: cool to hot is billed as a read of the data in the account, and hot to cool is billed as a write into the cool tier.

```powershell
Set-AzStorageAccount -ResourceGroupName resource-group -Name storage-account -UpgradeToStorageV2 -AccessTier Hot
```

```azurecli
az storage account update -g resource-group -n storage-account --set kind=StorageV2 --access-tier Cool
```

Substitute the resource group, the account name, and the tier from the outcome. Hot on the first command and Cool on the second are the two legal stamps, not a sequence. The upgrade article says the account access tier applies only to block blobs, so for an account that mostly holds page blobs or files the tier barely matters.

A fictional Standard_ZRS account takes outcome 1 and does not take a tier until someone confirms the region. A fictional build cache on the same subscription, rewritten daily, takes outcome 3 and tier Hot, however large the bytes look. A fictional diagnostic-export account, kind Storage and Standard_LRS, written once and read rarely, takes outcome 4 and tier Cool. None of those three is a client. They are the sort keys.

> **Boundary:** Outcomes 3 and 4 apply to kind Storage. Kind BlobStorage shares an October 2026 retirement. The upgrade article lists it under the same commands, but the legacy blob FAQ says you move the data to a new GPv2 account. Until those pages agree, give BlobStorage its own pass before you copy a tier. Account kinds other than Storage and BlobStorage are outside the retirement pages used here.

## Where the account sits while the kind changes

The kind change does not redraw the landing zone. The private endpoint, the subnet it lives in, and the account name stay. What moves is the control decision at the management group, and the blob meters Cost Management will show on the next invoice.

The landing zone around the account uses the nested boundaries from [Azure Private Link in a hub-and-spoke network](https://learn.microsoft.com/en-us/azure/architecture/networking/guide/private-link-hub-spoke-network): subscription, resource group, virtual network, subnet, with on-premises outside the subscription. Figure 2 draws one workload subscription on that pattern. The hub stays out of frame because this retirement does not ask you to renumber it.

```diagram-asset
src: /diagrams/set-the-gpv1-tier-before-auto-migration/upgrade-in-place.svg
alt: Management group inventory and Azure Policy sit outside the subscription, the private endpoint stays in its subnet, and Cost Management reads blob meters after the storage account kind changes in place.
caption: The private endpoint stays in the subnet while the account kind changes in the resource group
aspectRatio: 16 / 10
source: Hand-authored SVG with official Azure icons, modeled on Azure Private Link in a hub-and-spoke network
```

## Workflow

1. From the management group, query Resource Graph for storage accounts whose kind is Storage or BlobStorage. A row still on Storage is inside the auto-migration window. BlobStorage stays on the list until you have read its own retirement page. That is marker 1, into the storage account.

2. Azure Policy, left on AuditIfNotExists, marks kind Storage noncompliant. The sample remediation sends no tier, and the upgrade article says an upgrade without one defaults to Hot, so plan on Hot. The platform owner either runs PowerShell or the CLI with AccessTier Hot or Cool, or stops when the SKU is Standard_ZRS. The ARM change sets kind to StorageV2, keeps the SKU when the region supports it, and cannot be reversed. That is marker 2.

3. On-premises clients keep the same private endpoint and the same account name. The retirement overview says data and endpoints remain the same, and the scale-target page says no data is copied. Do not plan a DNS cutover for this retirement. Marker 3 is that private path.

4. Cost Management shows the new blob meters. Files and disks stay on their own prices. The person named on the decision reads the first full month and reopens it if the transaction line, not the capacity line, is what moved. Marker 4 is that handoff.

## Audit first, remediate after the tier is written

The Learn retirement pages point at a sample policy through aka.ms/gpv1_azure_policy. On 26 October 2026 that short link resolved to a community definition, [Upgrade GPv1 storage accounts to GPv2](https://github.com/Azure/Community-Policy/blob/main/policyDefinitions/Storage/storage-account-upgrade-gpv1-storage-account-to-gpv2/azurepolicy.json). The default effect in that file is AuditIfNotExists, not deploy. The condition matches kind Storage and kind StorageV2. The existence check is kind equals StorageV2, so an account already on GPv2 is compliant and a GPv1 account is not.

The deploy template keeps the account name, the location, and the SKU, sets kind to StorageV2, and sends an empty properties object. It does not set accessTier. The upgrade article says an upgrade without a tier defaults to Hot. It documents the portal, PowerShell, and CLI, not this template, so expect Hot and check accessTier on the first remediated account. The remediation identity is granted Storage Account Contributor, role definition 17d1049b-9a84-46fb-8f53-869881c3d3ab. That role manages the account and can read the account keys, so a key holder can reach the data with shared-key authorization. Assign the sample as AuditIfNotExists at the management group. Turn on DeployIfNotExists only for a scope where the remaining accounts each have a decision that accepts Hot, or replace the template so the tier is a parameter you have already chosen.

Read that template the way you read any other deployment of a storage account. The retirement FAQ tells you to diff infrastructure-as-code plans for replacement or for settings you did not mean to change: network rules, private endpoints, encryption, identity, tags. An empty properties object is not a promise that those settings survive. If your own Bicep or Terraform still describes kind Storage, or if the plan wants to replace the account, stop the apply.

## Write the decision where the invoice can find it

For each account, put four lines on the decision record before the kind flips. The shape is the one in [An ADR without a customer problem is just a solution brief](/ground-every-adr-in-a-customer-problem): name the failure someone can feel, then the choice.

The failure is operational. Unattended upgrade to Hot on an export the business treats as cold. Or legacy ZRS replaced by whatever redundancy the region still has, so a zone failure no longer means what the landing zone review thought it meant. The choice is the outcome number, the tier, and the SKU you kept or handed to support. The owner is the person who will open Cost Management when the first full GPv2 month posts. The revisit trigger is that invoice, or any support-driven change of redundancy.

> **Cost:** Files and disks do not reprice when the kind changes. A forecast that swings "storage" and an account that is mostly file shares or disks are aimed at the wrong meter. Blob capacity, blob transactions, and, on cool, blob reads are the meters that move.

Run the query today and put an outcome number next to every row. Waiting does not keep the GPv1 price: the overview says GPv2 pricing is expected shortly after the retirement date even when the backend conversion has not finished. The only part still yours is the tier.