Merge pull request #294982 from dlepow/forcemig

[APIM] Force migration with blocked access

Author: JamesJBarnett

articles/api-management/breaking-changes/stv1-platform-retirement-august-2024.md

@@ -5,7 +5,7 @@ services: api-management
 author: dlepow
 ms.service: azure-api-management
 ms.topic: reference
-ms.date: 08/28/2024
+ms.date: 02/19/2025
 ms.author: danlep
 ---
 
@@ -54,9 +54,8 @@ As of 1 September 2024, API Management will no longer provide any service level
 
 Through continued use of an instance hosted on the `stv1` platform beyond the retirement date, you acknowledge that Azure does not commit to the SLA of 99.95% for the retired instances.
 
-### Automatic migration
+[!INCLUDE [api-management-automatic-migration](../../../includes/api-management-automatic-migration.md)]
 
-Starting 1 September 2024, we'll automatically migrate remaining `stv1` service instances to the `stv2` compute platform. All affected customers will be notified of the upcoming automatic migration a week in advance. Automatic migration might cause downtime for your upstream API consumers. You may still migrate your own instances before automatic migration takes place.
 
 [!INCLUDE [api-management-migration-support](../../../includes/api-management-migration-support.md)]
 

articles/api-management/breaking-changes/stv1-platform-retirement-sovereign-clouds-february-2025.md

@@ -52,6 +52,7 @@ As of 1 September 2024, API Management will no longer provide any service level
 
 Through continued use of an instance hosted on the `stv1` platform beyond 1 September 2024, you acknowledge that Azure does not commit to the SLA of 99.95%.
 
+[!INCLUDE [api-management-automatic-migration](../../../includes/api-management-automatic-migration.md)]
 
 [!INCLUDE [api-management-migration-support](../../../includes/api-management-migration-support.md)]
 

articles/api-management/migrate-stv1-to-stv2-vnet.md

@@ -6,7 +6,7 @@ author: dlepow
 ms.service: azure-api-management
 ms.custom:
 ms.topic: how-to
-ms.date: 11/04/2024
+ms.date: 02/19/2025
 ms.author: danlep
 ---
 
@@ -241,6 +241,9 @@ Under certain conditions, [Option 1: Migrate and keep same subnet](#option-1-mig
 
 * **Azure Key Vault blocked** - If access to Azure Key Vault is currently blocked, you must migrate using Option 2, including setting up NSG rules in the new subnet for access to Azure Key Vault.
 
+[!INCLUDE [api-management-automatic-migration](../../includes/api-management-automatic-migration.md)]
+
+
 [!INCLUDE [api-management-migration-support](../../includes/api-management-migration-support.md)]
 
 ## Frequently asked questions

includes/api-management-automatic-migration.md

@@ -0,0 +1,32 @@
+---
+author: dlepow
+ms.service: azure-api-management
+ms.topic: include
+ms.date: 02/21/2025
+ms.author: danlep
+---
+
+## Automatic migration
+
+After the retirement date, we'll automatically migrate remaining `stv1` service instances to the `stv2` compute platform. All affected customers will be notified of the upcoming automatic migration a week in advance. Automatic migration might cause downtime for your upstream API consumers. You may still migrate your own instances before automatic migration takes place.
+
+### Virtual network configuration may be removed during automatic migration
+
+Im most cases, automatic migration retains the virtual network settings of your API Management instance, if they're configured. Under certain [special conditions](../articles/api-management/migrate-stv1-to-stv2-vnet.md#special-conditions-and-scenarios), the virtual network configuration of your `stv1` service instance is removed during automatic migration and, as a security measure, access to your service endpoints is blocked. If the network settings were removed during the migration process, you'll see a message in the portal similar to: `We have blocked access to all endpoints for your service`.
+
+:::image type="content" source="media/api-management-automatic-migration/blocked-access.png" alt-text="Screenshot of blocked access to API Management in the portal.":::
+
+While access is blocked, access to the API gateway, developer portal, direct management API, and Git repository is disabled. To restore access to your service endpoints:
+
+1. Redeploy your API Management instance in your virtual network. For steps, see the guidance for deploying API Management in an [external](../articles/api-management/api-management-using-with-vnet.md) or [internal](../articles/api-management/api-management-using-with-internal-vnet.md) virtual network. We strongly recommend deploying the instance in a **new subnet** of the virtual network with settings compatible with the API Management `stv2` compute platform. 
+1. After the virtual network is reestablished, unblock access to your service endpoints. In the portal, on the **Overview** page of the instance, select **Unblock my service**. This action is not reversible.
+
+> [!WARNING]
+> If you unblock access to your service endpoints before reconfiguring the virtual network, your service endpoints will be publicly accessible from the internet. To protect your environment, make sure to reestablish your virtual network as soon as possible.
+
+> [!TIP]
+> If you need a reminder of the names of the virtual network and subnet where your API Management instance was originally deployed, you can find information in the portal. In the left menu of your instance, select **Diagnose and solve problems** > **Availability and performance** > **VNet Verifier**. In **Time range**, select a period before the instance was migrated.
+
+
+
+