Azure Architecture Blog

Preserve a Legacy IP During Azure Migration with Private Link Service Direct Connect

Link: https://techcommunity.microsoft.com/t5/azure-architecture-blog/preserve-a-legacy-ip-during-azure-migration-with-private-link/ba-p/4540575
Published: 2026-07-27 21:31:30
Fetched: 2026-08-27 21:13:49

詳細を表示

Why this matters

Phased migrations to Azure frequently stall on a single, unglamorous constraint: an application with a hard-coded dependency address. The usual options are to re-address the application or change its configuration, and both add development effort, regression testing, and risk to a migration that is already time-boxed.

This article demonstrates a pattern that removes that constraint from the critical path. Using Azure Private Link Service Direct Connect together with a Private Endpoint, the migrated application continues to reach its dependency on exactly the same private address it has always used, while that dependency remains on premises during the interim phase.

The practical benefits are:

Reduced migration risk. No application re-addressing or code change, so no regression cycle and a significantly smaller blast radius.
Faster migration. Web and application tiers can move now rather than waiting for the backend dependency to be modernised, so phase one is no longer blocked by phase two.
Avoided remediation cost. No development effort to change hard-coded addressing, and none of the associated testing spend.
Business continuity preserved. The application connects to the same address throughout, which removes addressing-related cutover risk mid-migration.
Overlapping address space handled. One of the most common reasons enterprise datacentre exits stall is addressed directly, without VNet peering.

The pattern is deliberately a bridge rather than a destination. It buys time to modernise properly; it does not remove the need to do so.

Customer challenge

The customer was planning a phased migration of a legacy application to Azure. The web and application tiers could move first, but a dependent database service needed to remain on premises during the initial phase. The application used a hard-coded private address for this dependency, and changing the application configuration or addressing would have increased migration risk and required additional development and regression testing.

Customer requirements

The customer needed transitional architecture that would allow the web and application tiers to run in Azure while continuing to reach the on-premises database through its existing application-facing address. The solution is needed to:

Preserve the existing application-facing database address.
Migrate the web and application tiers to Azure without immediate application code or configuration changes.
Keep the database on-premises until a later migration phase.
Provide private, controlled connectivity between the Azure-hosted application tiers and the on-premises database.
Validate the complete traffic path before considering the pattern for production use.

Solution and lab overview

This lab evaluates Azure Private Link Service Direct Connect as a transitional connectivity pattern for a phased migration. The capability can connect a Private Link service directly to a privately routable destination address without requiring the destination to sit behind a traditional load balancer. That makes it relevant to direct IP-based scenarios such as database connections, custom applications, and privately reachable on-premises resources.

In the lab, the migrated web and application virtual machines connect to a Private Endpoint in an extended prod VNet. The endpoint maps to a Private Link Service Direct Connect resource in a hub VNet. The hub then routes the traffic across a site-to-site VPN to the simulated on-premises database server. The detailed IP values used to reproduce the lab are introduced in the architecture and deployment sections rather than in the customer narrative.

Preview notice
Private Link Service Direct Connect is in public preview and available only in selected regions. Review the documented requirements, limitations, and regional availability before enabling it in a subscription or using it in a production design.

Why this pattern works

Legacy applications often depend on fixed private addresses that cannot be changed safely during the first migration wave.
Reusing or overlapping address space complicates conventional routed hybrid connectivity.
Private Link Service Direct Connect can route traffic to a specific privately routable destination address and bypass the traditional load-balancer requirement.
The pattern provides a temporary abstraction that lets the Azure-hosted application tier keep using its expected destination while the actual dependency remains on-premises.

When this pattern fits

Consider this pattern when:

An application has a hard-coded or otherwise fixed dependency address that cannot be changed in the current migration phase.
The application tier is ready to migrate ahead of its backend dependency.
On-premises and Azure address spaces overlap, which rules out straightforward VNet peering.
You need a controlled, reversible transition step rather than a single large cutover.

Look at other options when:

The application can be reconfigured or modernised within the migration window. Where that is possible, resolving the dependency properly is the better outcome.
You need a permanent end-state architecture. This pattern is transitional by design.
Your target region does not yet support Private Link Service Direct Connect, which is in public preview with limited regional availability.

Architecture

Figure 1. Logical architecture and traffic path

Component	Address space / IP	Location	Purpose
Hub VNet	10.230.0.0/21	West US 2	Hosts the VPN Gateway, Azure Bastion, test subnet, and Private Link Service subnet.
On-premises VNet	10.220.0.0/21	North Central US	Simulates the on-premises network with production and development subnets.
On-premises production subnet	10.220.1.0/24	North Central US	Hosts vm-db at 10.220.1.6. IIS on this VM simulates the test service on TCP port 80.
Extended production VNet	10.220.1.0/24	West US 2	Hosts the migrated web and application VMs that retain the original application-facing address space.
Private Link Service subnet	10.230.3.0/24	Hub VNet	Hosts the Private Link Service NAT IP configurations 10.230.3.10 and 10.230.3.11.
Private Endpoint	10.220.1.6	Extended production subnet	Provides the local endpoint used by the migrated application tiers to reach the on-premises dependency.

Traffic flow

Testing note: In this lab, vm-db represents the on-premises database server. To validate the end-to-end network path without deploying a database engine, we install IIS on vm-db and use its web server on TCP port 80 as a lightweight test service. A successful HTTP response confirms that traffic reaches vm-db through the intended private connectivity path; it does not validate database functionality.

The web or application VM in the extended production subnet connects to 10.220.1.6 on TCP port 80. For this test, that port is served by IIS running on vm-db.
Because 10.220.1.6 is assigned to the Private Endpoint in the same subnet, the connection is sent to the Private Endpoint locally.
The Private Endpoint connection maps to the Private Link Service Direct Connect resource in the hub VNet.
The Private Link Service Direct Connect resource uses the destination IP address 10.220.1.6.
The hub VNet routes 10.220.0.0/21 through the VPN Gateway to the simulated on-premises network.
The simulated on-premises vm-db receives the request through IIS, and the HTTP response returns through the same private connectivity path.

Prerequisites and assumptions

An Azure subscription where the Microsoft.Network/AllowPrivateLinkserviceUDR feature flag can be registered.
Azure CLI and Az PowerShell modules available in the execution environment. The commands below assume PowerShell syntax for variables.
Permission to create resource groups, VNets, subnets, NSGs, public IPs, VPN gateways, local network gateways, Private Link Service, Private Endpoint, NICs, and VMs.
A region supported by Private Link Service Direct Connect. This lab uses West US 2 and North Central US.
This lab intentionally uses overlapping application-facing IP space in the extended Azure VNet and the on-premises production subnet. Do not peer the hub VNet and the extended production VNet directly.

Credential hygiene
The original lab used a sample shared key and local administrator password. For publication, replace all secrets with strong unique values or Key Vault-backed automation. This document uses placeholders only.

Deploy the lab

Run the following sequence from an authenticated PowerShell session with Azure CLI available. Review every variable before execution. The lab uses IIS on the simulated database VM only as a lightweight TCP and HTTP target; the objective is to validate the network path rather than database behavior.

# -----------------------------
# Variables
# -----------------------------
$RG="rg-pls-demo"
$LOCATION="westus2"
$VNET="vnet-hub"
$VNET_PREFIX="10.230.0.0/21"
$GW_SUBNET="GatewaySubnet"
$GW_PREFIX="10.230.1.0/24"
$BASTION_SUBNET="AzureBastionSubnet"
$BASTION_PREFIX="10.230.2.0/24"
$PLS_SUBNET="snet-pls"
$PLS_PREFIX="10.230.3.0/24"
$TEST_SUBNET="snet-test"
$TEST_PREFIX="10.230.4.0/24"
$ONPREM_RG="onprem-group"
$ONPREM_LOCATION="northcentralus"
$ONPREM_VNET="vnet-onprem"
$ONPREM_VNET_PREFIX="10.220.0.0/21"
$ONPREM_GW_SUBNET="GatewaySubnet"
$ONPREM_GW_PREFIX="10.220.0.0/24"
$ONPREM_PROD_SUBNET="snet-prod"
$ONPREM_PROD_PREFIX="10.220.1.0/24"
$ONPREM_DEV_SUBNET="snet-dev"
$ONPREM_DEV_PREFIX="10.220.2.0/24"
$ONPREM_DB_IP="10.220.1.6"
$VNET_EXTENDED="Extended-VNET"
$VNET_PREFIX_EXTENDED="10.220.1.0/24"
$EXT_SUBNET="snet-extended-prod"
$EXT_PREFIX="10.220.1.0/24"
$PLS_NAME="pls-directconnect-db"
$PLS_IP1="10.230.3.10"
$PLS_IP2="10.230.3.11"
$DESTINATION_IP=$ONPREM_DB_IP
$PE_NAME="pe-db"
$PE_CONNECTION_NAME="pe-to-pls"
$PLS_JSON="pls-ipconfigs.json"
$PE_JSON="pe-ipconfig.json"
$LNG_ONPREM="lng-onprem"
$LNG_AZURE="lng-azure"
$PIP_ONPREM_VPNGW="pip-onprem-vpngw"
$ONPREM_VPNGW="onprem-vpngw"
$PIP_VPNGW="pip-vpngw"
$VPNGW_HUB="vpngw-hub"
$SHAREDKEY="<replace-with-strong-shared-key>"
$ADMINUSER="adminuser"
$ADMIN_PASSWORD="<replace-with-strong-password>"

# -----------------------------
# Create hub resource group, VNet, NSGs, and subnets
# -----------------------------
az group create --name $RG --location $LOCATION
az network vnet create --resource-group $RG --name $VNET --location $LOCATION --address-prefixes $VNET_PREFIX
az network nsg create -g $RG -n nsg-gateway -l $LOCATION
az network nsg create -g $RG -n nsg-bastion -l $LOCATION
az network nsg create -g $RG -n nsg-pls -l $LOCATION
az network nsg create -g $RG -n nsg-test -l $LOCATION
az network vnet subnet create -g $RG --vnet-name $VNET -n $GW_SUBNET --address-prefixes $GW_PREFIX
az network vnet subnet create -g $RG --vnet-name $VNET -n $BASTION_SUBNET --address-prefixes $BASTION_PREFIX
az network vnet subnet create -g $RG --vnet-name $VNET -n $PLS_SUBNET --address-prefixes $PLS_PREFIX --network-security-group nsg-pls --disable-private-link-service-network-policies true
az network vnet subnet create -g $RG --vnet-name $VNET -n $TEST_SUBNET --address-prefixes $TEST_PREFIX --network-security-group nsg-test

# -----------------------------
# Configure Azure Bastion NSG rules and associate with the Azure bastion Subnet
# -----------------------------
$NSG="nsg-bastion"
$nsg=Get-AzNetworkSecurityGroup -ResourceGroupName $RG -Name $NSG
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowHttpsInbound" -Priority 120 -Direction Inbound -Access Allow -Protocol Tcp -SourceAddressPrefix Internet -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 443))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowGatewayManagerInbound" -Priority 130 -Direction Inbound -Access Allow -Protocol Tcp -SourceAddressPrefix GatewayManager -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 443))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowAzureLoadBalancerInbound" -Priority 140 -Direction Inbound -Access Allow -Protocol Tcp -SourceAddressPrefix AzureLoadBalancer -SourcePortRange * -DestinationAddressPrefix * -DestinationPortRange 443))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowBastionHostCommunication" -Priority 150 -Direction Inbound -Access Allow -Protocol Tcp -SourceAddressPrefix VirtualNetwork -SourcePortRange * -DestinationAddressPrefix VirtualNetwork -DestinationPortRange 8080,5701))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowSshRdpOutbound" -Priority 100 -Direction Outbound -Access Allow -Protocol Tcp -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix VirtualNetwork -DestinationPortRange 22,3389))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowAzureCloudOutbound" -Priority 110 -Direction Outbound -Access Allow -Protocol Tcp -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix AzureCloud -DestinationPortRange 443))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowBastionCommunicationOutbound" -Priority 120 -Direction Outbound -Access Allow -Protocol Tcp -SourceAddressPrefix VirtualNetwork -SourcePortRange * -DestinationAddressPrefix VirtualNetwork -DestinationPortRange 8080,5701))
$nsg.SecurityRules.Add((New-AzNetworkSecurityRuleConfig -Name "AllowHttpOutbound" -Priority 130 -Direction Outbound -Access Allow -Protocol Tcp -SourceAddressPrefix * -SourcePortRange * -DestinationAddressPrefix Internet -DestinationPortRange 80))
Set-AzNetworkSecurityGroup -NetworkSecurityGroup $nsg
az network vnet subnet update -g $RG --vnet-name $VNET -n $BASTION_SUBNET --network-security-group nsg-bastion

# -----------------------------
# Deploy Azure Bastion and hub VPN Gateway
# -----------------------------
az network public-ip create -g $RG -n pip-bastion -l $LOCATION --sku Standard --zone 1 2 3
az network bastion create -g $RG -n bastion-hub --public-ip-address pip-bastion --vnet-name $VNET -l $LOCATION --sku Standard
az network public-ip create -g $RG -n $PIP_VPNGW -l $LOCATION --sku Standard --zone 1 2 3
az network vnet-gateway create -g $RG -n $VPNGW_HUB --public-ip-addresses $PIP_VPNGW --vnet $VNET --gateway-type Vpn --vpn-type RouteBased --sku VpnGw2AZ

# -----------------------------
# Create extended Azure prod VNet and migrated web/app VMs(+ vm-test in hub VNET)
# -----------------------------
az network vnet create --resource-group $RG --name $VNET_EXTENDED --location $LOCATION --address-prefixes $VNET_PREFIX_EXTENDED
az network nsg create -g $RG -n nsg-extended -l $LOCATION
az network vnet subnet create --resource-group $RG --vnet-name $VNET_EXTENDED --name $EXT_SUBNET --address-prefixes $EXT_PREFIX --network-security-group nsg-extended
az network nic create -g $RG -n nic-testvm --vnet-name $VNET --subnet $TEST_SUBNET
az vm create -g $RG -n vm-test --nics nic-testvm --image Win2022Datacenter --admin-username $ADMINUSER --admin-password $ADMIN_PASSWORD
az network nic create -g $RG -n nic-web --vnet-name $VNET_EXTENDED --subnet $EXT_SUBNET --private-ip-address 10.220.1.4
az vm create -g $RG -n vm-web --nics nic-web --image Win2022Datacenter --admin-username $ADMINUSER --admin-password $ADMIN_PASSWORD
az network nic create -g $RG -n nic-app --vnet-name $VNET_EXTENDED --subnet $EXT_SUBNET --private-ip-address 10.220.1.5
az vm create -g $RG -n vm-app --nics nic-app --image Win2022Datacenter --admin-username $ADMINUSER --admin-password $ADMIN_PASSWORD

# -----------------------------
# Create simulated on-premises VNet and VPN Gateway
# -----------------------------
az group create --name $ONPREM_RG --location $ONPREM_LOCATION
az network vnet create --resource-group $ONPREM_RG --name $ONPREM_VNET --location $ONPREM_LOCATION --address-prefixes $ONPREM_VNET_PREFIX
az network vnet subnet create --resource-group $ONPREM_RG --vnet-name $ONPREM_VNET --name $ONPREM_GW_SUBNET --address-prefixes $ONPREM_GW_PREFIX
az network vnet subnet create --resource-group $ONPREM_RG --vnet-name $ONPREM_VNET --name $ONPREM_PROD_SUBNET --address-prefixes $ONPREM_PROD_PREFIX
az network vnet subnet create --resource-group $ONPREM_RG --vnet-name $ONPREM_VNET --name $ONPREM_DEV_SUBNET --address-prefixes $ONPREM_DEV_PREFIX
az network public-ip create --resource-group $ONPREM_RG --name $PIP_ONPREM_VPNGW --location $ONPREM_LOCATION --sku Standard
az network vnet-gateway create --resource-group $ONPREM_RG --name $ONPREM_VPNGW --public-ip-addresses $PIP_ONPREM_VPNGW --vnet $ONPREM_VNET --gateway-type Vpn --vpn-type RouteBased --sku VpnGw2AZ

# -----------------------------
# Create local network gateways and VPN connections
# -----------------------------
$AZURE_VPN_PUBLICIP = az network public-ip show -g $RG -n $PIP_VPNGW --query ipAddress -o tsv
$ONPREM_VPN_PUBLICIP = az network public-ip show -g $ONPREM_RG -n $PIP_ONPREM_VPNGW --query ipAddress -o tsv
Write-Host "Azure VPN IP : $AZURE_VPN_PUBLICIP"
Write-Host "OnPrem VPN IP : $ONPREM_VPN_PUBLICIP"
az network local-gateway create -g $RG -n $LNG_ONPREM --gateway-ip-address $ONPREM_VPN_PUBLICIP --local-address-prefixes 10.220.0.0/21
az network local-gateway create -g $ONPREM_RG -n $LNG_AZURE --gateway-ip-address $AZURE_VPN_PUBLICIP --local-address-prefixes 10.230.0.0/21
az network vpn-connection create -g $RG -n conn-to-onprem --vnet-gateway1 $VPNGW_HUB --local-gateway2 $LNG_ONPREM --shared-key $SHAREDKEY
az network vpn-connection create -g $ONPREM_RG -n conn-to-azure --vnet-gateway1 $ONPREM_VPNGW --local-gateway2 $LNG_AZURE --shared-key $SHAREDKEY
az network vpn-connection show -g $RG -n conn-to-onprem --query "{Name:name,Status:connectionStatus}" -o table
az network vpn-connection show -g $ONPREM_RG -n conn-to-azure --query "{Name:name,Status:connectionStatus}" -o table

# -----------------------------
# Create on-premises DB VM
# -----------------------------
az network nic create -g $ONPREM_RG -n nic-db --vnet-name $ONPREM_VNET --subnet $ONPREM_PROD_SUBNET --private-ip-address $ONPREM_DB_IP
az vm create -g $ONPREM_RG -n vm-db --nics nic-db --image Win2022Datacenter --admin-username $ADMINUSER --admin-password $ADMIN_PASSWORD

# -----------------------------
# Register PLS Direct Connect preview feature
# -----------------------------
az feature register --namespace Microsoft.Network --name AllowPrivateLinkserviceUDR
az feature show --namespace Microsoft.Network --name AllowPrivateLinkserviceUDR --query properties.state -o tsv
az provider register --namespace Microsoft.Network

# -----------------------------
# Create PLS Direct Connect IP configuration JSON
# -----------------------------
$PLS_SUBNET_ID = az network vnet subnet show -g $RG --vnet-name $VNET -n $PLS_SUBNET --query id -o tsv
@"
[
{
    "name": "ipconfig1",
    "primary": true,
    "private-ip-allocation-method": "Static",
    "private-ip-address": "$PLS_IP1",
    "subnet": { "id": "$PLS_SUBNET_ID" }
},
{
    "name": "ipconfig2",
    "primary": false,
    "private-ip-allocation-method": "Static",
    "private-ip-address": "$PLS_IP2",
    "subnet": { "id": "$PLS_SUBNET_ID" }
}
]
"@ | Out-File -FilePath $PLS_JSON -Encoding ascii

az network private-link-service create -g $RG -n $PLS_NAME -l $LOCATION --destination-ip-address $DESTINATION_IP --ip-configurations "@$PLS_JSON"
az network private-link-service show -g $RG -n $PLS_NAME --query "name:name,provisioningState:provisioningState,destinationIpAddress:destinationIPAddress}" -o table

# -----------------------------
# Create Private Endpoint in the extended Azure production subnet
# -----------------------------
az network vnet subnet update -g $RG --vnet-name $VNET_EXTENDED -n $EXT_SUBNET --private-endpoint-network-policies Disabled
$PLS_ID = az network private-link-service show -g $RG -n $PLS_NAME --query id -o tsv
@"
[
{
    "name": "pe-ipconfig1",
    "private-ip-address": "$ONPREM_DB_IP"
}
]
"@ | Out-File -FilePath $PE_JSON -Encoding ascii

az network private-endpoint create -g $RG -n $PE_NAME -l $LOCATION --vnet-name $VNET_EXTENDED --subnet $EXT_SUBNET --private-connection-resource-id $PLS_ID --connection-name $PE_CONNECTION_NAME --ip-configs "@$PE_JSON"
az network private-link-service show -g $RG -n $PLS_NAME --query privateEndpointConnections -o table

# -----------------------------
# Install IIS on the on-premises DB VM and publish a test page
# -----------------------------
az vm run-command invoke -g $ONPREM_RG -n vm-db --command-id RunPowerShellScript --scripts "Install-WindowsFeature Web-Server -IncludeManagementTools"
az vm run-command invoke -g $ONPREM_RG -n vm-db --command-id RunPowerShellScript --scripts "Set-Content -Path 'C:\inetpub\wwwroot\index.html' -Value '<h1>OnPrem DB Server IIS Page</h1>'"
az vm run-command invoke -g $ONPREM_RG -n vm-db --command-id RunPowerShellScript --scripts "Get-WindowsFeature Web-Server; netstat -ano | findstr :80"

Validate the solution

Checkpoint	Command	Expected result
VPN tunnel status	az network vpn-connection show -g $RG -n conn-to-onprem --query connectionStatus -o tsv az network vpn-connection show -g $ONPREM_RG -n conn-to-azure --query connectionStatus -o tsv	Both connections show Connected.
DB web service	az vm run-command invoke -g $ONPREM_RG -n vm-db --command-id RunPowerShellScript --scripts "netstat -ano \| findstr :80"	The DB VM is listening on TCP port 80.
Private Endpoint connection	az network private-link-service show -g $RG -n $PLS_NAME --query "privateEndpointConnections[].{Connection:name,Status:privateLinkServiceConnectionState.status}" -o table az network private-endpoint show -g $RG -n $PE_NAME --query "{Name:name,ProvisioningState:provisioningState}" -o table	The connection status is Approved, and the Private Endpoint provisioning state is Succeeded.
Hard-coded IP test from web and app tiers	az vm run-command invoke -g $RG -n vm-web --command-id RunPowerShellScript --scripts "Test-NetConnection 10.220.1.6 -Port 80" az vm run-command invoke -g $RG -n vm-app --command-id RunPowerShellScript --scripts "Test-NetConnection 10.220.1.6 -Port 80"	TcpTestSucceeded is True.
HTTP test from web and app tiers	az vm run-command invoke -g $RG -n vm-web --command-id RunPowerShellScript --scripts "Invoke-WebRequest http://10.220.1.6 -UseBasicParsing" az vm run-command invoke -g $RG -n vm-app --command-id RunPowerShellScript --scripts "Invoke-WebRequest http://10.220.1.6 -UseBasicParsing"	The response contains the sample IIS page.

Production considerations

Do not peer the extended prod VNet with the Azure hub VNet. The extended VNet uses 10.220.1.0/24, which overlaps with the 10.220.0.0/21 on-premises prefix that the hub routes through the VPN Gateway. The repeated database IP is intentionally exposed to the web and app tiers only through the Private Endpoint abstraction, not through direct VNet peering.
The PLS subnet must have Private Link service network policies disabled. The Private Endpoint subnet must have Private Endpoint network policies disabled for this lab pattern.
Private Link Service Direct Connect requires at least two IP configurations. The lab uses 10.230.3.10 and 10.230.3.11 for high availability alignment.
The destination IP must be privately routable and reachable from the PLS path. In this lab, the hub routes 10.220.0.0/21 to the on-premises side through VPN Gateway.
For production, validate return path, NSG rules, route tables, firewall policies, DNS behavior, logging, and operational ownership before adopting the pattern.

Clean up

When the lab is no longer required, remove the lab resource groups. Validate that no shared resources exist in these groups before deletion.

az group delete --name rg-pls-demo --yes --no-wait
az group delete --name onprem-group --yes --no-wait

Conclusion

This lab shows how a Private Endpoint and Private Link Service Direct Connect can provide a controlled transition path when an application tier moves to Azure before a fixed-address dependency. The pattern can reduce immediate application change, but it should remain an interim architecture: validate routing symmetry, network security, monitoring, regional availability, operational ownership, and a clear plan to remove the legacy address dependency before production adoption.

Used well, this approach reduces migration risk, avoids application remediation cost, and keeps a datacentre exit moving when it would otherwise stall. In a recent engagement it unblocked a phased migration for an enterprise customer whose application carried a hard-coded dependency address, without a single change to application code.

Private Link Service Direct Connect is in public preview and available in selected regions, so confirm regional availability, routing, DNS behaviour, and operational ownership before any production adoption.

If you try the lab, I would welcome your feedback, and any variations you find useful in your own migrations.

References

About the author

Kumar Kaushal is a Senior Digital Cloud Solutions Architect at Microsoft, focused on helping customers design and validate practical Azure architectures for cloud migration, hybrid connectivity, networking, resiliency, and modernization.

2026-07-27

Azure News - 2026-07-27