Unable to downgrade legacy zone-redundant Azure Container Registry from Premium to Standard

Question

Unable to downgrade legacy zone-redundant Azure Container Registry from Premium to Standard

Eric Lee 0

I have an existing Azure Container Registry in Canada Central that I’m trying to downgrade in place from Premium to Standard.

The registry was created with the legacy zoneRedundancy property set to Enabled. Current Microsoft documentation says that zone redundancy is supported automatically for all ACR service tiers and that the legacy property no longer controls zone-redundancy behavior.

The registry is not using any other Premium-only features:

No geo-replications
No private endpoints
No customer-managed key
No IP or virtual-network rules
No connected registries
Approximately ~150 GiB of stored artifacts, which is below Standard’s maximum capacity

I attempted the change using Azure CLI 2.84.0:

az acr update \
  --resource-group <resource-group> \
  --name <registry-name> \
  --sku Standard

I also attempted the update through the Azure portal and directly through the current REST API:

PATCH https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ContainerRegistry/registries/<registry-name>?api-version=2025-11-01
Content-Type: application/json

{"sku":{"name":"Standard"}}

All three methods return:

Cannot update the registry SKU due to reason: Registry has zone-redundancy enabled. Currently, zone-redundancy cannot be updated after registry creation.

The request is rejected without changing the registry. The existing registry remains healthy and on Premium.

This appears inconsistent with the current documentation:

My questions are:

Is this a known limitation for older registries created with zoneRedundancy: Enabled?
Is there a supported way to clear or migrate the legacy property so the registry can be downgraded in place?
Can Microsoft migrate the registry’s resource metadata on the backend without requiring registry recreation?
If creating a new Standard registry is the only supported solution, can the documentation explicitly identify legacy zone-redundant registries as an exception to in-place SKU switching?
Is there an officially recommended migration procedure that preserves OCI indexes, child manifests, signatures/attestations, and image digests?

I do not currently have an Azure support plan, so I would appreciate confirmation from the ACR product team or someone familiar with this legacy property.

0 comments

2 answers

Your answer

Answer 1

Your checks match the documented prerequisites for a Premium-to-Standard change: remove Premium-only resources and stay within Standard storage limits. Current ACR documentation says zone redundancy applies to every tier in supported regions and the legacy zoneRedundancy property no longer controls behavior. An immutable-property rejection therefore is not something you can repair through CLI, portal, or a supported ARM edit. Azure Support must reconcile the registry metadata; public documentation provides no customer-accessible method to clear that flag or guarantee an in-place backend migration. If you cannot wait, create a Standard registry and use az acr import from the source. Import every required tag or digest; multi-architecture images copy all referenced platforms. Separately inventory OCI referrers, signatures, attestations, RBAC, webhooks, tasks, and retention settings. Verify digests and signature validation before cutting workloads over, and keep the old registry until validation is complete.

Answer 2

Hello @Eric Lee,

Thank you for using Q & A forum.

Answers to your questions

Is this a known limitation for older registries created with zoneRedundancy: Enabled?

Based on the error and the documentation, it appears very likely that legacy ACR resources created when zone redundancy was a Premium-only opt-in feature are still treated differently by the resource provider. The SKU update API is apparently checking the historical zoneRedundancy flag instead of the new service behavior.

Is there a supported way to clear or migrate the legacy property?

The current documentation indicates the property is being deprecated, but it does not provide a migration path for existing resources that still carry the flag.

Can Microsoft migrate the resource metadata on the backend?

Potentially yes, but only Microsoft engineering can confirm this.

Because the failure is coming from the ACR resource provider rather than from artifact storage limits or SKU limits, a backend metadata migration would theoretically be possible if supported by the product team. However, there is no public statement that such a migration service exists.

Should documentation call out legacy registries as an exception?

I would say yes.

The current documentation states that:

Zone redundancy is available across all SKUs.

The legacy property no longer controls behavior.

Migration procedure that preserves OCI indexes, signatures, attestations, and digests?

If recreation becomes necessary, use an OCI-aware copy mechanism rather than pull/tag/push.

Recommended tools include:

az acr import (for registry-to-registry copies)

oras

skopeo

regclient/regsync

If this answers your query, do click Accept Answer and Up-Vote for the same. And, if you have any further query do let us know.