Basic SKU Public IP addresses Retirement

On 30 September 2025, Basic SKU public IP addresses will be retired in Azure. You can continue to use your existing Basic SKU public IP addresses until then, however, you’ll no longer be able to create new ones after 31 March 2025.

You can see the official announcement here.

Required Action

To avoid any potential service disruptions, review pricing and then upgrade to Standard SKU public IP addresses by 30 September 2025.

Microsoft have provided guidance on migration paths for some of the resources using basic public IPs.

Upgrading a basic public IP address to standard SKU IP.

Common Migration Scenarios

Migration Resource	Decision Path
Virtual Machine	Use scripts or manually detach and upgrade public IPs. For standalone virtual machines, you can use the upgrade script or for virtual machines in an availability set use this script.
Virtual Machine Scale Sets	Replace basic SKU instance public IP addresses with new standard SKU.
Load Balancer (Basic SKU)	New Load Balancer SKU required. Use the upgrade script Upgrade Basic Load Balancer to Standard SKU to upgrade to Standard Load Balancer.
VPN Gateway (using Basic IPs)	A migration path will be provided in the future. When this migration path is available, we’ll update this decision path with migration information and send out a service health alert. For more information, see Migrating a basic SKU FAQ.
ExpressRoute Gateway (using Basic IPs)	New ExpressRoute Gateway is required. Follow the ExpressRoute Gateway migration guidance for upgrading from Basic to Standard SKU.
Application Gateway (v1 SKU)	New AppGW SKU required. Use this migration script to migrate from v1 to v2.

Standard SKU public IP’s offer significant improvements, including:

• Access to a variety of other Azure products, including: Standard Load Balancer, Azure Firewall, and NAT Gateway.
• Security by default. Closed to inbound flows unless allowed by a network security group.
• Zone-redundant and zonal front ends for inbound and outbound traffic.

More on standard SKU improvements here.

Virtual Machines

For Basic Public IPs assigned to VMs, there are a few scenarios to consider:

• VMs with an NSG
• VMs without an NSG
• VMs behind a load balancer
• VMs in a Scale Set

VMs with an NSG

As part of the upgrade, the Public IP Address allocation method is set to static before being disassociated from the VM. Once disassociated, the Public IP SKU is upgraded to Standard, then the IP is re-associated with the VM.

Because the Public IP allocation is set to ‘Static’ before detaching from the VM, the IP address won’t change during the upgrade process. However, as the IP needs to be disassociated from the VM, connectivity will be interrupted.

For a single VM with one IP it should only take around 1-2mins for the upgrade to complete.

For a VM with multiple NICs, work on the basis of around a minute for each NIC, and a few seconds to that per IP.

Microsoft have provided a script for this scenario, that does all the work for you. You can install it using the following PowerShell command:

Install-Module -Name AzureVMPublicIPUpgrade -Scope CurrentUser -Repository PSGallery -Force

Module Requirements:

• Run the script as Admin, as it saves output to the root of C:, this output is used in case of recovery.
• VMName [string] Required - This parameter is the name of your VM.
• ResourceGroupName [string] Required - This parameter is the resource group for your VM with the Basic Public IPs attached that you want to upgrade.

Examples:

Single VM:

Start-VMPublicIPUpgrade -VMName 'myVM' -ResourceGroupName 'myRG'

To upgrade all VMs in a resource group, skipping VMs that do not have Network Security Groups:

Get-AzVM -ResourceGroupName 'myRG' | Start-VMPublicIPUpgrade -skipVMMissingNSG

Example of single VM migration, which only took around 1m30secs:

The following query returns a list of virtual machine IDs with Basic SKU public IP addresses attached. It uses PowerShell to run a Resource Graph query to return the results for you. You can then use the results to upgrade each VM using the scripts above.

Search-AzGraph -Query "resources | where type =~ 'microsoft.compute/virtualmachines' | project vmId = tolower(id), vmNics = properties.networkProfile.networkInterfaces | join (resources | where type =~ 'microsoft.network/networkinterfaces' | project nicVMId = tolower(tostring(properties.virtualMachine.id)), allVMNicID = tolower(id), nicIPConfigs = properties.ipConfigurations) on `$left.vmId == `$right.nicVMId | join ( resources | where type =~ 'microsoft.network/publicipaddresses' and isnotnull(properties.ipConfiguration.id) | where sku.name == 'Basic' | project pipId = id, pipSku = sku.name, pipAssociatedNicId = tolower(tostring(split(properties.ipConfiguration.id, '/ipConfigurations/')[0]))) on `$left.allVMNicID == `$right.pipAssociatedNicId | project vmId, pipId, pipSku"

Example output from ARG query in PowerShell:

VMs without NSGs

VMs with Basic Public IPs and with no NSGs will need to have an NSG deployed. Upgrading Basic IP to Standard will stop any traffic to the VM as Standard Public IPs are secure by default.

Steps required:

• Deploy an NSG and associate it to either the Subnet or NIC, as required (Subnet is the preferred, NIC if you need granular control).
• Add required Inbound rules to the NSG.
• Upgrade Basic IP to Standard, manually or using the script in the previous scenerio.

VMs behind a load balancer

There are a few scenarios to consider, some supported with the automated script, others not. Review them according to your situation.

The PowerShell module performs the following functions:

• Verifies that the provided Basic Load Balancer scenario is supported for upgrade.
• Backs up the Basic Load Balancer and Virtual Machine Scale Set configuration, enabling retry on failure or if errors are encountered.
• For public load balancers, updates the front end public IP addresses to Standard SKU and static assignment
• Upgrades the Basic Load Balancer configuration to a new Standard Load Balancer, ensuring configuration and feature parity.
• Migrates Virtual Machine Scale Set and Virtual Machine backend pool members from the Basic Load Balancer to the Standard Load Balancer.
• Creates and associates a network security group with the Virtual Machine Scale Set or Virtual Machine to ensure load balanced traffic reaches backend pool members. This follows Standard Load Balancer’s move to a default-deny network policy.
• Upgrades instance-level Public IP addresses associated with Virtual Machine Scale Set or Virtual Machine instances
• Upgrades Inbound NAT Pools to Inbound NAT Rules for Virtual Machine Scale Set backends, creating a new backend pool for each migrated NAT Pool. Specify -skipUpgradeNATPoolsToNATRules to skip this upgrade and use the standalone NAT Pool migration module later for more backend pool options.
• Logs the upgrade operation for easy audit and failure recovery.

Unsupported Scenarios

• Basic Load Balancers with IPv6 frontend IP configurations
• Basic Load Balancers for Azure Kubernetes Services (AKS) clusters
• Basic Load Balancers with a Virtual Machine Scale Set backend pool member where one or more Virtual Machine Scale - Set instances have ProtectFromScaleSetActions Instance Protection policies enabled
• Migrating a Basic Load Balancer to an existing Standard Load Balancer
• If your Basic Load Balancer has floating IP enabled on a secondary IP configuration of the network interface, update the floating IP to a primary IP before running the migration script to avoid any configuration issues

Installing the Migration Module

Install-Module -Name AzureBasicLoadBalancerUpgrade -Scope CurrentUser -Repository PSGallery -Force

Pre-Migration Steps

• Validate support for your scenario
• Plan for a few minutes of application downtime during migration
• Develop inbound and outbound connectivity tests for your traffic
• Plan for instance-level Public IP changes on Virtual Machine Scale Set instances (see note)
• [Recommended] Create Network Security Groups or add security rules to an existing Network Security Group for your backend pool members. Allow the traffic through the Load Balancer along with any other traffic to be explicitly allowed on public Standard SKU resources.
• [Recommended] Prepare your outbound connectivity, taking one of the following approaches described in How should I configure outbound traffic for my Load Balancer?

Validate your scenario

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName> -validateScenarioOnly:$true

Running the validation creates a log file with all the validation checks, and it looks something like this:

2025-03-21T11:03:05+00 [Information] - [Test-SupportedMigrationScenario] Determining if LB is internal or external based on FrontEndIPConfiguration[0]'s IP configuration
2025-03-21T11:03:05+00 [Information] - [Test-SupportedMigrationScenario] FrontEndIPConfiguiration[0] is assigned a public IP address '%resourceId%', so this LB is External
2025-03-21T11:03:05+00 [Information] - [Test-SupportedMigrationScenario] Determining if there is a frontend IPV6 configuration
2025-03-21T11:03:05+00 [Information] - [Test-SupportedMigrationScenario] Load balancer does not have a frontend IPV6 configuration
2025-03-21T11:03:07+00 [Information] - [Test-SupportedMigrationScenario] Checking if backend pools contain members which are members of another load balancer's backend pools...
2025-03-21T11:03:07+00 [Information] - [Test-SupportedMigrationScenario] All VM load balancer associations are with the Basic LB(s) to be migrated.
2025-03-21T11:03:07+00 [Information] - [Test-SupportedMigrationScenario] Checking if backend VMs have public IPs...
2025-03-21T11:03:10+00 [Warning] - [Test-SupportedMigrationScenario] Load Balance VMs have instance-level Public IP addresses, all of which must be upgraded to Standard SKU along with the Load Balancer.
2025-03-21T11:03:10+00 [Warning] - [Test-SupportedMigrationScenario] -Force or -ValidateOnly parameter was used, so continuing with migration validation
2025-03-21T11:03:10+00 [Information] - [Test-SupportedMigrationScenario] Detected migration scenario: {"BackendType":"VM","VMSSInstancesHavePublicIPs":false,"ExternalOrInternal":"External","SkipOutboundRuleCreationMultiBE":false,"VMsHavePublicIPs":true}
2025-03-21T11:03:10+00 [Information] - [Test-SupportedMigrationScenario] Load Balancer 'elb-basic' is valid for migration

If validation is successful, as stated in the validation log (See the last line above) then you can upgrade using the following:

Start-AzBasicLoadBalancerUpgrade -ResourceGroupName <loadBalancerRGName> -BasicLoadBalancerName <basicLBName>

This process will update the Basic IP on the ELB as well as the Basic IP on the VM if it has one.

VMs in a Scale Set

If you have basic IPs in your VMSS, follow the guidance from Microsoft here.