Share via

Request to Retain Outbound IPs During Migration from Windows to Linux App Service Plan

Saeed 0 Reputation points
2025-08-28T13:31:55.7466667+00:00

We have an existing Windows App Service and need to migrate it to a Linux-based App Service Plan, but we must retain the current outbound IPs since they are already whitelisted by a customer.

Details:

Current App Service Name: api-appservice

Current App Service Plan (Windows): current-windows-plan

Current Outbound IPs: Assigned via the above plan and already shared with our customer for whitelisting.

Target App Service Plan (Linux): target-linux-plan

Requirement: We want to migrate the app service to this new Linux plan but retain the same outbound IPs currently assigned to the Windows plan.

Flexibility: It is acceptable if the Windows plan (current-windows-plan) receives a new set of outbound IPs after the migration, as long as the Linux plan inherits the existing ones.

Question: Is it possible to move the outbound IP addresses currently associated with the Windows plan (current-windows-plan) over to the Linux plan (target-linux-plan), so that our customer does not need to update their firewall whitelist?

If this is possible, our plan is to:

Delete the app service from the Windows plan.

Recreate the app service on the Linux plan (target-linux-plan) with the same name (api-appservice).

Business Impact:

The outbound IPs are whitelisted by a critical customer in their firewall.

If these IPs change, our customer will have to update their firewall rules, which could cause delays and downtime in production connectivity.

Retaining the same outbound IPs ensures uninterrupted integration and avoids business impact for both us and our customer

Azure App Service
Azure App Service
Azure App Service is a service used to create and deploy scalable, mission-critical web apps.
0 comments

1 answer

Sort by: Most helpful
Most helpful Newest Oldest
  1. Ofek Ben Eliezer 0 Reputation points
    2025-08-28T13:47:51.8166667+00:00

    No, you cannot “move” the existing outbound IPs from a Windows App Service plan to a Linux plan. Outbound IPs are tied to the App Service deployment unit and change in common operations such as deleting and recreating the app or moving plans. To keep a stable egress IP, use VNet Integration + NAT Gateway or run in an App Service Environment that uses your own egress.

    What to do instead – pin a static egress with NAT Gateway The supported way to keep the same outbound IP through your migration is to front both the old Windows app and the new Linux app with the same NAT Gateway via regional VNet Integration. Your customer whitelists the NAT public IPs – not the multi-tenant plan IPs – and the egress stays constant even when you switch plans or OS.

    Step-by-step

    1. Create or choose a VNet + integration subnet
      • Use regional VNet Integration on a supported App Service plan SKU. Enable Route all so internet-bound traffic goes through the VNet.
    2. Attach a NAT Gateway to that subnet
      • Create a Public IP or Public IP Prefix for the NAT. Associate the NAT Gateway with the integration subnet. These IPs become your app’s outbound egress.
      Pre-stage on the current Windows app Integrate the current app (api-appservice on current-windows-plan) with the VNet, enable Route all, and verify the observed egress IP matches the NAT public IP. 
        Give this NAT IP list to your customer for whitelisting.
    3. Cut over to Linux
      • Create the new Linux app on target-linux-plan. Integrate it with the same VNet integration subnet and enable Route all. The outbound IPs remain the NAT IPs, so no firewall change at the customer.

    Verification tips

    From Kudu or app logs, call an external echo service to confirm the public egress IP equals the NAT IP.

    • Azure shows the NAT IPs under the app’s Networking overview once Route all + NAT are in place.

    Gotchas and sizing

    • When App Service uses a NAT Gateway, traffic to Azure Storage must go via private endpoints or service endpoints. Plan those before cutover.
    • If you have high concurrency to the same destination, consider a Public IP Prefix or multiple NAT IPs. A NAT Gateway can hold up to 16 IPs and gives you significantly more SNAT ports.
    • On Premium V4, outbound IPs are intentionally shown as Dynamic – you must use NAT Gateway if you need stable egress.

    Why deleting and recreating won’t preserve your IPs Deleting the app or moving across plans often lands you on a different deployment unit – that changes the outbound IP set. Re-using the app name does not guarantee the same egress. NAT Gateway is the supported pattern to make egress predictable across such changes.

    0 comments

Your answer

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