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

Hemakumar S 0 Reputation points
2026-09-17T12:30:41.25+00:00

Description

We are planning a migration of an internet-facing application from our on-premises data center to Azure using Azure Custom IP Prefix (BYOIP).

Our objective is to retain the same public IP range throughout the migration while minimizing or eliminating downtime during cutover.

Current State The public IP prefix is currently advertised from our on-premises environment. Traffic is expected to continue flowing to the on-premises environment until the migration cutover window. No advertisement of the public IP prefix is currently being performed from the Azure environment. The on-premises environment is the sole active advertisement point for the public prefix at this time.

Desired State We would like to advertise the same BYOIP prefix from the Azure environment while continuing to have inbound traffic prefer the on-premises advertisement path. Prior to migration, the on-premises environment should remain the preferred route for all inbound traffic. On the day of cutover, we need the ability to shift traffic to Azure in a controlled manner so that Microsoft's advertisement becomes the preferred path. We have full route advertisement control on the on-premises side and would like to understand the supported mechanisms available in Azure and Microsoft's network to facilitate this transition. Ideally, we would like to maintain simultaneous advertisements from both environments during the migration period and control traffic preference with minimal disruption. We are seeking guidance on the recommended approach, supported routing controls, and any limitations associated with advertising the same prefix from both on-premises and Azure during the coexistence and cutover phases.

Azure Cloud Services
Azure Cloud Services

An Azure platform as a service offer that is used to deploy web and cloud applications.

0 comments No comments

2 answers

Sort by: Most helpful
  1. Marcin Policht 108.6K Reputation points MVP Volunteer Moderator
    2026-09-17T14:49:12.3866667+00:00

    Simultaneous public IP prefix advertisement from both on-premises and Azure is generally not recommended because it creates overlapping BGP paths, leading to routing instability, packet loss, and unpredictable inbound traffic behavior.

    Instead, use a planned maintenance window with a sequential cutover.

    1. Bring your prefix into Azure via the Azure Portal using the Validation and Provision phases of the Custom IP Address Prefix documentation. Derive your public IP prefixes and assign them to your Azure load balancers or resources while keeping them unadvertised.
    2. During a scheduled maintenance window, withdraw the BGP route advertisement from your on-premises edge routers.
    3. Execute the Commission command on your Azure custom IP prefix to start Microsoft's global advertisement (ASN 8075).

    Note that commissioning or decommissioning an Azure custom IP prefix takes approximately 3 to 4 hours to fully propagate across Microsoft's Wide Area Network and the global internet. It is not an instant switch. In addition, AFAIK, Azure does not allow customers to inject custom BGP AS-path prepending or specific local preferences for BYOIP prefixes to deterministically steer traffic while dual-homed. Microsoft handles global advertisement automatically once commissioned.

    You can choose a regional-only commissioning state if you want to limit initial advertisement to a single Azure region before going global, but this does not safely solve simultaneous on-prem/cloud dual-advertisement overlap.


    If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

    hth

    Marcin

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-09-17T12:31:10.8533333+00:00

    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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

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