Guidance Required for BYOIP Cutover Strategy - Prefer On-Prem Advertisement Before Migration and Azure Advertisement

The supported approach is to keep the prefix in Azure in the Provisioned state until the cutover window, then move it to Commissioned during a maintenance window.

Key behavior:

1. Provisioned state
   • The custom IP prefix exists in Azure.
   • Child public IP prefixes and public IPs can be created and attached to Azure resources.
   • The IPs are not advertised from Azure and aren't reachable yet.
   • This is the supported state for building and validating the Azure-side infrastructure before cutover.
2. Commissioned state
   • Azure begins advertising the range from the local Azure region and then globally through Microsoft WAN under ASN 8075.
   • The rollout is asynchronous and partial while the prefix is in Commissioning.
   • Full commissioning is estimated at 3-4 hours.

For the coexistence requirement, the documented limitation is important:

• Advertising the same range to the Internet from a location other than Microsoft at the same time that Azure is commissioning or commissioned can create BGP routing instability or traffic loss.
• The recommended guidance is to plan migration of an active prefix during a maintenance period.
• For active prefixes currently advertised outside Microsoft, the documented migration guidance says the external advertisement should be disabled once the Azure infrastructure has been verified as operational.

That means the supported model is not to rely on long-term simultaneous Internet advertisement from both on-premises and Azure while trying to make on-premises remain preferred. The documented recommendation is:

1. Provision the BYOIP prefix into Azure.
2. While it is still Provisioned, create child public IP prefixes/public IPs and attach them to the target Azure resources.
3. Validate the Azure infrastructure during this stage, understanding those IPs are not yet reachable from the Internet.
4. During a planned maintenance window, transition the custom IP prefix to Commissioned.
5. Stop the non-Microsoft advertisement of that same range after Azure is verified operational to avoid routing instability or traffic loss.

Two supported migration patterns are documented for active prefixes:

• Method 1: Create Azure public IP prefixes/public IPs from the custom IP prefix while it is Provisioned, attach them to resources, then commission the prefix during cutover.
• Method 2: Build and validate infrastructure first using Microsoft-owned ranges, then switch to the provisioned BYOIP-derived addresses before or after commissioning, depending on resource type.

If tighter control is needed before global Internet advertisement, Azure also documents a regional commissioning feature for unified model custom IP prefixes, where the prefix is advertised only within the Azure region it is deployed in. This is called out as a way to help prevent issues during initial deployment.

Practical cutover guidance based on the documented behavior:

1. Before cutover
   • Keep on-premises as the only Internet advertisement point.
   • Provision the custom IP prefix in Azure.
   • Create and attach child public IP prefixes/public IPs to Azure resources.
   • Validate the Azure deployment.
2. Cutover window
   • Use a maintenance window.
   • Commission the Azure custom IP prefix.
   • Expect asynchronous rollout and partial advertisement during Commissioning.
   • Remove or disable the on-premises Internet advertisement of the same prefix to avoid BGP instability or traffic loss.
3. After cutover
   • Confirm the prefix reaches Commissioned.
   • Keep Microsoft as the active Internet advertisement source for that range.

The context does not document any Azure or Microsoft-supported mechanism to keep both advertisements active and make inbound traffic continue to prefer on-premises until a later controlled preference flip. The supported guidance in the documentation is to avoid concurrent Internet advertisement of the same prefix from outside Microsoft and to perform the transition in a maintenance window.

References:

• Create a custom IPv4 address prefix in Azure
• Manage a custom IP address prefix
• Custom IP address prefix (BYOIP)