Migrating from Azure APIM STv1 to STv2: New Options and Considerations

With support for the Azure API Management (APIM) STv1 platform ending on August 31, 2024, it is important 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 described in the accompanying documentation.

Why should I migrate to STv2?

As support for STv1 ends, instances of this platform 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

Last year, several limitations in the migration process were addressed to make it easier to inject instances into virtual networks. Key improvements include:

1. Portal Experience: An improved user interface is provided for a smoother migration process.
2. Public IP Optional: Now that services can provide managed IPs, public IPs are optional.
3. Maintain previous gateway: Ability to retain existing gateways for a longer period of time for validation purposes.
4. Release the previous subnet: Option to decommission old subnets more quickly for customers who need to revert to their old subnets.

Networking Dependencies

One of the biggest challenges in the migration process was the need for networking dependencies, especially new subnets and IP changes. The latest migration options address this by allowing you to preserve your original IPs, both public and private.

Key Considerations for New Migration Options

1. Subnet capacity: The subnet must have enough capacity to accommodate the STv2 instance. That is, the subnet must be at least half empty to allow for the creation of a new STv2 gateway next to the STv1 gateway.
2. Coexistence of instances: If your subnet contains other APIM instances, you should migrate them as soon as possible to avoid conflicts during scale or update operations.
3. Subnet Delegation: Subnets cannot have any deployed or delegated resources. Make sure all delegations are removed before migration.
4. Disable scaling rules: Disable all scaling rules to avoid issues during migration. The default coexistence period is 15 minutes for external VNet injected instances and 4 hours for internal VNet injected instances. If you have multiple STv1 instances in the same subnet, disable scaling rules on all instances until the migration is complete.
5. Networking Settings: STv2 requires additional networking setup compared to STv1. Ensure that traffic to Azure is allowed by your existing Network Security Groups (NSGs), Network Virtual Appliances (NVAs), and other networking controls. These include:

• Add an outbound rule to Azure KeyVault in NSG.
• If you are performing forced tunneling through an NVA, add a service endpoint to Azure KeyVault in the subnet.
• Allow traffic to Azure KeyVault from the NVA’s subnet address space.

Migration options within the same subnet

1. Preserve original IP address: This option will keep the original public and private IPs, but will cause downtime while the IPs are transferred from the old gateway to the new gateway.
2. New IP address: This option uses a new pre-created public IP to allow for network dependency coordination and communication with partners. It also specifies a retention time for the old gateway for internal VNet injection instances, providing extended time for validation and network dependency updates.

Migration process

The migration process involves creating a new STv2 gateway next to the existing STv1 gateway in the same subnet. The detailed steps are as follows:

1. Create a 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.
2. Maintain IP Options:

• As the IP is transferred from the old gateway to the new gateway, there will be a brief downtime as the IP becomes unresponsive to traffic.
• Once the migration is successfully completed, the old gateway will be deleted.

• A pre-generated public IP is assigned to the new gateway.
• For instances injected into external VNets, the previous gateway is retained for 15 minutes, and for instances injected into internal VNets, it is retained for 4 hours.
• To achieve a zero-downtime migration, validation activities and DNS updates can be performed during the retention period.
• After the retention period expires, the old gateway will be deleted.

Additional Considerations

• Infrastructure Configuration Lock: Infrastructure configuration is locked for the entire duration of the migration.
• downtime: The IP preservation option causes downtime during IP transfer. The new IP option avoids this downtime by using pre-generated public IPs.
• Networking: An NSG with rules for stv2 must be associated with the subnet. The existing subnet must have an additional outbound rule for Azure Key Vault.
• Multi-region: There is no option to upgrade locations selectively. All regions are upgraded one at a time in a single operation.

Verification and monitoring

• Check networking: The new UI includes: check A button to check if your network meets the requirements. This static check looks for NSGs, service endpoints, and DNS configurations, but it does not check blocks at the NVA level, so you will need to check them manually.
• Diagnose and resolve problems: Additional detectors can be used to monitor migration status.

conclusion

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

Please see the Learning Guide for a full list of migration options. Same subnet migration using Azure CLI.

!!! memo: The portal environment is not yet fully available and will be released soon.

If you have any questions or need further assistance with the immigration process, please contact us anytime!

We hope this blog helps you understand the new migration options and considerations for moving from Azure APIM STv1 to STv2. If you have specific questions or need more information, please let us know!