As the support for Azure API Management (APIM) STv1 platform ends on August 31, 2024, it’s crucial for customers to migrate their instances to the STv2 platform. This blog will focus on the new migration options introduced to facilitate this process, as outlined in the attached document.

Why Migrate to STv2?

With the end of support for STv1, instances on this platform will no longer have a Service Level Agreement (SLA). Migrating to STv2 ensures continued support and access to the latest features and improvements in Azure APIM.

New Migration Options

Over the past year, several limitations in the migration process have been addressed to make it easier for instances injected into a virtual network. Here are the key improvements:

Portal Experience: Enhanced user interface for a smoother migration process.
Public IP Optional: The service can now provision a managed IP, making the public IP optional.
Retain Old Gateway: Ability to keep the old gateway for a longer duration for validation purposes.
Release Old Subnet: Option to release the old subnet sooner for customers who need to revert.

Networking Dependencies

One of the biggest challenges in the migration process has been networking dependencies, particularly the need for new subnets and IP changes. The latest migration option addresses this by allowing the retention of original IPs, both public and private.

Key Considerations for the New Migration Option

Subnet Capacity: The subnet must have enough capacity to accommodate the STv2 instance. This means the subnet should be at least half empty to allow the creation of a new STv2 gateway alongside the STv1 gateway.
Coexistence of Instances: If the subnet contains other APIM instances, they should be migrated as soon as possible to avoid conflicts during scaling or update operations.
Subnet Delegation: The subnet cannot have any deployed or delegated resources. Ensure that any delegations are removed ahead of the migration.
Disable Scaling Rules: To prevent issues during the migration, disable all scaling rules. The default coexistence period is 15 minutes for external VNet injected instances and 4 hours for internal VNet injected instances. If multiple STv1 instances exist in the same subnet, disable scaling rules across all instances until migration is complete.
Networking Settings: STv2 requires additional networking settings compared to STv1. Ensure that traffic to Azure is allowed in the existing Network Security Group (NSG), Network Virtual Appliances (NVAs), and other networking controls. This includes:

Adding an outbound rule to Azure KeyVault in the NSG.
Adding a service endpoint to Azure KeyVault on the subnet if force tunneling through an NVA.
Allowing traffic to Azure KeyVault from the subnet address space at the NVA.

Migration Options Within the Same Subnet

Preserve Original IP Addresses: This option retains the original public and private IPs, but involves downtime while the IPs are transferred from the old gateway to the new gateway.
New IP Addresses: This option uses new public IPs, which are pre-created to allow for network dependency adjustments and communication with partners. It also allows specifying the retention time of the old gateway for internal VNet injected instances, providing extended time for validation and updating network dependencies.

Migration Process

The migration process involves creating a new STv2 gateway alongside the existing STv1 gateway in the same subnet. Here are the detailed steps:

Create New Gateway: The migration process creates a new STv2 gateway in the same subnet as the old gateway. The old gateway continues to handle traffic using custom DNS settings.
Preserve IP Option:

The IPs are transferred from the old gateway to the new gateway, resulting in a brief downtime as the IPs will not respond to traffic.
The old gateway is deleted after the migration is successful.

New IP Option:

Pre-created public IPs are assigned to the new gateway.
The old gateway is retained for 15 minutes for external VNet injected instances and 4 hours for internal VNet injected instances.
Validation activities and DNS updates can be performed during the retention period to achieve a no-downtime migration.
The old gateway is deleted after the retention period elapses.

Additional Considerations

Infrastructure Configuration Lock: The infrastructure configuration will be locked for the entire duration of the migration.
Downtime: The preserve IP option will have a downtime during the IP transfer. The new IP option avoids this downtime by using pre-created public IPs.
Networking: NSG with the rules for stv2 is required to be attached to the subnet. Existing subnets need to have the additional outbound rule for Azure Key Vault
Multi Regions: There is no option to selectively upgrade the locations. A single operation will orchestrate upgrading all the regions one at a time.

Verification and Monitoring

Verify Networking: The new UI includes a Verify button to check if the network meets the requirements. This static check looks for NSGs, service endpoints, and DNS configurations but does not check blocks at the NVA level, which need to be verified manually.
Diagnose and Solve Problems: Additional detectors are available to monitor the status of the migration.

Conclusion

Migrating from STv1 to STv2 is essential to ensure continued support and access to the latest features in Azure APIM. The new migration options significantly simplify the process by addressing key challenges, particularly networking dependencies. By following the considerations and steps outlined above, customers can achieve a smooth and successful migration.

Refer the learn documentation for the complete list of migration options including the same subnet migration using Azure CLI.

!!! Note: The portal experience is not completely available and should be released soon.

Feel free to reach out with any questions or for further assistance with your migration process!

I hope this blog helps you understand the new migration options and considerations for moving from Azure APIM STv1 to STv2. If you have any specific questions or need further details, let me know!

​Microsoft Tech Community – Latest Blogs –Read More