If you manage an Azure subscription, you may have recently received a notice from Microsoft about a legacy storage account retirement. It shows up in the Azure portal under Service Health, Health advisories, and it is easy to skim past as one more compliance email. It should not be skimmed past. Microsoft is retiring general purpose v1 storage accounts and legacy blob only storage accounts on October 13, 2026, and any account you have not migrated by that date will be migrated for you, on Microsoft's schedule rather than yours.
Here is what this notice actually means, why it is worth acting on now instead of waiting, and the exact steps to migrate a general purpose v1 account to general purpose v2 yourself.
What is actually being retired
Two related account types are affected. General purpose v1, often called GPv1, is the original Azure Storage account type, and it predates most of the features Azure Storage has today. Legacy blob only storage accounts are a related older account type built specifically for blob storage. Both are being retired on October 13, 2026. After that date, general purpose v2, or GPv2, becomes the only supported account type for these workloads.
GPv2 is not a downgrade dressed up as an upgrade. It gives you access to the storage features Microsoft has shipped over the past several years, better performance characteristics, and true zonal redundancy support, which GPv1 never fully offered. If your organization has had a GPv1 account running quietly for years because nobody wanted to touch a working system, this retirement is actually a reasonable excuse to finally move it forward.
What happens if you do nothing
Microsoft has been direct about this part. If a GPv1 or legacy blob storage account is not migrated before October 13, 2026, Microsoft will migrate it automatically on your behalf. Microsoft's own notice describes your decision not to migrate as consent for them to do it for you. The automatic migration can also result in higher billing costs, since you lose the chance to plan the change around your own configuration and pricing tier choices. On top of that, creation of any new GPv1 accounts will be blocked entirely by the same date.
None of this is catastrophic if it happens to you. It just means less control over the timing and outcome than doing it yourself gives you, and for most organizations, a planned migration during a quiet maintenance window beats an unplanned one on Microsoft's calendar.
A special note if you use Azure Databricks
If your Azure Databricks workspace relies on a GPv1 storage account for its managed storage, you cannot migrate that specific account manually, and you do not need to. Microsoft has stated it will schedule and complete a managed migration of affected Databricks storage accounts on your behalf as part of this retirement, with separate notifications sent when that migration is planned. Any other GPv1 accounts in your subscription that are not tied to Databricks managed storage still require the manual migration covered below.
Step 1: Find every GPv1 account in your subscription
Before migrating anything, confirm what you actually have. In the Azure portal, open Storage accounts, then look at the Storage Center view and filter or sort by Kind. Any account listed simply as Storage, rather than StorageV2 or BlobStorage, is a GPv1 account and is in scope for this retirement. It is worth checking every subscription your organization has, since these accounts tend to hide in older resource groups nobody has opened in a while.
Step 2: Migrate using the Azure portal
For most accounts, this is a two minute task with no downtime and no risk to your data. Microsoft's own documentation confirms the upgrade happens through a Resource Manager operation that changes the account type in place. Your service endpoints, access keys, and shared access signatures all stay exactly as they were.
In the Azure portal, open the storage account you want to migrate, go to Settings, then Configuration. Under Account kind, select Upgrade. Type the name of the storage account to confirm you mean it, then select Upgrade at the bottom of the panel. That is the entire process.
Step 3: Migrate using PowerShell instead
If you are managing more than a handful of accounts, or you simply prefer scripting this over clicking through the portal, PowerShell handles it in one line:
Set-AzStorageAccount -ResourceGroupName <resource_group> -AccountName <storage_account> -UpgradeToStorageV2
Replace the resource group and storage account name with your own values, and run it against each account identified in Step 1.
Step 4: Migrate using Azure CLI
The Azure CLI equivalent is just as short:
az storage account update --name <StorageAccountName> --resource-group <ResourceGroup> --set kind=StorageV2
This is the more practical option if your infrastructure is already managed through CLI scripts or a CI/CD pipeline, since it drops straight into an existing deployment process without introducing a new tool.
A note on accounts using zone redundant storage
If your GPv1 account uses ZRS, zone redundant storage, the same portal, PowerShell, and CLI steps above still apply, and it is still a non disruptive in place upgrade. The one thing worth checking first is whether your account's region actually supports GPv2 with ZRS. If it does not, the upgrade will not be available, and you will need to either open a support request to upgrade to GPv2 with a different redundancy option such as LRS or GRS, or plan a migration of the account into a region that does support ZRS.
Managing this at scale with Azure Policy
If your organization has many GPv1 accounts spread across subscriptions, checking and upgrading each one manually does not scale well. Microsoft publishes a sample deployIfNotExists Azure Policy specifically for this scenario, which detects general purpose v1 accounts across your environment and performs the same non disruptive upgrade automatically wherever it finds one. For an organization with dozens of legacy accounts scattered across old projects, this is a far more reliable path than trying to track every account by hand in a spreadsheet.
About the Microsoft livestream sessions
Microsoft's original notice invited subscribers to two live Q&A sessions in late June 2026 with the engineering team behind this retirement. Both sessions have already taken place by the time most organizations are reading this. If you missed them, a recording was expected to be posted afterward, and the best place to check for it, along with any further updates on this retirement, is Microsoft's own Azure Updates page rather than searching for it separately.
Frequently asked questions
What is the deadline to migrate a GPv1 storage account?
October 13, 2026. After that date, Microsoft will automatically migrate any remaining general purpose v1 or legacy blob only storage accounts on your behalf, and creation of new GPv1 accounts will be blocked entirely.
Will migrating from GPv1 to GPv2 cause downtime?
No. Microsoft's documentation confirms the upgrade is a Resource Manager operation that changes the account type in place, with no loss of durability or availability during the process. Your endpoints, access keys, and shared access signatures remain unchanged.
Do I need to do anything for Azure Databricks managed storage accounts?
No, not if the account is specifically Databricks managed storage tied to a workspace. Microsoft will schedule and complete that migration on your behalf and will notify you separately when it happens. Any other GPv1 accounts in the same subscription that are not Databricks managed storage still need to be migrated manually.
What happens if I do not migrate before the deadline?
Microsoft will migrate the account automatically after October 13, 2026. Microsoft's notice states that not migrating is treated as consent for them to do it on your behalf, and the automatic migration may result in higher billing costs compared to a migration you plan and configure yourself.
If you want a hand finding every legacy storage account across your Azure environment and getting them migrated properly before the deadline, our Azure cloud infrastructure team can take care of it for you, along with the rest of your Azure environment. Get in touch and we will help you get ahead of this before it becomes Microsoft's problem to solve on your behalf.