review comments

Author: dlepow

articles/api-management/media/migrate-stv1-to-stv2-no-vnet/platform-migration-portal.png

@@ -1,12 +1,12 @@
 ---
 title: Migrate to stv2 platform - Azure API Management - Non-VNet injected
-description: Migrate your Azure API Management instance in-place from the stv1 compute platform to the stv2 platform. Follow these migration steps if your API Management instance isn't deployed (injected) in an external or internal VNet.
+description: Migrate your Azure API Management instance in-place from the stv1 compute platform to the stv2 platform. Follow these migration steps if your API Management instance is not deployed (injected) in an external or internal VNet.
 
 author: dlepow
 ms.service: api-management
 ms.custom: devx-track-azurecli
 ms.topic: how-to
-ms.date: 03/01/2024
+ms.date: 03/14/2024
 ms.author: danlep
 ---
 
@@ -46,7 +46,7 @@ API Management platform migration from `stv1` to `stv2` involves updating the un
 
 You can choose whether the virtual IP address of API Management will change, or whether the original VIP address is preserved.
 
-* **New virtual IP address (recommended)** - If you choose this mode, API requests remain responsive during migration. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 30 minutes. After migration, you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address. 
+* **New virtual IP address** - If you choose this mode, API requests remain responsive during migration. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 30 minutes. After migration, you'll need to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address. 
 
 * **Preserve IP address** - If you preserve the VIP address, API requests will be unresponsive for approximately 15 minutes while the IP address is migrated to the new infrastructure. Infrastructure configuration (such as custom domains, locations, and CA certificates) will be locked for 45 minutes. No further configuration is required after migration.
 
@@ -155,7 +155,7 @@ After successful migration to a new VIP address, update any network dependencies
 
 - **Can I roll back the migration if required?**
 
-    If there's a failure during the migration process, the instance will automatically roll back to the `stv1` platform. However, if the service migrates successfully and if you encounter any other networking issues, you can only roll forward while the old gateway continues to serve traffic. When migrating a non-VNet-injected instance, the old gateway is purged in 15 minutes.
+    If there's a failure during the migration process, the instance will automatically roll back to the `stv1` platform. However, after the service migrates successfully, you can't roll back to the `stv1` platform. 
 
 - **Is there any change required in custom domains/private DNS zones?**
 

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

@@ -6,7 +6,7 @@ author: dlepow
 ms.service: api-management
 ms.custom: devx-track-azurecli
 ms.topic: how-to
-ms.date: 03/11/2024
+ms.date: 03/14/2024
 ms.author: danlep
 ---
 
@@ -110,6 +110,8 @@ After you update the VNet configuration, the status of your API Management insta
 
 [!INCLUDE [api-management-validate-migration-to-stv2](../../includes/api-management-validate-migration-to-stv2.md)]
 
+[!INCLUDE [api-management-migration-compute-coexist](../../includes/api-management-migration-compute-coexist.md)]
+
 [!INCLUDE [api-management-migration-rollback](../../includes/api-management-migration-rollback.md)]
 
 ## Update network dependencies
@@ -187,7 +189,9 @@ After successful migration, update any network dependencies including DNS, firew
 
 - **Can I roll back the migration if required?**
 
-  If there's a failure during the migration process, the instance will automatically roll back to the `stv1` platform. However, if the service migrates successfully and if you encounter any other networking issues, you can only roll forward while the old gateway continues to serve traffic. By default, the old gateway is purged in 15 minutes that can be extended up to 48 hours by contacting Azure support in advance.
+  If there's a failure during the migration process, the instance will automatically roll back to the `stv1` platform. However, after the service migrates successfully, you can't roll back to the `stv1` platform. 
+
+   After a VNet-injected service migrates successfully, there is a short window if time during which the old gateway continues to serve traffic and you can confirm your network settings. See [Confirm settings before old gateway is purged](#confirm-settings-before-old-gateway-is-purged)
 
 - **Is there any change required in custom domain/private DNS zones?**
 

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

@@ -6,7 +6,7 @@ author: dlepow
 ms.service: api-management
 ms.custom: devx-track-azurecli
 ms.topic: how-to
-ms.date: 03/01/2024
+ms.date: 03/14/2024
 ms.author: danlep
 ---
 

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

@@ -0,0 +1,8 @@
+## Confirm settings before old gateway is purged
+
+After successful migration of a VNet-injected API Management instance, the old and the new compute created during migration coexist for a short period of time, approximately 15 mins, which is a small window of time you can use to validate the deployment and that your applications work as expected. (*This window can be extended to 48 hours by contacting Azure support in advance.*) 
+
+* During this window, the old and new gateways are both online and serving traffic. You are not billed during this time. 
+* Use this window to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address and subnet address space.
+* Additionally, check the updated instance's network status to ensure connectivity of the instance to its dependencies. In the portal, in the left-hand menu, under **Deployment and infrastructure**, select **Network** > **Network status**. If needed, update settings such as UDRs and NSG rules.
+* After the window, the old gateway is decommissioned and the new gateway is the only one serving traffic. 

includes/api-management-migration-compute-coexist.md

@@ -12,4 +12,4 @@ If there's a failure during the migration process, the instance will automatical
 
 For help if migration fails, contact Azure support.
 
-If you need full control of rollback and the length of time when old and new gateways coexist, the recommendation is to deploy a new `stv2` instance [side-by-side with your original API Management instance](../articles/api-management/migrate-stv1-to-stv2.md#alternative-side-by-side-deployment). 
+If you need the capability to roll back manually, the recommendation is to deploy a new `stv2` instance [side-by-side with your original API Management instance](../articles/api-management/migrate-stv1-to-stv2.md#alternative-side-by-side-deployment). 

includes/api-management-migration-rollback.md

@@ -8,12 +8,3 @@ ms.author: danlep
 ## Verify migration
 
 To verify that the migration was successful, when the status changes to **Online**, check the [platform version](../articles/api-management/compute-infrastructure.md#how-do-i-know-which-platform-hosts-my-api-management-instance) of your API Management instance. After successful migration, the value is `stv2` or `stv2.1`. 
-
-## Confirm settings before old gateway is purged
-
-After successful migration, the old and the new compute created during migration coexist for a short period of time, approximately 15 mins, which is a small window of time you can use to validate the deployment and that your applications work as expected. (*For VNet-injected instance only, this window can be extended to 48 hours by contacting Azure support in advance.*) 
-
-* During this window, the old and new gateways are both online and serving traffic. You are not billed during this time. 
-* Use this window to update any network dependencies including DNS, firewall rules, and VNets to use the new VIP address/subnet address space.
-* Additionally, check the updated instance's network status to ensure connectivity of the instance to its dependencies. In the portal, in the left-hand menu, under **Deployment and infrastructure**, select **Network** > **Network status**. If needed, update settings such as UDRs and NSG rules.
-* After the window, the old gateway is decommissioned and the new gateway is the only one serving traffic.