How to migrate Azure vNET-integrated API-Management stv1 to stv2?

I understand your concerns about migrating your vNET-integrated Azure API Management (API-M) instances from stv1 to stv2 with the limitations of backup & restore and the missing stv2 dev tier. Here's how you can approach this:

Migration Strategy:

Migrate Production (Prod) to stv2 Standard:
Since backup & restore across service tiers isn't supported, a direct migration with rollback isn't feasible. Here's a two-step approach:
Test Migration:
Create a new stv2 Standard instance in the same region as your Prod stv1 instance.
Use the Azure API Management portal or PowerShell to export your Prod stv1 configuration (policies, APIs, products etc.).
Import the exported configuration into the new stv2 Standard instance.
Thoroughly test your migrated APIs in the new stv2 environment to ensure functionality.
Production Cut-over:
Once testing is successful, schedule a maintenance window for minimal disruption.
Update your DNS records or firewall rules to point to the new stv2 Standard instance's VIP address.
De-provision your stv1 Prod instance after confirming everything is functioning smoothly in stv2.
Development (Dev) Environment:
The absence of a stv2 Dev tier creates a cost challenge. Here are two options:
Consolidate Dev and Prod on stv2 Standard:
If your Dev environment has lower traffic compared to Prod, consider migrating Dev to the same stv2 Standard instance used for Prod. You can configure different policies and backends for Dev and Prod APIs within the same instance for better resource utilization.
Delay Dev Migration:
If Dev environment separation is crucial, you can temporarily hold off on Dev migration. Continue using the stv1 Dev instance until Microsoft releases the stv2 Dev tier (there's no official confirmation on its availability yet, but you can keep an eye on Microsoft documentation for updates).