Questions regarding migrating PostgreSQL databases from Tenant A to Tenant B

Question

Questions regarding migrating PostgreSQL databases from Tenant A to Tenant B

Pim Beliën 20

Hi,

I have to migrate all databases that are currently hosted on 1 Azure Database for PostgreSQL flexible server on one Tenant, to multiple different servers on another tenant. As suggested i would prefer to use the Database Migration service, but I am having a few doubts on the requirements and limitations.

I want to doublecheck if I can I indeed just slowly migrate database by database to a target new server. For example From the Source (lets call it server X) on Tenant A, i choose DB 1 and 2 and migrate those to the Target server Y server on Tenant B. After that I choose DB 3 and 4 and migrate those to Target server Z. Is the migration service indeed capable of this?
None of the scenarios described in https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/overview-migration-service-postgresql match with what I have. I have a Azure Database for PostgreSQL flexible server to Azure Database for PostgreSQL flexible server. Does that change anything? Would I need a migration runtime server in between still?
The source and the target PostgreSQL servers will all be in different VNETs and VNET peering will NOT be possible and both the source and target will have Private Endpoints. How do i establish a networking connection between source ant target in this case. It does not become clear from https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/how-to-network-setup-migration-service#postgresql-source-private-ip-to-flexible-server-private-endpoint nor from https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/concepts-migration-service-runtime-server?tabs=azure-portal what the solution is. Can I make the migration runtime server work with Private Links towards source and Target? If not is there any other way?
Does it matter if the data is encrypted with a CMK? Most likely I need to create a new CMK at source side for each new target server. Will that have any impact on the migration using the Migration service?

VRISHABHANATH PATIL 2,230 Reputation points Microsoft External Staff Moderator

2025-10-13T15:51:29.3633333+00:00

Hi Pim Beliën,

Thank you for reaching out to Microsoft Q&A. We have reviewed your question and here are the steps to mitigate the issue

Can you migrate databases one by one to different servers? Yes, you can. Azure Database Migration Service (DMS) allows you to migrate databases individually. For example: • Move DB1 and DB2 from source server X to target server Y. • Later, migrate DB3 and DB4 to target server Z. Each migration is a separate project, so this approach works fine as long as networking and authentication are set up correctly.

https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/overview-migration-service-postgresql

Does Flexible Server to Flexible Server change anything? Not really. DMS supports Flexible Server as both source and target. However: • You still need a Migration Runtime (either self-hosted or on an Azure VM). DMS doesn’t directly connect source and target without it. • The runtime acts as the bridge for data transfer.

https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/concepts-migration-service-runtime-server?tabs=azure-portal

Networking with Private Endpoints and No VNET Peering This is the tricky part: • The Migration Runtime must be able to reach both source and target servers. • Since VNET peering isn’t possible, you can use Private Link: o Deploy the runtime in a VNET that has Private Endpoints to both source and target. o Configure Azure Private DNS Zones for name resolution. • If that’s not possible, consider VPN Gateway or ExpressRoute to bridge the networks.

https://learn.microsoft.com/en-us/azure/postgresql/migrate/migration-service/how-to-network-setup-migration-service#postgresql-source-private-ip-to-flexible-server-private-endpoint Can the Migration Runtime work with Private Links? Yes. As long as: • The runtime is in a VNET that can access both endpoints. • DNS resolution for private endpoints is configured correctly. Does CMK encryption matter? No, CMK doesn’t affect migration. DMS works at the logical level (pg_dump/pg_restore or logical replication), so encryption is transparent. You’ll need to manage CMKs separately for each target server, but that won’t block migration.

https://learn.microsoft.com/en-us/azure/postgresql/concepts-data-encryption-postgresql

Important notes: • Use DMS with a Migration Runtime in a VNET that can reach both source and target via Private Endpoints. • Configure Private DNS Zones for proper name resolution. • Plan separate migration projects for each batch of databases. • CMK encryption doesn’t impact migration but set up keys on target servers as needed.

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

Thanks, Vrishabh
VRISHABHANATH PATIL 2,230 Reputation points Microsoft External Staff Moderator

2025-10-15T03:06:34.74+00:00

Hi @Pim Beliën

We haven't heard back from you. Please reply if you have any questions in this matter and we will gladly continue the discussion.

Thank, Vrishabh
Pim Beliën 20 Reputation points

2025-10-16T11:57:39.37+00:00

Thnx,

I would like a little more clarity on the tricky networking part ;)

My Target DB and the Migration Runtime can be in the same tenant (lets call it tenant A) and in the same VNET. This is are already linked to a private DNS zone thanks to peering with hub VNET. The Source is however completely on the other tenant.

Are you saying that I should be able to create a private endpoint for the Source as well in the Migration Runtime VNET (so inside tenant A)? Im a littly fuzzy on how that would then be able to connect to the Database on Tenant B.
VRISHABHANATH PATIL 2,230 Reputation points Microsoft External Staff Moderator

2025-10-16T13:04:06.18+00:00
Hi @Pim Beliën,

Thank you for sharing your feedback. Below is a detailed explanation addressing your additional questions.

Can you create a Private Endpoint for the Source in Tenant A?

No, you cannot directly create a Private Endpoint for a resource that lives in another tenant. Private Endpoints are scoped to the same Azure subscription/tenant as the resource they point to. So, you cannot “pull” the source PostgreSQL server into Tenant A’s VNET via a Private Endpoint.

How can the Migration Runtime reach the Source in Tenant B?

You have a few options:

Cross-Tenant Network Connectivity

Since VNET peering is not possible across tenants, you need a network bridge:
- VPN Gateway: Set up a Site-to-Site VPN between Tenant A’s VNET (where the Migration Runtime lives) and Tenant B’s VNET (where the source PostgreSQL server resides). - ExpressRoute: If you have ExpressRoute circuits, you can connect both tenants to the same circuit. 1. Migration Runtime in Tenant B - Deploy the Migration Runtime in Tenant B’s VNET so it can reach the source via Private Endpoint. - Then allow outbound connectivity from that runtime to the target in Tenant A (via VPN or public IP if allowed).

Why Private Endpoint alone won’t solve this

Private Endpoints only work within the same tenant and subscription. They cannot span tenants. So, the runtime in Tenant A cannot directly create a Private Endpoint for a database in Tenant B.

Recommended Architecture

Option 1 (Simpler): Place Migration Runtime in Tenant B (source side). Connect to target in Tenant A using:

Public endpoint (if allowed) with firewall rules.

Or VPN Gateway between tenants.

Option 2: Use VPN Gateway between Tenant A and Tenant B so the runtime in Tenant A can reach the source via its Private Endpoint.

DNS Considerations

If you use Private Endpoints, configure Private DNS Zones in each tenant for name resolution.

If using VPN, ensure DNS resolution works across the tunnel.

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

Thanks,
Vrishabh
Pim Beliën 20 Reputation points

2025-10-17T07:41:27.5733333+00:00

Thnx again. Thats what I thought indeed. Sadly public endpoint is a no-go, but I had another idea. If setup a loadbalancer in tenant B in front of its PostgreSQL and link that using a private link service with a private endpoint in tenant A. Would that also work?

Answer accepted by question author

0 additional answers

Your answer

VRISHABHANATH PATIL 2,230 Reputation points Microsoft External Staff Moderator

2025-10-15T03:06:34.74+00:00

Hi @Pim Beliën

We haven't heard back from you. Please reply if you have any questions in this matter and we will gladly continue the discussion.

Thank, Vrishabh
Pim Beliën 20 Reputation points

2025-10-16T11:57:39.37+00:00

Thnx,

I would like a little more clarity on the tricky networking part ;)

My Target DB and the Migration Runtime can be in the same tenant (lets call it tenant A) and in the same VNET. This is are already linked to a private DNS zone thanks to peering with hub VNET. The Source is however completely on the other tenant.

Are you saying that I should be able to create a private endpoint for the Source as well in the Migration Runtime VNET (so inside tenant A)? Im a littly fuzzy on how that would then be able to connect to the Database on Tenant B.
Pim Beliën 20 Reputation points

2025-10-17T07:41:27.5733333+00:00

Thnx again. Thats what I thought indeed. Sadly public endpoint is a no-go, but I had another idea. If setup a loadbalancer in tenant B in front of its PostgreSQL and link that using a private link service with a private endpoint in tenant A. Would that also work?

Answer 1

Hi @Pim Beliën,

Thanks for reviewing the earlier given solution and below are the detailed steps which answers your additional question -

Your idea of using Azure Private Link Service with a Load Balancer is creative and technically possible, but there are some important considerations:

How It Works

You expose the PostgreSQL server in Tenant B behind an Internal Load Balancer.
Create a Private Link Service on that Load Balancer.
In Tenant A, create a Private Endpoint that connects to the Private Link Service.
This allows Tenant A’s VNET to reach the Load Balancer in Tenant B over a private connection without VNET peering.

Key Constraints

PostgreSQL Protocol Support
- The Load Balancer must forward TCP traffic correctly to PostgreSQL (port 5432).
  - No Layer 7 inspection—this is pure TCP forwarding.
  1. DNS Resolution
    - You’ll need to configure Private DNS Zones so that the PostgreSQL hostname resolves to the Private Endpoint IP in Tenant A.
    1. Authentication
      - Ensure PostgreSQL accepts connections from the Load Balancer’s IP (or configure firewall rules accordingly).
      1. Operational Complexity
        
        This adds an extra hop (Load Balancer → PostgreSQL), which could slightly impact latency.
        
        You’ll need to manage health probes and ensure the LB doesn’t interfere with PostgreSQL traffic.

Microsoft Guidance

This approach is supported because Private Link Service is designed for cross-tenant connectivity scenarios. It’s often used for exposing services privately across tenants without peering.

Reference:

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

Thanks,
Vrishabh

Pim Beliën 20 Reputation points

2025-10-20T07:47:26.7733333+00:00

Thnx yet again :)
I will try to go ahead with this approach while keeping the constraints in mind

Share via

Questions regarding migrating PostgreSQL databases from Tenant A to Tenant B

0 additional answers

Your answer