Azure SQL API version upgrade notification

Hi @Tikoo, Shivata
Based on the information you've shared, your understanding is correct. The retirement of Azure SQL REST API version 2014-04-01 applies to the Azure Resource Manager (management plane) API and does not affect the runtime operation of Azure SQL databases or application connectivity.

To address your questions:

1. Do these advisor resources require any action from your side?

The advisor resources such as DbParameterization, DefragmentIndex, DropIndex, and ForceLastGoodPlan are part of Azure SQL Automatic Tuning/Advisor. If you are not explicitly deploying or managing these resources through your own ARM/Bicep templates, SDKs, or direct REST API calls, there is generally no action required for these Azure-managed resources.

2. Will the retirement affect the runtime operation of Azure SQL databases?

No. The retirement affects only management operations that explicitly invoke the retired REST API version (2014-04-01). It does not impact database availability, client connectivity, or application workloads.

3. Is any action required from your side?

The recommended approach is to review your customer-managed automation, such as ARM/Bicep templates, Terraform configurations, Azure CLI or PowerShell scripts, SDKs, or custom applications, and ensure they are not explicitly using API version 2014-04-01. If they are, update them to a supported API version. If your deployments do not reference this API version, no further action is required.

4. Why do newly deployed Azure SQL resources still appear with API version 2014-04-01 in exported ARM templates?

The API version shown in an exported ARM template reflects the resource provider schema used during template export and does not necessarily indicate that the Azure SQL service or your deployment is actively using that API version for management operations. The retirement guidance is intended for customer-authored management requests that explicitly target the retiring API version. Any updates required for Azure-managed resources are handled by the Azure platform.

Based on your description, since these advisor resources are Azure-managed and are not part of your Infrastructure-as-Code, your primary focus should be verifying that your own templates, scripts, or applications do not explicitly reference API version 2014-04-01.

For additional information, please refer to the official documentation: https://learn.microsoft.com/rest/api/sql/retirement

I hope this clarifies your concern. Please let us know if your deployment templates or automation explicitly reference API version 2014-04-01, and we'll be happy to assist further.

If you find this information helpful, please consider accepting the answer so it can benefit other community members facing a similar question.

Hello Tikoo, Shivata,

Greetings! Thanks for raising this question in Q&A forum.

You have asked exactly the right questions, and I want to give you a clear, direct answer to each one.

The reason you are seeing this notification is that Microsoft sent out retirement warnings to all customers who have the Microsoft.SQL resource provider registered in their subscription, which effectively means anyone using Azure SQL databases received this notification. The confusion arises because the advisor resources you see in the exported ARM template (DbParameterization, DefragmentIndex, DropIndex, ForceLastGoodPlan) are Azure-managed Automatic Tuning advisor resources, not resources you deployed yourself.

To address each of your questions directly:

1. Do these advisor resources require any action from your side?

No. These four advisor resources (DbParameterization, DefragmentIndex, DropIndex, ForceLastGoodPlan) are system-generated and fully managed by the Azure SQL platform. You did not deploy them through your IaC pipelines, and you are not responsible for updating them. Microsoft manages the API version used internally by these platform resources. The fact that they appear in an exported ARM template does not mean you are calling the 2014-04-01 API yourself.

2. Will the retirement affect your SQL database runtime or connectivity?

This change only affects management operations such as ARM templates, REST API calls, CLI, or PowerShell scripts. It does not impact your database runtime or connectivity. Your applications connecting to Azure SQL via connection strings, ADO.NET, or SQL drivers are completely unaffected.

3. What action, if any, is required from your side?

The only action required is to check whether any of your own scripts, pipelines, or ARM/Bicep templates explicitly call the 2014-04-01 API version. Here is how to do that quickly:

1. Search your own Bicep and ARM template files in your repositories for the string 2014-04-01. Since you already confirmed these advisor resources are not in your templates, this is likely clean.

Run the following query in Azure Resource Graph Explorer in the portal to check across your subscription:

resources
| where type startswith 'microsoft.sql'
| where properties.apiVersion == '2014-04-01'
| project name, type, location, subscriptionId

If you are currently using the Azure portal, Azure CLI, or Azure PowerShell to manage Azure SQL Database, you do not need to take any action.

If the above checks come back clean, you have nothing to remediate. You can safely disregard the advisor for these four platform-managed resources.

4. Why do newly deployed Azure SQL resources still reference the retired API version through advisor resources?

This is a known inconsistency and a fair criticism. The Azure platform itself still exposes these advisor resources using the 2014-04-01 version when you export a template, even for resources deployed in 2026. This is a Microsoft-side issue with the platform's own internal API surface for these advisor types. The retirement notice is aimed at customer-authored API calls and templates, not at platform-generated advisor metadata. Microsoft is responsible for migrating these internal advisor resources on their end.

In summary, your understanding is correct. These advisor resources are Azure-managed, you do not own them, and you have no remediation action to take for them specifically. Your only task is to verify your own templates and code are free of explicit 2014-04-01 API references, which it sounds like they already are.

Reference: https://learn.microsoft.com/en-us/rest/api/sql/retirement

If this answer helps you kindly accept the answer which will help others who have similar questions.

Best Regards,

Jerald Felix.