Cost

Upgrade general-purpose v1 storage accounts to v2

One capability across every storage account in the estate: move any account still on the legacy general-purpose v1 kind onto general-purpose v2, so the workload pays v2's lower per-gigabyte capacity prices and can finally use access tiers, lifecycle management and reserved capacity, before Microsoft retires v1 entirely.

13 min·10 sections·AZURE

Last reviewed 18 June 2026

Upgrading storage accounts to v2: the basics

Why does a general-purpose v1 account quietly cost you more than it should?

Azure Storage has shipped three account generations, and the oldest one is still running in plenty of estates. A general-purpose v1 account, the original kind, reports its 'kind' property as 'Storage'. General-purpose v2, the current default, reports 'StorageV2'. They look identical in the portal and serve the same blobs, files, tables and queues, but they price differently and, more importantly, v1 is missing the features that let you optimise what you store. A v1 account cannot use access tiers, so every byte sits at one flat rate whether it is read every minute or never touched again. It cannot use lifecycle management to move cold data down automatically or delete it on a schedule. And it cannot be covered by reserved capacity, the commitment discount that knocks a large slice off the per-gigabyte price.

The Cost Optimization workbook surfaces this directly. Its Storage tab runs a query titled 'Storage accounts which are not v2' that lists every account whose kind is still 'Storage' (or the legacy 'BlobStorage' kind). Each one is an account that is locked out of the three biggest levers for reducing storage spend at once. The workbook is not flagging a misconfiguration that breaks anything; it is flagging money left on the table, because the account is paying v2-or-higher capacity rates with none of v2's ways to bring that bill down.

Most v1 accounts are simply old. They were created years ago, before v2 became the default, and nobody had a reason to touch them. The upgrade closes that gap. It is a one-way change of the account kind, it is free, it carries no downtime and no risk of data loss, and once it lands the account can immediately adopt access tiers, lifecycle rules and reserved-capacity coverage. There is also a deadline now attached to the inertia: Microsoft will retire general-purpose v1 accounts on 13 October 2026, so an account left on v1 is not only paying more than it needs to, it is on a clock.

In this lesson you will learn how Azure Storage distinguishes a general-purpose v1 account from a v2 one, how to find every v1 account left in a subscription, why staying on v1 quietly costs more, and how to upgrade safely with a single command or a Bicep change. You will also learn the one workload profile to check before upgrading in bulk, and the retirement deadline that makes this non-optional.

Fun fact

The account kind that never changes by itself

When Microsoft made general-purpose v2 the default account kind, it did not retroactively upgrade the v1 accounts already out there. The kind is a property you set once at creation, and an account keeps it for life unless someone explicitly changes it. That is why a subscription opened years ago can still be quietly running v1 accounts today: they were created correctly for their time, the default moved on, and nothing ever prompted a change. The upgrade is one-way on purpose, you cannot downgrade a v2 account back to v1, which is exactly why the workbook surfaces the laggards rather than leaving you to find them.

Finding the v1 accounts hiding in a subscription

Priya runs the platform team at a company that has been on Azure for six years. The Cost Optimization workbook's Storage tab shows the 'Storage accounts which are not v2' query returning a handful of accounts she does not recognise from any recent project.

Before scheduling any change, she lists every account whose kind is still the legacy 'Storage' value, so she can see which ones are real, what they hold and whether any are transaction-heavy enough to model before a bulk upgrade.

List every account still on the legacy v1 kind. A 'kind' of 'Storage' is general-purpose v1; 'StorageV2' is the current generation.

$ az storage account list --query "[?kind=='Storage'].{name:name, rg:resourceGroup, tier:accessTier}" -o table

Name Rg Tier

------------------ ---------------- ------

archivelogs2019 rg-legacy None

appdiagstore rg-legacy None

# accessTier is 'None' because v1 cannot use tiers at all. That is the lost lever.

A v1 account reports no access tier because the feature does not exist on v1. archivelogs2019 is the clearest win: old log data paying the flat v1 rate that could drop to cool or archive the moment it is v2.

How the workbook decides an account is not v2deep dive

The check is a single property: the account 'kind'. A general-purpose v1 account reports 'kind' as 'Storage', a v2 account reports 'StorageV2', and the older blob-only kind reports 'BlobStorage'. The Cost Optimization workbook's 'Storage accounts which are not v2' query is essentially a filter for any account whose kind is not 'StorageV2', because only v2 (and the specialised premium kinds) can use the full set of cost levers. There is nothing subtle to interpret: the property is either current or it is not.

What sits behind that one property is the feature gap. Access tiers, hot, cool, cold and archive, are a v2 capability, so a v1 account has no access tier at all and every blob is billed at the single v1 rate regardless of how often it is touched. Lifecycle management policies, which tier or delete data automatically by age, only apply to v2 accounts. Reserved capacity, the commitment discount on stored gigabytes, is offered for v2 standard accounts. Each of these is a real saving that the v1 kind structurally cannot access, which is why the workbook treats the kind itself as the cost signal.

The upgrade flips 'kind' from 'Storage' to 'StorageV2' in place. It is a control-plane change to the account, not a data copy, so it is near-instant and the data never moves. It is also one-way: there is no path back to v1, which is deliberate, because v1 is the generation being retired. After the change the account behaves as a normal v2 account and the cost levers become available immediately; the workbook stops listing it on its next refresh.

What is the impact of leaving accounts on v1?

The direct impact is a higher standing bill than the same data would cost on v2. General-purpose v2 delivers the lowest per-gigabyte capacity prices in Azure Storage, so a capacity-heavy v1 account is paying more for the same stored bytes. On top of that base difference, the account is locked out of access tiers, so data that is never read still pays the hot rate instead of dropping to cool, cold or archive, and locked out of reserved capacity, so a predictable, long-lived store cannot take the commitment discount. For an estate with old logs, backups and archives on v1, these add up to a recurring overpayment month after month.

The second-order impact is opportunity cost on every other optimisation. Lifecycle management, the policy engine that automatically tiers cold data and deletes expired data, does not run on v1 accounts. So a v1 account is not just expensive today, it is excluded from the automation that keeps storage cheap over time. Every clean-up has to be manual, which means in practice it mostly does not happen, and the account silently accumulates cold data at the full rate.

Finally there is the deadline. Microsoft will retire general-purpose v1 accounts on 13 October 2026, with new v1 account creation blocked earlier. An account left on v1 is therefore not a stable steady state: it is a forced migration waiting to happen. Doing the upgrade now, while it is a free and unhurried savings exercise, is strictly better than doing it later under a retirement clock, when it becomes mandatory work with no savings framing left to claim.

How do you upgrade v1 accounts to v2 safely?

Treat this as one sweep rather than a per-account chore. The order matters: find the v1 accounts, set aside the one transaction-heavy profile to model first, then upgrade the rest and actually use the levers the upgrade unlocks.

1. Inventory every v1 account

List every account whose kind is still 'Storage' (and the legacy 'BlobStorage' kind, which is also pre-v2). Pull the stored capacity and the transaction count alongside each one, because those two numbers tell you both the size of the saving and whether the account is the rare transaction-heavy exception.

2. Set aside the transaction-heavy outliers

Most accounts are capacity-dominated and upgrade to a clear saving. The exception is an account that stores little but performs a very high volume of operations, where v2's slightly higher per-transaction price could outweigh the capacity saving. Model those few before upgrading; greenlight the rest.

3. Upgrade the kind, then choose a default tier

Run the upgrade, which flips kind from 'Storage' to 'StorageV2' in place with no downtime and no data movement. If you do not specify a default access tier the account upgrades to Hot, so set Cool explicitly on accounts whose data is mostly cold to capture the saving from the first day.

4. Use the levers the upgrade unlocks

The upgrade only removes the block; the saving comes from what you do next. Add lifecycle management rules to tier cold data down and delete expired data automatically, and buy reserved capacity for the large, predictable stores. For new accounts, set kind to StorageV2 in your Bicep so no fresh v1 account is ever created again.

# Upgrade every general-purpose v1 account to v2. Free, no downtime, one-way.
# Default to Cool here for cold-data stores; use --access-tier=Hot for hot workloads.
for row in $(az storage account list \
    --query "[?kind=='Storage'].{n:name, g:resourceGroup}" -o tsv); do
  name=$(echo "$row" | cut -f1)
  rg=$(echo "$row" | cut -f2)
  az storage account update \
    --name "$name" --resource-group "$rg" \
    --set kind=StorageV2 \
    --access-tier=Cool
  echo "$name: upgraded to general-purpose v2 (default tier Cool)"
done

# For new accounts, pin kind to v2 in Bicep so no fresh v1 account is ever created:
#
# resource sa 'Microsoft.Storage/storageAccounts@2023-05-01' = {
#   name: storageAccountName
#   location: location
#   kind: 'StorageV2'
#   sku: { name: 'Standard_LRS' }
#   properties: {
#     accessTier: 'Cool'
#   }
# }

Quick quiz

Question 1 of 5

The Cost Optimization workbook lists several accounts under 'Storage accounts which are not v2'. What does that query actually filter on?

Keep learning

Go deeper on the account kinds, the upgrade itself, and the cost levers that v2 unlocks.

You can now treat legacy storage accounts as one capability rather than untouchable old infrastructure: find every account still on the v1 kind, set aside the rare transaction-heavy outlier to model first, upgrade the rest in place for free, and then actually use the access tiers, lifecycle rules and reserved capacity the upgrade unlocks. Pin the kind to v2 in your templates so no new v1 account is ever created, and you have cleared the estate well ahead of the 13 October 2026 retirement deadline.

Back to the library

Upgrading storage accounts to v2: the savings view

A free, no-downtime change that unlocks three separate ways to cut the storage bill

This is one of the cleanest savings items on the Azure cost report because the change itself costs nothing. Upgrading a v1 account to v2 is free, there is no migration project and no professional-services line. What the upgrade buys is access to three pricing levers that v1 simply cannot use: access tiers, so rarely read data drops to the cool, cold or archive rate instead of paying the hot rate forever; lifecycle management, so that tiering and clean-up happen automatically rather than relying on someone to remember; and reserved capacity, the one-or-three-year commitment that discounts the per-gigabyte price for predictable volumes.

The headline saving is the per-gigabyte capacity price. Microsoft documents general-purpose v2 as delivering the lowest per-gigabyte capacity prices in Azure Storage, so for a capacity-heavy account the upgrade can reduce the standing bill on its own, before any tiering. The honest caveat to put in the finance pack is that v2 can carry slightly higher per-transaction prices than v1, so an account that is light on stored data but extremely transaction-heavy is the one case to model before upgrading in bulk. For the typical account, where capacity dominates the bill, the maths favours v2.

The return is one-sided and the payback is immediate. There is no upfront spend to recover, so any capacity saving and any tiering or reservation discount the upgrade unlocks is pure return from day one. The only work is engineering time to run the upgrade and, for a transaction-heavy minority, a short look at the transaction profile first.

This lesson is for the finance partner who sees 'Storage accounts which are not v2' on the Cost Optimization workbook and wants to know what it is worth. It covers why the upgrade is free, the three pricing levers it unlocks, the single transaction-heavy case worth modelling first, and how to turn a list of legacy accounts into a savings plan with an immediate payback.

Fun fact

The account kind that never changes by itself

How a finance partner frames the v1 upgrade

Priya is the finance partner reviewing the Cost Optimization workbook. The 'Storage accounts which are not v2' query returns six accounts. Her first instinct is not to wave them through but it is also not to demand a business case, because the upgrade itself is free: there is no migration spend to approve, just engineering time. The real question is what each account is worth once it can use the v2 levers. She asks the team to pull the stored capacity and the transaction count for each one.

The picture sorts itself quickly. Three accounts are large stores of old logs and backups sitting on the flat v1 rate: those are immediate wins, because once on v2 they can drop to the cool or archive tier and the bigger ones can be covered by reserved capacity, both of which are pure saving against today's bill. Two are small and barely used, so the saving is trivial but the upgrade is still free and clears them ahead of the retirement deadline. One is a high-transaction telemetry ingest account, and that is the only one she rings-fences: v2 can carry slightly higher per-transaction prices, so she asks the team to model that account's transaction profile before committing, rather than assume. The finance pack reads: 'Five accounts upgrade free for an immediate capacity and tiering saving; one transaction-heavy account gets modelled first; total upfront cost, zero.'

Why the v1 upgrade is a rare zero-risk saving

Most cost work involves a trade: spend now to save later, or accept a performance hit for a cheaper tier. The v1 upgrade has neither side of that trade. It is free, it has no downtime and no data-loss risk, and it unlocks saving rather than requiring spend, so the payback is immediate by definition. The only number to put in front of it is the saving it enables: the lower v2 capacity rate on the stored gigabytes, plus whatever the now-available access tiers and reserved capacity remove on top.

The one piece of diligence worth the finance role's attention is the transaction profile. Microsoft prices v2 transactions slightly higher than v1 in some cases, so an account that stores very little but performs an enormous volume of operations is the one profile where the upgrade could nudge the bill the wrong way. That is a small minority of accounts and it is easy to spot from the transaction metrics. For every capacity-dominated account, which is the common case, the upgrade lowers the bill. The finance move is to greenlight the capacity-heavy accounts immediately and ask only for the transaction-heavy outliers to be modelled first.

What finance can do about the v1 gap

Finance cannot change an account kind, but it owns the framing that turns a list of legacy accounts into a prioritised savings plan with zero upfront cost and one clearly bounded exception. Three levers.

1. Greenlight the free upgrades without a business case

Make explicit that the upgrade itself costs nothing: no migration spend, no downtime, no data-loss risk, just engineering time. There is no business case to build for a free, reversible-by-deletion-only change that the retirement deadline will force anyway. The finance role is to remove the approval friction so the capacity-heavy accounts get upgraded promptly, not to gate them behind a justification they do not need.

2. Order the work by stored capacity, not account count

A six-account list looks small, but the saving is dominated by the one or two largest stores. Ask the team to sort the v1 accounts by stored gigabytes and start at the top, because that is where the lower v2 capacity rate, the access-tier saving and the reserved-capacity discount all compound. An empty v1 account is worth upgrading for the deadline, but it is not where the money is.

3. Ring-fence the transaction-heavy exception explicitly

The single profile that needs care is the account that stores little but transacts enormously, where v2's slightly higher per-transaction price could erode the saving. Require that any such account is modelled on its real transaction metrics before it is upgraded, and recorded as a checked exception either way. The distinction between 'we modelled this and it still wins' and 'we upgraded everything blind' is what keeps the savings claim defensible.

Quick quiz

Question 1 of 5

The workbook shows six v1 accounts. As the finance partner, what is the right starting assumption about the cost to upgrade them?

Keep learning

Go deeper on the account kinds, the upgrade itself, and the cost levers that v2 unlocks.

You have finished the finance view of the v1-to-v2 upgrade. You know it is the rare cost item with no upfront spend, no downtime and no data-loss risk, so the payback is immediate by definition, and that the saving comes from the levers it unlocks: the lower v2 capacity rate, access tiers, lifecycle clean-up and reserved capacity. Next time 'Storage accounts which are not v2' appears on the workbook, you will greenlight the capacity-heavy accounts without a business case, sort the work by stored gigabytes, and ring-fence only the one transaction-heavy profile to model first.

Back to the library

Upgrading storage accounts to v2: the headline

Free standing-cost reduction on the estate's oldest storage, with a hard retirement deadline already set

Some of the storage in the estate is still on the original account generation from years ago. It works fine, but it is paying more than it needs to and cannot use any of the modern tools for bringing storage cost down. The fix is free, takes no downtime, and carries no risk to the data.

There are two reasons to act rather than leave it. The first is savings: the newer account type has lower standing per-gigabyte prices and unlocks automatic tiering and commitment discounts that the old type cannot touch. The second is a deadline: Microsoft retires the old account type on 13 October 2026, so this becomes mandatory regardless. Doing it now turns a forced migration into a savings win.

The leadership decision is simply to set the expectation that the estate is moved off the legacy account type ahead of the deadline, and that the savings levers it unlocks are then actually used. The cost of acting is engineering time; the cost of waiting is a higher bill now and a rushed migration later.

A short read for the leader who needs to know why old storage accounts cost more than necessary, why the upgrade is free and risk-free, and why a hard retirement deadline means this is happening anyway, so it is better done now as a savings win than later as a scramble.

Fun fact

The account kind that never changes by itself

What it looks like when old storage stops quietly overpaying

At a cost review the CFO asked why the storage line had not moved despite a year of optimisation work. The honest answer was that a chunk of the estate's storage was still on an account generation that could not use any of the tools the optimisation work relied on: no access tiers, no automatic lifecycle clean-up, no reserved-capacity discount. The savings levers existed; several accounts simply could not pull them.

The team's response was to stop treating the legacy accounts as untouchable old infrastructure and treat the upgrade as the unlock it is. They listed every v1 account, confirmed the upgrade was free and carried no downtime or data-loss risk, modelled the single transaction-heavy account, and upgraded the rest. With those accounts now on v2, the cold data finally moved to cheaper tiers, lifecycle rules took over the clean-up, and the large stores became eligible for reserved capacity. The next review had a number to show. The shift, from 'that storage is stuck on the old type and we leave it alone' to 'all storage is on the current type and using every saving lever, with the retirement deadline already behind us', is the confidence signal this capability delivers, and it cost nothing upfront to reach.

Why this is the easiest cost decision on the table

This is the rare optimisation with no downside to weigh. The upgrade is free, it does not interrupt the workload, it cannot lose data, and it is going to be mandatory anyway because the old account type is being retired. The only question is whether the estate does it now as a deliberate savings exercise or later as a forced migration under a deadline.

The cost of getting it wrong is small and bounded: a single account type with an unusual transaction pattern is worth a quick check before a bulk change. The cost of doing nothing is a recurring overpayment on every legacy account plus a rushed, value-free migration in 2026. Approving the upgrade and asking for the unlocked levers, tiering and reserved capacity, to actually be used is the whole decision.

The leadership move on legacy storage

The executive handle is not to approve each upgrade individually; it is to set the expectation that the estate is off the legacy account type ahead of the retirement deadline and that the saving levers it unlocks are then actually used.

1. Set a date that beats the retirement deadline

Microsoft retires general-purpose v1 on 13 October 2026. Ask for an internal date comfortably ahead of that by which every v1 account is upgraded, so the work happens as an unhurried savings exercise rather than a forced migration. Pinning the deadline turns a vague 'we should do that' into a tracked commitment that also captures the saving early.

2. Ask for the saving, not just the upgrade

Upgrading the kind only removes the block; the saving comes from using access tiers, lifecycle management and reserved capacity afterwards. The proof that this is done is not 'the accounts are now v2', it is a measurable drop in the storage line: cold data tiered down, clean-up automated, the big stores on reserved capacity. Ask for the before-and-after number, not the migration status.

3. Make new v1 accounts impossible

Once the estate is clean, ask that the infrastructure-as-code templates pin the account kind to v2 so no new v1 account is ever created. A one-line default in Bicep is the difference between cleaning this up once and cleaning it up again every time someone provisions storage from an old template.

Quick quiz

Question 1 of 5

At a cost review you ask why the storage line has not moved despite a year of optimisation work. What is the most likely structural answer the v1 issue points to?

Keep learning

Go deeper on the account kinds, the upgrade itself, and the cost levers that v2 unlocks.

Two takeaways. The v1-to-v2 upgrade is the rare cost decision with no downside to weigh: free, no downtime, no data risk, and mandatory by the 13 October 2026 retirement deadline anyway, so doing it now turns a forced migration into a savings win. And the proof it is done is a lower storage line, not a list of upgraded accounts, so ask for the before-and-after number and for new templates to pin the account kind to v2 so this never recurs.

Back to the library

Part of the learning path Cut your Azure storage bill

Upgrade general-purpose v1 storage accounts to v2

Upgrading storage accounts to v2: the basics

The account kind that never changes by itself

Finding the v1 accounts hiding in a subscription

How the workbook decides an account is not v2deep dive

What is the impact of leaving accounts on v1?

How do you upgrade v1 accounts to v2 safely?

1. Inventory every v1 account

2. Set aside the transaction-heavy outliers

3. Upgrade the kind, then choose a default tier

4. Use the levers the upgrade unlocks

Quick quiz

Keep learning

Upgrading storage accounts to v2: the savings view

The account kind that never changes by itself

How a finance partner frames the v1 upgrade

Why the v1 upgrade is a rare zero-risk saving

What finance can do about the v1 gap

1. Greenlight the free upgrades without a business case

2. Order the work by stored capacity, not account count

3. Ring-fence the transaction-heavy exception explicitly

Quick quiz

Keep learning

Upgrading storage accounts to v2: the headline

The account kind that never changes by itself

What it looks like when old storage stops quietly overpaying

Why this is the easiest cost decision on the table

The leadership move on legacy storage

1. Set a date that beats the retirement deadline

2. Ask for the saving, not just the upgrade

3. Make new v1 accounts impossible

Quick quiz

Keep learning

Related cost lessons