Forum Discussion
How to migrate Azure vNET-integrated API-Management stv1 to stv2?
We currently have a prod and dev stv1 API-Management, both still running in the developer tariff.
My goal is to migrate the prod to stv2-standard and the dev to stv2 dev-tariff.
However I have the following challanges:
- Backup & Restore from stv1 dev to stv2 standard does not work
- there is currently no stv2 dev-tariff, it's visible on many pages from microsoft but I cannot select it in azure. That would mean we'd need two stv2 standard tariffs which doubles the cost. Is there any information if this ever will be released and if yes, when?
Because of the above two problems I cannot try out the migration with a way back (duplicate API management from backup) because the migration with changing the network has no way back.
Of course I could setup a new stv2 API-management but the effort to setup everything is very high so I'd like to avoid that.
Has anyone done it already and can share information which could help me to do this migration?
- Yes, I refered to this guide. But after contacting microsoft I found out something more, see other reply.
- 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).- Thanks for your Ideas!
However after contacting Microsoft I got explained that stv2 does not mean v2 tariff, meaning that stv2 will have the same pricing as stv1. So I can get a 48hour extension period for fallback during migration and do not have to switch the dev-tariff to standard!
