Storage accounts should be migrated to new Azure Resource Manager resources

What does the recommendation "Storage accounts should be migrated to new Azure Resource Manager resources" check?

Flags any storage account still deployed under the legacy classic (Azure Service Manager) model rather than Azure Resource Manager. It looks only at the deployment model of the account itself: it does not inspect the data inside, the encryption settings, the network rules or whether anonymous access is enabled. A modern Resource Manager storage account, even a poorly configured one, never trips this check, and a classic account always does regardless of how well it is otherwise secured.

Why does "Storage accounts should be migrated to new Azure Resource Manager resources" matter?

Classic storage accounts were fully retired on 31 August 2024, so this is a deprecated resource model that should no longer exist in your estate. Management through Azure Service Manager has stopped, which means a classic account left behind can become unreachable for routine operations while still holding live data. Beyond the retirement, the classic model cannot use Azure RBAC, managed identities, resource locks, customer-managed keys or Microsoft Entra authentication, and it sits outside Resource Manager policy and tagging. That means a classic account is effectively invisible to the controls that govern everything else, so it becomes an unmanaged blind spot: access cannot be scoped granularly, activity is harder to audit, and a single forgotten classic account can hold business data that no policy is watching. Migrating brings the account under the same governance, access control and monitoring as the rest of your subscription, and removes a fragile dependency on a retired platform.

How do I fix "Storage accounts should be migrated to new Azure Resource Manager resources"?

1. Register the migration resource provider once per subscription with 'Register-AzResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate' and wait until its RegistrationState reads 'Registered'.
2. Run the migration in stages using the classic PowerShell cmdlet: 'Move-AzureStorageAccount -Validate -StorageAccountName <name>' to check readiness, then '-Prepare' to stage the Resource Manager account, and finally '-Commit' to complete it (or '-Abort' to roll back before commit). The modern 'az' CLI has no dedicated command for classic-to-ARM storage migration, so use the portal or this PowerShell path.
3. After migration, assign the built-in audit policy to catch any future regressions by looking it up by display name rather than hardcoding a GUID: pid=$(az policy definition list --query "[?displayName=='Storage accounts should be migrated to new Azure Resource Manager resources'].name" -o tsv); az policy assignment create --name audit-classic-storage --policy "$pid" --scope <subscription-scope>.

# Close the highest-impact storage exposure first: anonymous read AND plain HTTP.
for acct in $(az storage account list \
    --query "[?allowBlobPublicAccess].name" -o tsv); do
  az storage account update --name "$acct" \
    --allow-blob-public-access false \
    --https-only true \
    --min-tls-version TLS1_2
  echo "$acct: anonymous access disabled, secure transfer required, min TLS 1.2"
done

# Ratchet it shut: deny any future account that allows anonymous access.
az policy assignment create \
  --name deny-anon-blob \
  --policy 13e6c4f1-e83f-4b50-a677-2cf6e2b9c885 \
  --scope "/subscriptions/00000000-0000-0000-0000-000000000000"