Share via

Migrating from Azure Database for PostgreSQL Flexible Server to another Flexible Server fails with "Unsupported extension(s)"

Mette Bryde Frisk 0 Reputation points
2026-06-04T08:01:00.13+00:00

We are migrating from Azure Database for PostgreSQL Flexible Server to another Flexible Server due to networking changes.

We are using the new PostgreSQL Migration Service in offline mode where we as source server type select On-premises server.

The validation fails with:

Error 603405: Unsupported extension(s). The migration service does not support the migration of databases with 'azure, pgaadauth' extension(s) on the source server.

Source and target are both PostgreSQL 14 Flexible Servers.

The only extensions present on the source are:

pgaadauth | 1.10

azure | 1.1

These are Azure-managed extensions. They cannot be dropped because:

ERROR: extension "azure" is not allow-listed for "azure_pg_admin" users

The target server contains the same extensions.

Is this a known limitation or bug in Migration Service validation for Flexible Server-to-Flexible Server migrations? Is there a supported workaround?

Azure Database Migration service

Answer accepted by question author

Manoj Kumar Boyini 16,150 Reputation points Microsoft External Staff Moderator
2026-06-04T09:04:53.3066667+00:00

Hi @Mette Bryde Frisk

The migration path being attempted (Azure Database for PostgreSQL Flexible Server to another Azure Database for PostgreSQL Flexible Server using the PostgreSQL Migration Service) is currently not supported.

As a result, validation may fail when it encounters Azure-managed extensions such as azure and pgaadauth, even though these extensions are present on both the source and target servers.

At this time, there is no supported workaround within the PostgreSQL Migration Service for Flexible Server-to-Flexible Server migrations.

We understand your goal is to move between Flexible Servers due to networking changes. Unfortunately, this migration scenario is not currently supported by the service.

We appreciate your feedback and recommend monitoring Azure Database for PostgreSQL documentation for future enhancements and support for additional migration scenarios.

Was this answer helpful?

1 person found this answer helpful.

Answer accepted by question author

Jerald Felix 13,255 Reputation points Volunteer Moderator
2026-06-04T08:18:06.6933333+00:00

Hello Mette Bryde Frisk,

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

This is indeed a known limitation of the Azure PostgreSQL Migration Service. The root cause is that the azure and pgaadauth extensions are Azure-managed system extensions that get automatically installed on every Azure PostgreSQL Flexible Server. The Migration Service's validation engine flags these as "unsupported" and blocks the migration but since these extensions are owned by Azure itself, the azure_pg_admin role is not permitted to drop them. So you're stuck in a situation where you can neither remove the extensions to pass validation nor proceed with the migration as-is. This is not a misconfiguration on your end it is a current bug/gap in the Migration Service when doing Flexible Server to Flexible Server migrations.

Here are your best options to work around this:

Use pg_dump and pg_restore instead of the Migration Service. Since both your source and target are PostgreSQL 14 Flexible Servers, a dump/restore approach works cleanly and bypasses the extension validation check entirely. Run:

pg_dump -h <source-host> -U <admin-user> -Fc -d <database-name> -f backup.dump
pg_restore -h <target-host> -U <admin-user> -d <database-name> backup.dump

If you prefer to stay within Azure tooling, consider using Azure Database for PostgreSQL's built-in geo-restore or point-in-time restore to restore a copy of your source server, then update the networking configuration on the restored copy — this avoids a migration altogether.

If your schema and data volume is manageable, you can also use pgAdmin's backup/restore wizard for a GUI-based approach to accomplish the same as pg_dump/pg_restore.

For the Migration Service path specifically — raise a support ticket with Azure referencing Error 603405 and explain that the blocking extensions (azure, pgaadauth) are Azure-managed and cannot be dropped. This helps Microsoft track and prioritize a fix so the validation logic skips these system-level extensions in Flexible Server to Flexible Server scenarios.

While waiting for a fix, make sure to allowlist any other PostgreSQL extensions your databases use on the target server before doing the dump/restore, via the Azure Portal under Server Parameters → azure.extensions.

The pg_dump/pg_restore approach is the most reliable path for your scenario right now and gives you full control over the migration without the service's extension validation getting in the way.

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

Best Regards,

Jerald Felix.

Was this answer helpful?

1 person found this answer helpful.

1 additional answer

Sort by: Most helpful
Most helpful Newest Oldest

  1. AI answer

    2026-06-04T08:01:20.7866667+00:00

    Error 603405 indicates that the migration service doesn’t support migrating databases when certain extensions are present on the source, even if those extensions also exist on the target.

    From the documented behavior of the migration service:

    • Only extensions that are supported by Azure Database for PostgreSQL flexible server can be migrated.
    • Some PostgreSQL objects and features (including certain extensions and superuser‑level objects) are explicitly not supported by the migration service and will block validation or migration.
    • Error 603405 is specifically raised for “Unsupported Extensions. The migration service doesn't support the migration of databases with {0} extensions on the target server.”

    In this case, azure and pgaadauth are Azure‑managed extensions that can’t be dropped by the azure_pg_admin role, so they can’t be removed to satisfy the validation rule. The error code and the general limitations documentation together indicate this is a current limitation of the migration service rather than a misconfiguration.

    Because the migration service does not support migrating databases that contain unsupported extensions, and these particular extensions cannot be dropped on the source, there is no supported in‑product workaround documented for using the migration service to move such a database from one flexible server to another. A different migration approach (for example, dump/restore or other tooling that does not enforce this extension check) would be required.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.