Azure Blob Storage Auto-Migrates Legacy Accounts After October 13, 2026

Microsoft will stop accepting requests to create new legacy BlobStorage accounts in September 2026 and says remaining legacy Blob Storage accounts will be automatically migrated to general-purpose v2 after October 13, 2026. GPv1 accounts are also in the retirement-scope inventory, but administrators should not assume the same automatic-migration statement applies to them without confirmation from Microsoft. Discover both legacy kinds now, update deployment code, and choose GPv2 cost controls before the deadlines arrive.
Microsoft’s Azure Storage retirement guidance warns that automatic migration may increase billing. The account conversion is only one part of the work; teams also need to decide how the resulting GPv2 accounts will be operated and charged.

September Turns Old Templates Into Deployment Risks​

The first operational deadline arrives before the automatic-migration date. Starting in September 2026, Microsoft says Azure will block creation requests for accounts whose kind is BlobStorage.
That verified creation block should not be generalized to every request using kind: Storage. GPv1 accounts remain within the broader retirement inventory and should be upgraded, but the supplied guidance does not establish that all new GPv1 Storage requests will be blocked at the same September milestone.
Audit both deployed resources and code capable of creating them:

1. Find existing BlobStorage and GPv1 Storage accounts.
2. Search ARM templates, Bicep, Terraform, scripts, pipeline variables, internal catalogs, and copied deployment examples for both kinds.
3. Prioritize removing BlobStorage creation requests before September.
4. Replace legacy definitions with reviewed StorageV2 configurations.
5. Assign an accountable owner and validation date to each discovered account.
6. Test revised deployments before production pipelines encounter the block.

This pattern will be familiar to readers of WindowsForum’s reports on the Azure Update Delivery service-tag deprecation and Azure AD Graph API retirement. In both cases, the visible production dependency was only part of the footprint. Reusable modules, recovery scripts, old automation, and rarely executed jobs can preserve a retired setting after primary deployments have been corrected.
Azure Resource Graph can help build the initial inventory. Use a query such as the following across the subscriptions available to the operator:

resources
| where type =~ 'microsoft.storage/storageaccounts'
| where kind == 'BlobStorage' or kind == 'Storage'
| extend owner = coalesce(
    tostring(tags['owner']),
    tostring(tags['Owner']),
    tostring(tags['serviceOwner']),
    tostring(tags['ServiceOwner'])
  )
| join kind=leftouter (
    resourcecontainers
    | where type == 'microsoft.resources/subscriptions'
    | project subscriptionId, subscriptionName = name
  ) on subscriptionId
| project
    subscriptionName,
    subscriptionId,
    resourceGroup,
    accountName = name,
    accountKind = kind,
    location,
    owner,
    tags
| order by subscriptionName asc, resourceGroup asc, accountName asc

The two kind filters identify the supplied retirement-scope account types. The subscription-name join and owner-tag logic are editorial conveniences, however, so test them against your naming, tagging, and access model. An empty owner field may mean the account lacks one of the listed tags rather than proving that it has no responsible team.
Resource Graph results should begin the investigation, not end it. Reconcile them with infrastructure repositories, deployment histories, service catalogs, and billing records so that unmanaged accounts and dormant deployment definitions are not overlooked.

---

Upgrade Each Account In Place​

Microsoft describes the account-kind conversion as an Azure Resource Manager operation rather than a data-copy migration. It does not require moving blobs into a separate destination, unlike the cloud-to-cloud transfers covered in WindowsForum’s report on Azure Storage Mover from Amazon S3 to Azure Blob Storage.
Before changing an account:

• Confirm that its kind is BlobStorage or GPv1 Storage.
• Confirm that the assigned operator can update the resource under the organization’s access model.
• Check whether resource locks, Azure Policy, or deployment controls could deny or reverse the change.
• Identify the applications, automation, monitoring, and business processes that depend on the account.
• Capture representative billing and activity data.
• Document the intended GPv2 tiering, redundancy, and lifecycle approach.
• Review Microsoft’s current conversion instructions and limitations for the account.

Use Microsoft’s current Azure portal or Azure Resource Manager procedure to change the account kind to StorageV2. Portal labels and placement can change, so verify the workflow against the current documentation and confirm the resulting account kind after the operation.
For an account managed through ARM, Bicep, Terraform, or another infrastructure-as-code system, update the source of truth as part of the same controlled change. Do not make a portal-only conversion that leaves automation declaring the old kind. Test a representative low-risk account first, validate it, and then expand the migration batch.
That incremental approach reflects the operational lesson in WindowsForum’s coverage of Azure web deployment improvements: small, testable deployment changes are easier to verify and troubleshoot than a broad unobserved rollout.

Configure GPv2 Deliberately​

GPv2 provides controls for access tiers, lifecycle management, and redundancy, but converting the account does not choose the right operating model for the workload.

Lifecycle management​

Create lifecycle rules only after reviewing data age, access patterns, retention requirements, and deletion obligations. Azure exposes lifecycle management in the storage account’s data-management experience, although the exact portal navigation and labels can vary.
A rule can define eligible blob types and filters and determine when matching data moves to a cooler tier or is deleted. Give every rule a named owner and review date. One generic age-based policy should not be copied across unrelated workloads simply to mark the migration complete.

Access tiers​

Review the account’s default access tier and any blob-specific tiering needs through the storage account’s current configuration and container-management experiences. The portal’s exact controls may differ by account configuration and may change over time.
Choose the default from measured workload behavior rather than account age. Where repeatable age- or filter-based transitions are appropriate, use lifecycle policies instead of relying on recurring manual changes.

Redundancy​

GPv2 also requires an explicit redundancy decision. Review the options Azure currently makes available for the account and select the configuration approved for its durability, availability, regional-resilience, and cost requirements.
Do not automatically preserve an old assumption merely because the legacy account used a particular SKU. The conversion is an opportunity to document why the selected redundancy level fits the workload.
The migration is also a useful security-review checkpoint, but it is not a security upgrade by itself. WindowsForum users discussing Microsoft Defender’s November 2025 updates emphasized the growing risks around Azure Blob Storage and AI integrations. Changing the account kind does not replace identity review, data governance, logging, threat protection, or controls for connected applications.

Use a Per-Account Migration Worksheet​

A short worksheet makes the project auditable and keeps cost decisions tied to each workload:

Field	Required entry
Current account kind	BlobStorage or GPv1 Storage
Workload and access pattern	Purpose, read/write frequency, transaction behavior, and retention needs
Chosen tiering approach	Default tier, exceptions, and lifecycle transitions
Redundancy decision	Selected configuration and approving owner
Lifecycle-rule owner	Person or team responsible for review
Baseline period	Dates and representative cost and activity data
Migration owner	Person accountable for execution and follow-up
Validation date	Scheduled date and completed result

Attach relevant dependency records, policy exceptions, and maintenance-window details. The baseline should cover more than stored capacity: include transaction activity, retrieval, tier placement, lifecycle operations, and redundancy where those factors affect the workload.
GPv2 can provide better cost-governance tools while still producing a higher bill if nobody models or reviews their use. The practical risk is not that GPv2 is inherently more expensive; it is allowing the account type and charging behavior to change without an approved operating model.

Validate Before Closing the Account​

After each conversion:

• Confirm that Azure reports the account kind as StorageV2.
• Perform representative reads and writes through the application’s normal path.
• Verify that the expected containers, blobs, and metadata are present.
• Check the workload’s approved authentication and authorization scenarios.
• Confirm that monitoring, diagnostics, and alerts still produce expected results.
• Review the selected default tier, lifecycle rules, and redundancy configuration.
• Run the normal deployment pipeline to detect source-of-truth drift.
• Compare activity and charges with the recorded baseline.
• Record the result, exceptions, and follow-up owner in the worksheet.

The conversion may be in place, but that does not remove the need for application testing. It changes the risk from transfer mechanics to configuration, automation, workload behavior, and cost.

October 13 Is a Billing-Control Deadline​

Microsoft’s automatic-migration statement specifically covers remaining legacy Blob Storage accounts after October 13, 2026. Because Microsoft also warns that billing may increase, the date is a financial-control deadline rather than merely a platform-maintenance event.
GPv1 accounts should remain in the migration program because they are within the retirement-scope inventory. However, teams should use Microsoft’s current GPv1 guidance instead of claiming that those accounts are covered by the same October 13 automatic conversion.
Waiting for Microsoft to act leaves less time to observe costs, correct deployment definitions, and test the chosen GPv2 configuration. By September, production code should no longer request new BlobStorage accounts. Before the October milestone, remaining legacy Blob Storage accounts should be reviewed and upgraded through the organization’s controlled process wherever practical.

Frequently Asked Questions​

Which account kinds belong in the retirement inventory?​

Include accounts whose kind is BlobStorage and GPv1 accounts whose kind is Storage. Do not include StorageV2 accounts merely because they contain blobs.

What exactly is blocked in September 2026?​

Microsoft’s stated milestone blocks creation requests for new legacy BlobStorage accounts. GPv1 Storage is in the broader retirement scope, but the September statement should not be presented as proof that every GPv1 creation request is blocked at the same time.

Which accounts will Microsoft automatically migrate after October 13, 2026?​

The supplied retirement information explicitly identifies remaining legacy Blob Storage accounts for automatic migration after that date. It does not establish the same automatic-migration treatment for GPv1 accounts, even though GPv1 belongs in the retirement inventory.

Does the upgrade copy or move stored data?​

No. The direct account-kind change is described as an in-place Azure Resource Manager operation, not a transfer to a new storage account. Applications and operational controls should still be tested afterward.

Can an upgraded account be changed back?​

Treat the conversion as a one-way migration and verify Microsoft’s current restrictions before executing it. Complete the workload review, cost baseline, and validation plan first.

Where are lifecycle, tiering, and redundancy configured?​

Azure provides these controls in the storage account’s configuration, data-management, and container-management experiences. Lifecycle management is available from the account’s data-management area; default and blob-specific tiers are exposed through the relevant account and blob controls; redundancy is managed through the storage account’s current configuration experience. Because portal navigation can change, follow Microsoft’s current interface and documentation rather than relying on a fixed click path.

What should teams do if an account has no owner?​

Do not treat discovery alone as migration readiness. Assign a business or service owner who can approve the workload’s tiering, redundancy, lifecycle, validation, and cost model before the account is changed.

---

References​

1. Primary source: learn.microsoft.com
   
   

   Legacy Blob Storage account retirement FAQ - Azure Storage | Microsoft Learn

   Commonly asked questions regarding the retirement of Azure General-purpose v1 (GPv1) legacy blob storage accounts and upgrading to GPv2.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Microsoft Defender November 2025: Securing Azure Blob Storage and AI Integrations | Windows Forum

   Microsoft’s November Defender updates arrive as more than a routine patch cycle — they are a targeted response to an explosive set of risks centered on...

   windowsforum.com

 

[ChatGPT]

Azure administrators should inventory legacy Storage and BlobStorage accounts now, remediate provisioning templates to StorageV2, prioritize GPv1 accounts using Standard_ZRS, baseline costs, test one representative account, and then schedule production changes. Microsoft will automatically migrate remaining GPv1 accounts to GPv2 in October 2026, with GPv1 retirement set for October 13, 2026—but a self-directed plan gives teams time to validate workloads and measure cost changes before the deadline.
WindowsForum members following Azure’s retirement notices have focused on the practical problem: legacy accounts are often scattered across subscriptions, owned by different application teams, and still created by old templates. That makes this an inventory and change-control exercise first, not a portal-clicking exercise.
The immediate work is straightforward:

1. Find every Storage and BlobStorage account.
2. Update ARM, Bicep, Terraform, scripts, and other provisioning paths to use StorageV2.
3. Identify GPv1 accounts using Standard_ZRS and move them to the front of the queue.
4. Capture a billing baseline, especially transaction costs.
5. Upgrade and test one representative account from each meaningful workload group.
6. Schedule production changes with named owners and post-change validation.

For related background on the retirement notice itself, see Azure Blob Storage Auto-Migrates Legacy Accounts After October 13, 2026.

---

Start by separating Storage from BlobStorage​

The two legacy account kinds can both lead to GPv2, but they should not receive the same default treatment.
A legacy General Purpose v1 account is generally identified by kind == "Storage". Microsoft’s retirement guidance says remaining GPv1 accounts will be automatically migrated to General Purpose v2 (StorageV2, commonly called GPv2) in October 2026 if customers do not move first. GPv2 is Microsoft’s recommended account type for most Azure Storage scenarios and adds modern features such as blob tiering, lifecycle management, and broader redundancy options.
A legacy blob-only account is identified by kind == "BlobStorage". Microsoft says these accounts can be upgraded to GPv2, but they cannot be downgraded back to BlobStorage afterward. That irreversibility matters. A BlobStorage account may be technically eligible for an in-place upgrade, yet still need the planning discipline normally associated with a migration project: ownership confirmation, a workload test, a cost baseline, and an approved rollback response for the application.
The first job is inventory, not clicking Upgrade.
Run this Azure Resource Graph query in Azure Resource Graph Explorer across the relevant subscriptions:

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where kind in~ ("Storage", "BlobStorage")
| project
 subscriptionId,
 resourceGroup,
 name,
 location,
 kind,
 skuName = tostring(sku.name),
 skuTier = tostring(sku.tier),
 accessTier = tostring(properties.accessTier),
 tags
| order by subscriptionId asc, resourceGroup asc, name asc

Export the results and add information Azure cannot infer: application name, business owner, production status, deployment method, monthly storage cost, monthly transaction cost, test contact, and planned change window.
A narrower query is useful for assigning the GPv1 work:

Resources
| where type =~ "microsoft.storage/storageaccounts"
| where kind =~ "Storage"
| project
 subscriptionId,
 resourceGroup,
 name,
 location,
 redundancy = tostring(sku.name),
 tags
| order by location asc, redundancy asc, name asc

Run the same query with kind =~ "BlobStorage" for the blob-only population. The purpose is operational triage: a set of low-risk GPv1 accounts should not be handled with the same process as a business-critical BlobStorage archive with unclear ownership or unusual access patterns.

Make the decision explicit​

Use the inventory to classify accounts rather than treating every legacy account as an identical upgrade ticket.

Account condition	Outcome	Required next step
Storage account with reviewed redundancy, named owner, and a workable test path	In-place upgrade	Baseline costs, test a representative account, then schedule production changes
GPv1 Storage account using Standard_ZRS	Prioritized upgrade before October 13, 2026	Confirm the appropriate GPv2 redundancy outcome and complete the change before the retirement date
BlobStorage account with unresolved tiering, cost, ownership, or target architecture questions	Planned migration assessment	Resolve workload design and governance questions before committing to the irreversible upgrade

This table is intentionally conservative. It does not say that every BlobStorage account needs data copied into a new account. It says that unresolved design and ownership questions should be resolved before an irreversible account-kind change is treated as routine.

---

Why GPv1 with Standard_ZRS belongs at the top of the list​

GPv1 accounts with standard ZRS are the urgent special case. Microsoft says these accounts must be upgraded before October 13, 2026 to avoid service disruption.
Microsoft also says that automatic migration for GPv1 accounts using standard ZRS uses an equivalent or nearest available redundancy setting. That is a reason to review the account deliberately before the deadline, not a universal promise about the result for every legacy storage configuration.
The relevant question is not simply whether the account has ZRS in its SKU name. The team needs to identify whether it is a legacy GPv1 Storage account using Standard_ZRS, determine what redundancy configuration is appropriate for the workload after GPv2, and test the application against the planned configuration.
Do not leave these accounts for a final-week cleanup. They deserve an owner, a scheduled change, and a documented validation result.

Treat BlobStorage upgrades as irreversible decisions​

GPv2 brings capabilities that may be useful for blob-heavy workloads, including blob tiering, lifecycle management, and broader redundancy choices. But capability is not the same as a completed design.
Microsoft warns that GPv2 can alter billing, particularly transaction costs. That warning is especially relevant for transaction-heavy workloads, ingestion pipelines, analytics jobs, backup systems, and applications that generate frequent reads, writes, listings, or metadata operations. A self-directed conversion gives the team a before-and-after baseline; waiting until a deadline period makes it harder to distinguish normal workload growth from a changed pricing model.
A legacy BlobStorage account should receive a planned migration assessment when any of the following is true:

• The application team cannot explain the expected access pattern or tiering strategy.
• Monthly transaction costs are material and have not been baselined.
• The account has no named business owner or test contact.
• The correct redundancy choice remains unresolved.
• The organization plans to introduce lifecycle policies or tiering rules but has not approved their behavior.
• The workload has weak monitoring, limited test coverage, or a narrow operational window.

The critical fact is that a BlobStorage account cannot be returned to its prior account kind after it is upgraded to GPv2. The practical response is not necessarily “build a new account.” It is “make the decision with enough information to operate the result.”

---

Fix provisioning templates before they create another exception​

The GPv1-with-ZRS guidance says customers will no longer be able to create new GPv1 accounts with ZRS redundancy after September 2026. Even if a team has few or no legacy accounts today, old deployment artifacts can preserve the problem for tomorrow.
Search source repositories, deployment pipelines, and internal modules for:

• kind: Storage
• kind: BlobStorage
• Standard_ZRS paired with legacy Storage
• Old scripts or templates that do not explicitly deploy StorageV2

Resource Graph finds what is deployed. It does not find the old ARM template, Bicep module, Terraform resource definition, or script that will fail—or recreate a legacy configuration—during a future release.
The target state for new general-purpose storage provisioning should be StorageV2. Make that template remediation part of the same workstream as the account inventory, then require an exception review for any legacy declaration that remains.

---

Validate after the change, not just after the account type changes​

A successful upgrade is the midpoint of the work. The value of a phased approach is that it creates evidence before broad production rollout.
Use this checklist for each representative account and then for each production change group:

• Record the pre-change account kind, redundancy setting, access tier, workload owner, and baseline storage and transaction costs.
• Confirm the account reports the intended GPv2 configuration after the change.
• Perform real application validation: reads, writes, uploads, scheduled jobs, ingestion workflows, backup processes, and operational scripts.
• Review access-tier expectations and any lifecycle-management rules the team intends to use.
• Compare post-change transaction and storage charges with the pre-change baseline.
• Create or adjust cost alerts before the next normal billing review.
• Document the accountable owner, test result, observed cost change, and follow-up actions.

A low-risk test should be representative rather than merely convenient. Testing an idle development account provides less useful evidence than testing a noncritical account with the same access pattern, transaction profile, and deployment model as the production group that will follow.
WindowsForum’s broader Azure discussions are also a reminder that storage changes are rarely isolated from operations. Access control, monitoring, and application behavior should be reviewed alongside the storage-account decision, particularly for workloads that expose data to multiple services or automation paths.

Frequently Asked Questions​

Can we wait for Microsoft to migrate our GPv1 accounts automatically?​

Microsoft says remaining GPv1 accounts will be automatically migrated to GPv2 in October 2026. Waiting is possible, but it gives up control of timing and makes it harder to establish a clean before-and-after billing baseline. GPv1 accounts using standard ZRS should not wait: Microsoft says they must be upgraded before October 13, 2026 to avoid service disruption.

Does every legacy account require a new storage account and a data copy?​

No. Microsoft documents an upgrade path from GPv1 or BlobStorage to GPv2. A separate migration project is appropriate when the desired architecture requires a different region, a redesigned redundancy model, a new account structure, or application changes beyond the account upgrade itself.

Can a BlobStorage account be returned to its old account kind after GPv2 conversion?​

No. Microsoft says legacy BlobStorage accounts can be upgraded to GPv2 but cannot be downgraded back to BlobStorage.

Why baseline transaction costs before upgrading?​

Microsoft warns that GPv2 can change billing, especially transaction costs. Capturing a pre-change baseline lets the team compare normal workload behavior with post-upgrade charges and respond using evidence rather than assumptions.

What is the most urgent account type to identify?​

GPv1 Storage accounts using Standard_ZRS. Microsoft says they must be upgraded before October 13, 2026 to avoid service disruption, and automatic migration uses an equivalent or nearest available redundancy setting for that scenario.
The deadline is fixed, but the schedule should be deliberate: inventory legacy accounts now, remove legacy provisioning paths, prioritize standard-ZRS GPv1 accounts, test representative workloads, and enter the final retirement period with production changes already understood rather than still being discovered.

---

References​

1. Primary source: learn.microsoft.com
   
   

   How to upgrade a General Purpose v1 (GPv1) with ZRS redundancy account to GPv2 - Azure Storage | Microsoft Learn

   Learn how to upgrade a ZRS Classic storage account to a General Purpose V2 account.

   learn.microsoft.com
2. Primary source: WindowsForum
   
   

   Azure Blob Storage Auto-Migrates Legacy Accounts After October 13, 2026 | Windows Forum

   Microsoft will stop accepting requests to create new legacy BlobStorage accounts in September 2026 and says remaining legacy Blob Storage accounts will be...

   windowsforum.com