PostgreSQL Flexible Server upgrade from v12 → v14 fails with InternalServerError

Hi Blueoshan Support,

Thank you for reaching out to Microsoft Q&A.

That error usually means something went wrong in the control plane during the orchestration phase. It’s not always about your configuration—it can be triggered by unsupported features or extensions that the backend checks after prechecks. To confirm the exact cause, Azure Support will need your Tracking ID to review logs.

Microsoft Learn explains the upgrade process and limitations in detail:

• Major Version Upgrade – How-To
• Major Version Upgrade – Concepts & Limitations

Things to double-check before retrying

1. Supported version Version 14 is still supported. Check the Version Policy.
2. Extensions Some extensions block upgrades:
   • timescaledb, pgaudit, dblink, orafce, pg_partman, postgres_fdw Drop these if they exist anywhere on the server. Full list: Extensions & Versions.
   1. Replication
      • Remove read replicas before upgrading.
        • Disable logical replication slots.
        1. Storage type SSDv2 storage is currently not supported for major upgrades.
        2. Free space Keep at least 10–20% free storage for temporary files during upgrade.
3. PostGIS PostGIS is supported but make sure it’s allow-listed at the server level (azure.extensions) and installed consistently across databases: How to allow extensions.

Quick SQL checks

SQL

-- Check extensions per database

SELECT current_database() AS db, extname, extversion FROM pg_extension ORDER BY 1,2;

-- Check allow-listed extensions

SHOW azure.extensions;

If these steps don’t resolve the issue, please send us a private message with:

• Subscription id:
• Tenant id:
• Your registered email id:
• Resource URI of the server:
• Time zone:
• Tracking id:

The Tracking ID helps engineering pull internal logs. More details: How to perform a major version upgrade.

Alternative approach if time-sensitive

If you can’t wait for backend investigation, consider migrating instead of upgrading:

• Create a new Flexible Server on v14
• Enable required extensions
• Use Azure DMS or pg_dump/pg_restore for migration This avoids orchestration issues and unsupported scenarios.

TL; DR:

• Validate extensions, replication, storage type, and free space
• Ensure PostGIS is allow-listed and consistent
• If retry fails, share Tracking ID with Support
• If urgent, migrate to a new v14 server

Hope the above steps were helpful. If you have any other questions, please feel free to contact us.

Thanks,
Vrishabh