An unexpected error occured while processing the request.

Question

I'm trying to use Migrate PostgreSQL to Azure Database for PostgreSQL flexible server tool but get "An unexpected error occured while processing the request. '" when trying to connect to the Source server.

The server is in a different VNET, but a connection has been opened from the Azure VNET where my PostgreSQL flexible server exists to the Source server I'm trying to access.

This connection has been confirmed by running psql commands from an Azure Container App that resides in the same VNET as my PostgreSQL flexible server.

Answer 1

Hi Alexandru,

Thanks for sharing the details, I understand how frustrating it is to hit this error, especially when connectivity seems to be working from your side.

Based on what you described, the fact that you’re able to connect successfully using psql from an Azure Container Apps instance in the same VNET confirms that basic network connectivity to the source PostgreSQL server is in place. However, the migration tool used for Azure Database for PostgreSQL flexible server operates slightly differently and depends on additional service-level access and configuration.

This “unexpected error” during source connection is commonly seen in scenarios where the Azure migration service cannot reach the source endpoint, even though a test client (like psql) can. This usually happens due to one of the following:

The migration service runs outside your VNET unless explicitly configured, so it may not be able to access private endpoints or VNET-isolated resources. Even if your Flexible Server is in a VNET, the migration tool itself needs network line-of-sight to the source server.

If your source PostgreSQL is behind a private network, firewall, or restricted to specific IP ranges, you’ll need to explicitly allow access from Azure services (or configure a proper integration such as Private Link or a self-hosted integration runtime).

DNS resolution can also play a role, the migration service must be able to resolve the source server hostname correctly from its execution environment.

To address this, I recommend the following approach:

First, confirm whether your source server is publicly accessible or restricted to a private network. If it’s private, the migration service won’t be able to reach it unless you configure a supported network path.

If the source is private, consider using Azure Database Migration Service (DMS) with VNET integration, which allows you to deploy the migration service inside your VNET so it can access private endpoints directly.

Alternatively, temporarily allow access to the source PostgreSQL server from Azure services (for testing purposes) and verify if the migration tool connection succeeds.

Also, ensure that firewall rules, NSGs, and routing configurations allow traffic not just from your container app, but from Azure service infrastructure as well.

You can refer to the official Microsoft documentation for detailed guidance:

Azure Database for PostgreSQL migration overview:

https://learn.microsoft.com/azure/postgresql/migrate/concepts-migration-service-postgresql

Networking requirements for migration:

https://learn.microsoft.com/azure/dms/dms-overview

If after validating the above the issue still persists, it would be helpful to capture the activity ID or correlation ID from the error and involve backend support for deeper investigation, as this may require checking service-side logs.

Answer 2

The tracking ID error indicates a failure inside the migration service, but the context only provides concrete guidance for specific, surfaced error codes and for connectivity/time-out issues. Use the following checks that are supported by the documentation:

1. Validate basic connectivity from migration service perspective The migration service must be able to reach both source and target, not just the flexible server VNET:
   • Error 603000 (“Connection failed. Connection to the server {serverName} was unsuccessful. Ensure that the source server is reachable from the target or runtime server.”) is raised when the migration service cannot reach the source.
   • Even if psql works from an Azure Container App in the same VNET as the flexible server, ensure that the migration runtime (or migration service subnet, if using the built-in runtime) has the same network access (NSGs, firewalls, routes) to the source.
   • If this is a migration-service-based scenario, follow the network debugging guidance referenced by error 603000 to verify routing and firewall rules end‑to‑end.
2. Check for connection time-outs between source and migration service If the underlying problem is a time-out, it can surface as generic failures:
   • Typical time-out symptoms in the migration service include:
     • server closed the connection unexpectedly
     • SSL SYSCALL error: EOF detected
     • unexpected EOF on client connection
     • couldn't receive data from client: Connection reset by peer
   • To mitigate time-outs between source and migration service or between migration service and target, adjust TCP keepalive parameters on both source and target PostgreSQL instances:
     • tcp_keepalives_idle=10
     • tcp_keepalives_interval=10
     • tcp_keepalives_count=60
   • These can be applied without restarting PostgreSQL and help keep long‑running connections alive.
3. Confirm SSL and authentication settings The migration service surfaces specific error codes for SSL and authentication issues:
   • 603001 – SSL configuration error: server does not support SSL; set SSL mode to prefer and retry.
   • 603100 – Authentication failed: incorrect password.
   • 603102 – Source database missing. Ensure that the connection profile used by the migration tool matches the way psql connects (hostname, port, SSL mode, database name, username, password).
4. Check for pre-migration validation errors
   • The migration service has a catalog of premigration error codes. If the UI or logs expose a code (for example, 603000/603001/603100/603101/603102), use the documented resolution for that specific code.
5. If the error persists with only a tracking ID
   • Since the message is “An unexpected error occurred while processing the request” with only a tracking ID, and no mapped error code is shown in the UI, collect:
     • The tracking ID
     • Time of failure
     • Source and target server names
   • Then open an Azure support request so the service team can look up the tracking ID and correlate it with internal logs.

In parallel, verify that the source PostgreSQL server allows connections from the migration service subnet (not just from the flexible server VNET) and that any firewalls or network security groups permit outbound traffic from the migration runtime to the source on the PostgreSQL port.

---

References:

• Known errors in the migration service for Azure Database for PostgreSQL
• Troubleshoot DMS errors when connecting to source databases
• Troubleshoot connection issues to Azure Database for PostgreSQL