Can't upgrade my burstable tier.

Question

I am currently on Burstable, B1ms, 1 vCores, 2 GiB RAM, 20 storage, 360 IOPS and I am having issues with my MySQL database. So i was going to upgrade my server to the next tier and I am getting this error message. What could my problem be?

{

"code": "DeploymentFailed",

"target": "/subscriptions/XXXXXXXXXX/resourceGroups/XXXXXXXXXX/providers/Microsoft.Resources/deployments/UpdateMySqlFlexibleServer__4d7977906500405d9b2ea4c8eb694ada",

"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.",

"details": [

The server is currently in 'updating' state. Please wait for the operation to complete. You can refresh to check status. Reach out to Microsoft support if the operation is taking too long. 

{

  "code": "ResourceDeploymentFailure",

  "target": "/subscriptions/XXXXXXXXXX/resourceGroups/XXXXXXXXXX/providers/Microsoft.DBforMySQL/flexibleServers/XXXXXXXXXX",

  "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."

}
```  ]

}

Answer 1

Hi Zim,

Thank you for reaching out to Microsoft Q&A.

Why you’re seeing DeploymentFailed + InternalServerError

Your output shows two important signals:

1. “The server is currently in ‘updating’ state” When a MySQL Flexible Server is in Updating, Azure is already running a management operation (scale, patch, maintenance, start/stop, parameter change). While Updating is active, most writes (including compute tier changes) are blocked until the earlier operation succeeds or rolls back. Attempting another change during that window typically returns DeploymentFailed. This is expected platform behavior.
2. Terminal provisioning state 'Failed' with InternalServerError This indicates the backend operation hit a platform-side failure while applying your change. When that happens, the resource may remain Updating or Stopped until the control‑plane unlocks it or a restart completes. You should inspect deployment operations and the Activity Log using the correlation/tracking ID to see the precise failing step and message.

In short, you likely tried to scale while the server was already updating (or after a failed update), which caused a conflict and the terminal failure.

Common root causes to check

• Concurrent operation or maintenance: Scheduled maintenance can place the server in Updating; do not start/stop or scale during maintenance. Wait for it to finish, then retry.
• Previous scale/start/stop still in progress or stuck: Servers can remain Updating after a portal/CLI change fails. A controlled restart often clears it.
• Regional capacity / SKU availability: Auto‑allocation issues can return internal errors when a specific compute size isn’t currently available in the region; retry later or pick another size/tier.
• Resource provider or subscription constraints: Some failures are quota or RP registration related; check registration and quotas if errors persist.

Immediate troubleshooting (safe sequence)

Goal: Get the server back to a healthy state, then apply the scale.

1. List the exact deployment operations (to see which step failed)

Shell

# Replace <rg> and <deploymentName> with the values shown in your error

az deployment operation group list \

--resource-group <rg> \

--name <deploymentName> \

--query "[].{opName:properties.provisioningOperation,status:properties.provisioningState,response:properties.response}"

This surfaces the operation details and any nested error codes referenced by DeploymentFailed.

1. Check the Activity Log using the tracking ID

Shell

az monitor activity-log list \

--correlation-id b3bfd08e-4526-484b-b4cd-36bdfad5d2dd \

-o json

``

Correlates the control‑plane event and returns the inner message (for example, maintenance, allocation, or network constraints).

1. Verify current server state

Shell

az mysql flexible-server show \

--resource-group <rg> \

--name <serverName> \

--query "{state:state,version:version,sku:sku.name}"

``

Proceed only if state is Ready. If it’s Updating/Stopped, do not issue new changes.

1. If stuck, attempt a controlled restart (after verifying there’s no active maintenance in the portal):

Shell

az mysql flexible-server restart \

--resource-group <rg> \

--name <serverName>

``

A restart is the supported way to clear transient update locks; compute scaling itself performs a restart. Avoid repeated restarts—wait ~5–10 minutes between attempts.

1. Retry the scale only when the server is Ready from Burstable (B1ms) you can increase vCores within Burstable or move to General Purpose/Business Critical. Compute scaling restarts the server; storage can only scale up. Plan a short maintenance window.

Thanks,
Vrishabh