Action required if service identified is Microsoft backups? "Retirement Notice: Transition Azure Database for PostgreSQL Preview APIs to Preview API version 2026-04-01 by 30 January 2027"

If the ltrPreBackup request is generated solely by the Azure Backup vaulted-backup workflow, no backup-policy or PostgreSQL configuration change is required; Microsoft must update that service-managed call, while any customer-authored client using 2023-03-01-preview must be migrated before 30 January 2027.

Azure Backup invokes the PostgreSQL Flexible Server ARM API according to the configured backup schedule and performs the backup through service-managed infrastructure. Customers configure the policy and permissions but do not select the PostgreSQL resource-provider API version used internally by that workflow.^1^

Final validation: identify who initiated the call

You have already identified the relevant URI, so inspect the complete Activity Log event rather than searching again:

az monitor activity-log list \
  --correlation-id "<correlation-id>" \
  --offset 30d \
  --query "[].{time:eventTimestamp,caller:caller,operation:operationName.value,\
resourceId:resourceId,claims:claims,httpRequest:httpRequest}" \
  -o json

Administrative Activity Log events expose the initiating caller, authentication claims, operation, resource ID, and HTTP request details.^2^

Interpret the result as follows:

• Microsoft/Azure Backup managed identity or service identity, with timestamps corresponding to scheduled or on-demand vaulted-backup jobs: treat it as a Microsoft-managed dependency. Leave the Backup vault, policy, role assignments, and PostgreSQL server unchanged.
• Your application registration, service principal, managed identity, user, pipeline, Terraform/AzAPI deployment, or script identity: update that client to an API version supported by the operation.
• Caller is blank or ambiguous: correlate the timestamp with Backup Center → Backup instances → select the PostgreSQL instance → Jobs, then open an Azure support request under Azure Database for PostgreSQL or Azure Backup. Include tracking ID SJRX-YHZ, timestamp, correlation ID, operation name, caller/claims, and sanitized URI. Ask Microsoft to confirm that the affected-resource record represents the Azure Backup-managed LTR workflow.

Check for customer-owned dependencies

Before marking the notice as requiring no customer action, search source control, pipelines, runbooks, Logic Apps, Functions, and IaC for:

2023-03-01-preview
Microsoft.DBforPostgreSQL
ltrPreBackup
ltrBackupOperations

The PostgreSQL API release notes say versions not listed as recommended may be approaching retirement, and they identify Long-Term Retention as a supported operation area.^3^

If customer code makes the call:

1. Change its PostgreSQL management API version to 2026-04-01-preview or a later version that supports the required operation.
2. Revalidate the request and response schema; preview API behavior and properties can change.
3. Test backup initiation and operation-status retrieval outside production.
4. Deploy before 30 January 2027 and verify that subsequent Activity Log URIs no longer use 2023-03-01-preview.

The Microsoft.DBforPostgreSQL/flexibleServers/ltrBackupOperations resource definition explicitly supports 2026-04-01-preview.^4^

Therefore, if the caller validation shows Azure Backup and the repository search finds no customer-authored use of the retiring API, there is no migration action for your team. Continue monitoring backup jobs and retain the Activity Log evidence; Microsoft owns the API-version transition inside its managed backup workflow.

References

1. About Azure Database for PostgreSQL - Flexible Server backup
2. Azure Activity Log event schema
3. Release notes for the REST APIs for Azure Database for PostgreSQL flexible server
4. Microsoft.DBforPostgreSQL flexibleServers/ltrBackupOperations 2026-04-01-preview (deployment-language-arm-template)