An Azure service that provides access to a secure, dedicated Redis cache, managed by Microsoft.
A persistently stuck Cancelling migration must be investigated through an Azure support request so the backend migration state can be repaired or removed before the original AutobetUKS cache can be deleted.
Open the support request
- In the Azure portal, open the original Azure Cache for Redis resource,
AutobetUKS. - Select Support + Troubleshooting under Help.
- Run any offered diagnostics, then select Create a support request.
- Choose the closest available problem type to:
- Service: Azure Cache for Redis
- Problem type: Migration to Azure Managed Redis
- Problem subtype: Retirement and Migration of Azure Cache for Redis
- State clearly in the ticket:
- Source cache:
AutobetUKS - Attempted migration target:
autobet-uks - Migration failed and remains in Cancelling
- The replacement Azure Managed Redis instance was created independently and is now serving production traffic
- The source cache is no longer used
- Portal deletion is blocked by the migration state
- Request: Investigate and repair or remove the stuck backend migration state so the source cache can be deleted
- Source cache:
Technical support requests may require an Azure support plan.^1^
Include the operation evidence
Capture the failed migration/cancellation operation so Support can trace it:
- Open the resource group containing
AutobetUKS. - Select Activity log.
- Filter by the Redis resource, operation, and the migration/cancellation time range.
- Open the relevant failed or pending entry.
- Select JSON, copy the Correlation ID, and include it in the ticket.
Azure Resource Manager assigns each operation a correlation ID specifically for tracing requests across services.^2^
Also include:
- Full resource ID of
AutobetUKS - Subscription and resource-group names
- Migration start and cancellation times in UTC
- Current provisioning/migration status
- Exact deletion error
- Screenshots of the Cancelling status
- Confirmation that applications now use the independently created Managed Redis hostname
Do not post subscription IDs or correlation IDs publicly; provide them only through the private support request.
Why deletion remains blocked
The migration tooling documentation states that other management operations are blocked while migration is active.^3^ It does not document a client-side recovery procedure for a migration that remains indefinitely in Cancelling. In this case, the stuck state appears to be retaining the management-operation block.
As an analogous—not identical—case, an Azure Redis resource stuck during a resource move required backend engineering to correct its provisioning state before management operations resumed.^4^
Delete only after the state is cleared
After Support confirms that the migration/provisioning state has been corrected, delete the original cache from the portal or use Azure CLI:
az redis show \
--name AutobetUKS \
--resource-group <source-resource-group>
az redis delete \
--name AutobetUKS \
--resource-group <source-resource-group> \
--yes
az redis delete is the documented command for deleting an Azure Cache for Redis resource.^5^ It will not repair or bypass the stuck migration state, so retry it only after Support confirms that the backend operation is cleared.
Before deletion, retain the existing confirmation that all applications use autobet-uks; Microsoft’s decommissioning guidance is to verify application behavior, performance, and errors against the new instance before deleting the old cache.^6^
References
- Create an Azure support request
- Get operation correlation ID from Activity Log for Microsoft Discovery
- Migrate with tooling (preview) - Basic, Standard, and Premium tiers to Azure Managed Redis
- Azure Cache for Redis resource move stuck in provisioning state for over 72 hours - Microsoft Q&A
- Manage an Azure Redis cache using the Azure CLI
- Plan migration execution - Basic, Standard, and Premium tiers to Azure Managed Redis