What changed

Microsoft published the retirement with three milestones. The type was announced for retirement in September 2025. New general-purpose v1 account creation is blocked in September 2026. Full retirement follows in October 2026, and Microsoft states that any remaining v1 accounts will be automatically migrated to v2 at that point. The retirement page states that it takes effect globally across all Azure regions, so there is no region in which a v1 account continues to be supported. The sentence that carries the real weight is the one about consent: Microsoft states that a decision not to migrate an existing general-purpose v1 account will be construed as consent for Microsoft to migrate the account on the customer’s behalf. This is not a change that waits for an administrator to act. It is a change that proceeds unless an administrator acts first.

The operational risk is easy to miss because the service can continue to look healthy. The control becomes visible only when a capacity request fails, an unsupported runtime is removed, or an extension blocks an enforced ERP update. Waiting for that moment transfers a planned decision into an incident.

What the term means in plain language

A storage account is the container that holds Azure blobs, files, queues and tables. General-purpose v1 was the original account type. General-purpose v2 replaced it and became the default, adding blob access tiers of hot, cool, cold and archive, lifecycle management, immutable blob storage, fuller Event Grid integration, regionally consistent pricing meters and wider redundancy options including zone-redundant storage. The difference that matters commercially is not the feature list but the meter: v1 and v2 price storage and transactions on different models.

This distinction matters because product status is not the same as business readiness. Availability, support and compatibility are separate questions. A service can be available but unsupported, supported but capacity-constrained, or technically updated while a customer-specific process has stopped working.

Why this matters to a South African organisation

South African teams often operate with tight specialist capacity, rand-sensitive budgets and business processes that cannot be paused while a replacement is sourced. Localisation, regional cloud capacity and long procurement lead times can narrow the recovery options. The practical response is to use the available test window before it becomes an emergency window.

The consequence belongs to the business process, not only the technology team. Finance month-end, customer transactions, data pipelines and ERP extensions all cross technical and operational ownership. A change should therefore be accepted only when the service owner and the business owner can see the same evidence.

The hidden exposure

Azure blocks the creation of new general-purpose v1 storage accounts in September 2026 and retires the account type in October 2026, automatically migrating anything still on it to general-purpose v2. Microsoft states that a decision not to migrate is construed as consent, and that the v2 pricing model may increase costs for transaction-heavy workloads.

Normal operation is weak evidence. It proves only that yesterday’s combination of platform, configuration and workload completed. It does not prove that the next capacity allocation, lifecycle enforcement or major release will preserve the same result. An owner needs an inventory, a representative test and a dated decision.

Decision path

The upgrade itself is unusually safe, and that is worth stating plainly because it removes the usual reason for delay. Microsoft describes it as an in-place Azure Resource Manager operation that changes the account kind, with no downtime and no risk of data loss, leaving data and endpoints unchanged, and states that most workloads migrate without code changes. Two facts sit against that. The first is that the upgrade is permanent: a general-purpose v2 account cannot be downgraded back to v1, and a blob storage account cannot be downgraded back either. The second is commercial. Microsoft warns that upgrading introduces a new pricing model that may increase costs for certain workloads, especially those with high read, write or list operations, and that transaction pricing differs in v2 so workloads with frequent operations may incur higher charges unless cost-optimisation strategies are applied. The scope of that warning is narrower than it first appears, and the narrowing is useful: Microsoft states that converting an account changes how Blob Storage is billed but does not affect pricing for Azure Files or Azure Disks, which use their own pricing models. The decision is therefore not whether to migrate, because that is settled, but whether to migrate on a date of your choosing with the cost modelled and the access tier set, or to let the automatic migration make both choices by default. Braintree’s recommendation, rather than Microsoft’s instruction, is the former: a billing change discovered in an October invoice is far more expensive to investigate than the same change modelled in September.

Record the alternatives that were rejected and why. That prevents the next reviewer from reopening the entire question without context. Where the preferred path cannot be completed inside seven days, approve a time-bound exception with a responsible owner, expiry date and compensating control.

Technical test plan

Identify the accounts first. Microsoft names Azure Resource Graph, the CLI, Azure Inventory or the portal as the ways to list every general-purpose v1 account, and publishes a deployIfDoesNotExist Azure Policy that detects v1 accounts and performs the non-disruptive in-place upgrade. Model the cost before converting. Microsoft provides an open-source general-purpose v1 to v2 cost estimator that compares estimated costs using current usage and accepts uploaded billing data, with the caveat that it uses public pricing and excludes contract-specific discounts, taxes and reservations. To model manually, capture a baseline of monthly operations split by read, write and list or metadata, plus egress, then compare per-gigabyte and per-operation rates for the relevant region, redundancy and intended access tier, factoring early-deletion minimums for cool, cold and archive. Where the workload is read, write or list heavy, Microsoft’s own mitigations are to batch operations, write larger blocks and scope list operations. To upgrade in the portal, open the storage account, choose Configuration under Settings, select Upgrade under Account kind, and confirm by entering the account name. Set the default access tier, hot or cool, during the upgrade, because Microsoft flags leaving it unconsidered as a source of unintended charges. Finally, review infrastructure-as-code artifacts, pipelines, templates and policies so they reflect the post-migration v2 configuration and preserve networking, security, redundancy, access tier, encryption, identity, data protection and tags.

Use production-representative conditions without exposing production data unnecessarily. Capture the starting configuration, exact version, time of test and expected result. A pass requires evidence from the real workflow, not only a successful login or an unchanged dashboard.

Primary owner

Primary owner: The budget holder for Azure, with the platform or infrastructure lead.

The named owner coordinates platform, application, commercial and business-process decisions. Contributors may perform the work, but accountability cannot be distributed across a meeting invite. The owner closes the test, exception and evidence record.

Action within seven days

Action within seven days: Inventory every general-purpose v1 storage account in every subscription using Azure Resource Graph, model the v2 cost against current read, write and list volumes before converting, and convert deliberately with the default access tier chosen rather than waiting for the automatic migration.

Start with the highest-consequence workload. Assign the people, date and pass criteria before the test begins. If the first test fails, record the failure as evidence and open remediation with a deadline rather than hiding it behind a general project status.

Evidence to retain

Evidence to retain: The dated inventory of v1 accounts by subscription, the modelled cost comparison that supported the decision, the account kind before and after conversion, and the default access tier selected at upgrade.

Store the evidence with the platform or change record. Include source exports and machine-readable results where possible. The next reviewer should be able to reproduce the conclusion without rebuilding it from email, chat or memory.

Frequently asked questions

What happens if we do nothing?

Microsoft states that remaining general-purpose v1 accounts will be automatically migrated to general-purpose v2 at full retirement in October 2026, and that a decision not to migrate is construed as consent for Microsoft to migrate the account on your behalf.

Is the upgrade risky?

Microsoft describes it as in-place with no downtime and no risk of data loss, changing only the account kind in Azure Resource Manager, with data and endpoints unchanged and most workloads migrating without code changes.

Can we reverse it?

No. Microsoft states that upgrading to general-purpose v2 is permanent and that an upgraded account cannot be downgraded back to general-purpose v1.

Will it cost us more?

It can. Microsoft warns that the v2 pricing model may increase costs for workloads with high read, write or list operations because transaction pricing differs, while per-gigabyte storage costs and access tiers can reduce cost in other cases. The direction depends on the workload, which is why modelling it first is the point.

Does this change our Azure Files or Azure Disks bill?

Microsoft states that converting from v1 to v2 changes how Blob Storage is billed but does not affect pricing for Azure Files or Azure Disks, which use their own pricing models.

Does it apply in South African regions?

Microsoft states that the retirement takes effect globally across all Azure regions.

The Braintree view

Microsoft’s announcement supplies the platform fact. The customer control begins after that fact: identify the exposed process, name the owner, test the real dependency and retain a decision that can survive audit or staff turnover. Braintree can help structure the inventory, build the representative test and translate the result into a controlled implementation plan.

Use the seven-day action as the entry point. Do not wait for a renewal, support refusal or enforced update to reveal work that can be measured now.