Migrate from Azure API Management to Apache APISIX

Migrate from Azure API Management to Apache APISIX: what moves and what does not

APIs, routing and gateway behavior move well to Apache APISIX. The developer portal, subscriptions and keys, and policy logic need deliberate rework. Most teams leave Azure API Management for one of three reasons: a renewal that changes the cost picture, a Microsoft-hosted control plane they want out of their data path, or a requirement to run the gateway inside their own network. Whichever applies, the backend services, hostnames, TLS certificates and upstream routing are the easy part. APISIX is licensed under Apache-2.0, ships with more than 100 built-in plugins covering authentication, security, traffic control and observability, and runs without any commercial control plane. Its traditional, decoupled and standalone deployment modes let you choose how much of the management plane you operate yourself.

The work usually falls to a platform or API team, with security engineers reviewing authentication and secrets handling before any traffic moves. Export your APIs and policy XML first, then map each policy to a plugin in a staging environment. Rate limits and quotas map to traffic-control plugins, JWT validation maps to the JWT or openid-connect plugins, and header or body transformations need a separate check because policy expressions do not translate one to one. Confirm the exact plugin names and parameters against the APISIX documentation for your version, and test each policy's failure behavior, not only its success path.

Expect the developer portal, subscriptions and keys to be the highest-risk area. APISIX is a gateway, not a portal, so you will need a separate portal or catalog and a process for issuing, rotating and revoking consumer credentials. Existing subscription keys cannot be assumed to carry over, so plan a dated cutover per API with consumers notified in advance and DNS changed one API at a time, keeping the Azure route available until traffic on the APISIX route is verified. Ask your DeployOpen or internal team to confirm which Azure features your APIs actually use, since undocumented dependencies on named values, diagnostics or Entra ID settings are where migrations usually stall.

Which Azure API Management capabilities map to APISIX plugins and which need rework

This table maps common Azure API Management capabilities to their closest Apache APISIX equivalents and labels each row as clean, needs rework or gap. Use it to scope which policies can move as configuration and which need redesign or a separate tool. Confirm each plugin's behavior against the APISIX plugin documentation for your exact version before you cut over.

Azure API Management capability	APISIX equivalent	Migration notes
Rate limit and quota policies	limit-count and limit-req plugins	Needs rework: map each rate-limit-by-key and quota policy to a plugin with the same key and window, then test counters across multiple APISIX nodes.
JWT validation policy	jwt-auth plugin or openid-connect plugin	Clean for token checks: openid-connect works with Microsoft Entra ID. Confirm issuer, audience and claim mappings against your tokens.
Header and body transformations	proxy-rewrite and response-rewrite plugins	Needs rework: simple header set, remove and rewrite rules map directly; complex XML or JSON body transforms need custom logic.
Subscription keys	consumers with key-auth plugin	Needs rework: keys are not portable. Plan re-issuance and a cutover window for each subscriber.
Named values and secrets	Environment variables, APISIX secrets configuration or an external secrets manager	Needs rework: export named values from your APIOps export, then store secrets outside plain route definitions.
Backend routing and load balancing	upstreams with round-robin or other balancer types and routes	Clean for standard backends. Confirm health check and retry settings for each upstream.
Diagnostics and logging	Logging plugins such as http-logger or prometheus, with your own OpenTelemetry or log pipeline	Needs rework: Azure Application Insights and diagnostics settings do not transfer. Rebuild dashboards and alerts.
Custom C# policy expressions	Lua, Java, Go or Python plugin, or WebAssembly	Needs rework: each expression must be rewritten as plugin code and retested.
Policy fragments	Reusable plugin configuration or shared plugin code	Needs rework: flatten fragments into route or plugin config templates and verify inheritance behavior.
Products and developer portal	No direct equivalent in APISIX	Gap: APISIX has no developer portal. Use a separate tool such as Gravitee, WSO2 API Manager or Backstage.

How to sequence the migration from inventory to decommission

This sequence moves each API from Azure API Management to self-hosted Apache APISIX one at a time, with a tested route, a parallel run and a rollback path at every cutover. Each step closes with a named artifact so the team knows when it can move on.

Build the inventory of APIs and consumers
The platform or API team lists every API, operation, product, subscription, policy, named value, backend and known consumer in the Azure API Management instance, using an export from the APIOps tooling as the starting point. Each row records the backend URL, the authentication method, the policies applied and the owner who can confirm behavior. The step is done when an inventory sheet covers every API in scope and the owners have signed off on it, with gaps and undocumented consumers marked for follow-up.
Classify APIs by risk and pick a pilot
Using the inventory, the team sorts APIs by consumer count, traffic, data sensitivity and policy complexity, then selects one low-risk API with a small set of policies as the pilot. Policies that have no direct APISIX plugin equivalent are flagged now so they do not surprise the team later. The output is a ranked migration list with the pilot named and each unmapped policy recorded with a proposed approach.
Translate and test the pilot API
The engineer maps the pilot's policies to APISIX plugins, such as rate limiting, JWT or OpenID Connect validation and request transformations, and writes the routes, upstreams and consumers as a declarative configuration file kept in version control. The route is tested in a non-production APISIX instance against the same backend, covering success paths, authentication failures, throttling responses and header changes. The step closes when the tested route file and a test report with pass and fail results are stored with the inventory.
Run both gateways in parallel
The APISIX route for each migrating API is published on a separate hostname while Azure API Management keeps serving production traffic. The team sends test and pilot consumers to the new hostname, compares response codes, latency and logs between the two gateways, and checks that the backend sees the same requests. Consumers that need to move, including credential holders, are invited to test against the new hostname. The step is complete when the comparison results show no unexplained differences and the owners accept them in writing.
Cut over DNS one API at a time
The team switches the public DNS record for one API at a time, using a short time-to-live set well ahead of the change, and records the previous target, the new target, the change time and the named person who can reverse it. Each cutover is checked with synthetic requests and watched in logs before the next API moves. The output is a signed-off cutover list with a rollback record for every API, and the Azure route stays in place until the rollback window ends.
Decommission Azure routes and keys
Once every API in scope is live on APISIX and the agreed rollback window has passed, the team removes the Azure API Management routes, revokes subscription keys that are no longer needed and deletes exported configuration that is outside the retention decision. Retention rules for policy XML, logs and developer portal content are confirmed with the compliance owner before deletion. The step is done when the decommission record lists each removed item, its approver and the retention location for anything kept.

How to run Azure API Management and APISIX in parallel and switch DNS API by API

The safest way to move is to keep both gateways live at once and shift traffic one API at a time, so each cutover can be reversed in minutes. For a single site, deploy APISIX in traditional mode, where the data plane and control plane run together: client traffic arrives on port 9080 and the Admin API listens on port 9180, so restrict 9180 to your migration network and never expose it to the internet. If the APISIX data plane must sit in a separate network segment, such as a DMZ or a different cloud account, use decoupled mode instead, where the data plane reads from an etcd cluster shared with the control plane. Confirm with your platform team that the data plane can reach that etcd cluster before you plan cutover dates.

Many teams prefer standalone mode for the migrated APIs. In this mode there is no etcd, and APISIX loads routes and plugins from conf/apisix.yaml or conf/apisix.json, checking the file for changes every second and hot-reloading without a restart. Because the whole route set lives in one file, each change can be reviewed in a pull request, diffed against the exported Azure configuration and rolled back with a Git revert. The tradeoff is that standalone nodes do not share a live control plane, so you must confirm how your team will push the same file to every node and how it will verify that all nodes loaded the same version. Check the APISIX deployment modes documentation before you choose.

For each API, lower the DNS TTL on the record at least a full day before the planned switch so that resolvers pick up the change quickly, and keep the Azure hostname and its backend working until the old route is retired. Roll back by pointing the record at the Azure gateway again. Before retiring anything, compare error rates, latency percentiles and authentication failures on both paths for a period you agree in advance with the API owner, and use the same synthetic checks against each. Keep the Azure subscription keys valid during that window. Set the retirement date only after the comparison shows the APISIX path matches or beats the baseline.

What data and integrations to export, rebuild and re-issue

Some Azure API Management configuration can be extracted and replayed into APISIX, while other items carry secrets, identities or telemetry that must be rebuilt or re-issued. Sort each item into one of those groups before you cut over, and confirm every export path against your own tenant and subscription.

API definitions and policy XML

Start by extracting APIs, operations and policy XML with the open-source APIOps tooling, which is the documented starting point for pulling configuration out of Azure API Management. Treat the export as input to a mapping exercise, not as something APISIX can load unchanged. Each inbound policy needs a matching APISIX plugin or a documented gap, and you should record which is which in a migration register. Confirm the export covers global, product and API-level policies, since missing one scope is a common source of silent behavior change.

Subscription keys and developer accounts

Subscription keys do not move as usable secrets, so plan to re-issue credentials for every consumer rather than copying key values across. Export the subscription and product metadata so you can recreate the same scopes, owners and rate tiers in APISIX consumers and plugin configuration. Agree with each consumer team when old keys stop working, and run both gateways in parallel during that window. Confirm with your developer portal owner how existing sign-ups are contacted and re-onboarded.

Identity integration with Entra ID

Where Azure API Management validates Microsoft Entra ID tokens with a validate-jwt policy, APISIX uses the openid-connect plugin, which supports authorization code, client credentials and token introspection flows. Decide per API which flow each client uses, because a browser app, a service principal and a partner API need different settings. Register the APISIX route as a client or resource in your tenant, and confirm the issuer, audience and signing key discovery values against a test token before cutover.

Backend certificates and mutual TLS

Backend certificates, client certificates and any mutual TLS settings are not portable through a configuration export, so inventory each one that Azure API Management presents to a backend or accepts from a client. Recreate the trust chains and certificate files in APISIX, and keep private keys out of route definitions. Check certificate expiry dates and intermediate CA bundles, because an API that works in staging can fail in production when a chain is incomplete. Confirm the exact steps with your certificate authority and platform team.

Named values and secrets

Named values in Azure API Management often hold backend URLs, API keys and other sensitive strings referenced by policies. Move the secret values into a dedicated secrets store and reference them from APISIX, instead of writing them into route files or the etcd configuration in plain text. Keep non-secret values such as hostnames in configuration, and document which secret backs each plugin setting so rotation has an owner. Confirm which named values are marked secret in your export before you assume they are safe to copy.

Logs and metrics pipeline

Azure API Management diagnostics and Application Insights telemetry do not follow the APIs to APISIX, so the log and metrics pipeline must be rebuilt. Choose where access logs and gateway metrics will go, such as a SIEM or a monitoring stack, and configure APISIX log plugins to ship to it. Compare field names and retention with what your security team relies on today, and test that alerts still fire during a parallel run. Confirm retention requirements with your compliance owner before decommissioning the old diagnostics.

What drives the cost and duration of the migration, and how to keep each driver down

This table lists the factors that set the effort of moving from Azure API Management to self-hosted Apache APISIX, why each one matters, and how to shrink it. Read it before scoping, because the first rows usually decide whether the work is a weeks-long translation or a months-long program. Rows marked as one-time or recurring show which costs you pay once and which you carry every year.

Driver	Why it matters	How to reduce it
Number of APIs and operations	Every API and operation needs a route, upstream, plugin set and test cases in APISIX. Effort grows with operations, not just with API count. This is a one-time translation and testing cost.	Inventory APIs with the APIOps export first. Retire unused APIs and operations before translation, and group similar APIs into shared route templates.
Count and complexity of policy XML	Inbound, outbound and backend policy sections must each be mapped to a plugin or to custom code. C# expressions, reusable fragments and conditional logic are the hardest to translate and test. This is a one-time cost.	Classify each policy as direct mapping, plugin combination or custom logic. Replace C# expressions with explicit plugin configuration where possible, and keep a small set of tested custom plugins.
Subscription keys and developer accounts	Keys cannot be copied as-is into APISIX consumers without a plan for hashing, storage and cutover. Each consumer that must be re-issued credentials adds support and coordination work. This is one-time.	Count active subscriptions and keys with the export. Agree a dual-key window with each consumer team, and confirm with the business owner which keys are still in use.
Developer portal dependency	APISIX has no built-in developer portal. If consumers sign up and manage keys through the Azure portal, you must provide a replacement or a documented process. This can be a one-time build plus a recurring hosting cost.	Decide early whether the portal is replaced by a separate tool, an internal catalog or documentation only. Export portal content and confirm the target before cutover.
Identity model and token validation	JWT validation policies and Entra ID sign-in must map to the openid-connect or jwt-auth plugins with the correct issuers, audiences and key rotation. Mistakes here are hard to see in testing. This is one-time, with recurring key rotation.	List every token issuer and audience per API. Confirm with your identity team how the openid-connect plugin will reach your identity provider, and test expired, wrong-audience and revoked tokens.
Number of backends and certificates	Each backend host needs an upstream definition, health checks, TLS settings and a certificate chain. Certificates expire and must be renewed on the APISIX side, which is a recurring duty.	Consolidate backends into shared upstreams where the hosts are the same. Inventory certificates and expiry dates, and automate renewal before the first production route is switched.
Team experience with APISIX and Kubernetes	A team new to APISIX, etcd or Kubernetes will spend more time on design reviews and troubleshooting. Skill gaps raise both one-time and recurring effort. Confirm the team's experience with the APISIX documentation and deployment modes before estimating.	Run a short proof of concept on the traditional or standalone mode in a non-production network. Assign named owners for gateway, etcd and ingress operations, and document runbooks as you go.
Monitoring and SIEM integration	Azure diagnostics and log flows feed existing dashboards and SIEM rules. Each log source, alert and retention rule must be rebuilt for APISIX logs and metrics, which is a one-time task with recurring alert tuning.	List current alerts and log consumers. Map them to APISIX logging and observability plugins, and confirm that log fields and retention satisfy your SIEM and audit requirements before cutover.
Change control and run cost in regulated environments	Regulated organizations need approved change records, test evidence and rollback plans for each route switch. The APISIX cluster itself has recurring hosting, patching, upgrade and on-call costs inside your own network. Confirm your change board's lead times and evidence needs in writing before the plan is fixed.	Switch DNS API by API with a defined rollback. Keep evidence per change. Budget the recurring run cost, including nodes, etcd backups, upgrades to supported APISIX releases and on-call rotation, and ask for these as separate line items in any quote.

How the migration differs by starting point and environment

A small estate with a handful of APIs, few policies and no developer portal is the simplest case. Most of the effort goes into extraction and verification rather than into developer onboarding, because there are few consumers to coordinate. The work can often run in one short cycle per API, provided each API is cut over with its own DNS record and a rollback path.

Extraction first: Export the APIs, policy XML and named values with the APIOps tooling, then confirm that every policy has a matching APISIX plugin or a custom plugin plan.
Standalone or traditional mode: A small estate often fits file-driven standalone mode, which hot-reloads a YAML or JSON file. Confirm whether you also need the Admin API and etcd.
Key handling: With no portal, subscription keys may live only in Azure. Decide whether consumers receive new keys or whether the gateway accepts existing keys through a plugin.
Monitoring: Replace Azure diagnostics with your own logs and metrics before the first cutover, since there is no built-in dashboard to fall back on.

Before starting, ask whether any consumer calls the gateway from outside your network and whether the team has an owner for APISIX after handover.

What usually goes wrong in an APIM to APISIX move and how to prevent it

Most APIM to APISIX problems do not show up as outages. They show up as policies that behave slightly differently, consumers that lose access on a schedule nobody agreed to, or DNS changes that cannot be undone quickly. The cards below cover the failures we see most often and the checks that catch them before production traffic moves.

Silent policy behavior changes

Azure API Management evaluates inbound, backend and outbound policy sections in a fixed order, and a default such as how a missing header or an unmatched route is handled may not carry over to APISIX plugins. Plugin priority decides execution order, so a rate limit that ran before authentication in APIM may run after it in APISIX. Build a side-by-side test suite that sends the same requests to both gateways and compares status codes, headers and response bodies, including error paths. Treat any difference as a defect until a reviewer signs off on it.

Consumers broken by key re-issue

Subscription keys exported from Azure API Management cannot simply be copied into APISIX consumers without a plan for how each client learns the new credential. If keys are rotated on cutover day, integrations with hard-coded keys fail immediately and support queues fill up. Agree a notice period with each consumer owner, run old and new credentials in parallel for that window, and publish a dated communication that names the owners who must act. Confirm which consumers are internal and which are partners under contract.

JWT issuer and audience mismatches

APISIX's openid-connect plugin validates tokens against the issuer and audience it is configured with, and Microsoft Entra ID issues tokens whose issuer and audience values depend on the app registration and token version requested. A value that matches in staging can fail in production if the tenant, the application ID URI or the v1 and v2 token format differs. Decode real tokens from each client, record the iss and aud claims, and test the exact values in the APISIX route before any DNS change. Confirm the discovery endpoint and key rotation behavior with your identity team.

Rate limits that count differently

A rate limit enforced in Azure API Management applies to the service as configured, while APISIX plugins keep counters in a store that depends on the chosen policy and deployment mode. When APISIX runs as several data plane nodes, a limit that counts per node can allow roughly the configured rate multiplied by the node count. Decide whether limits must be global or per node, load test with several nodes behind the load balancer, and document the counter backend your team operates. Confirm this behavior in the plugin documentation for the APISIX version you deploy.

DNS cutover without a tested rollback

Moving a hostname to APISIX API by API is only safe if the previous target can be restored in minutes. Teams often change records by hand, lower TTLs too late, or discover that the old APIM hostname has a custom domain certificate that no longer validates. Script each record change with the new target and keep a rollback record that restores the previous value. Rehearse the rollback in a non-production zone and confirm the TTL a resolver will honor before the change window opens.

Secrets copied into version control

APIOps-style exports of Azure API Management can include named values, backend credentials and certificate references, and copying those files into a Git repository exposes them to everyone with read access and to every clone. The same risk applies to APISIX configuration files that contain upstream credentials or the Admin API key. Keep exported secrets out of the repository, load them from a secret store at deploy time, and run a secret scanner on every commit. Review the export before the first commit and rotate any value that was ever committed.

What buyers and platform teams ask before moving from Azure API Management

How much effort does moving from Azure API Management to Apache APISIX take?

The effort depends mainly on how many APIs you run, how many policies each API carries, and how much of your program depends on the developer portal. Policy translation, such as rate limits, JWT validation and header transformations, is usually the largest technical task, because each Azure policy has to be mapped to an APISIX plugin and tested against real traffic. The effort table on this page breaks the work into components so you can see which items apply to your estate. Ask any implementation partner to price each component separately: API export, policy mapping, identity and network changes, subscription and key migration, DNS cutover, and run-book handover.

How long does an Azure API Management to APISIX migration take?

Duration depends on API count, policy complexity and the number of consumers that must be moved over. A small set of APIs with simple JWT checks and rate limits can move in a short, focused program, while a large estate with custom policy fragments, many named values and partner-facing products needs phased cutovers and more testing. No fixed timeline applies to every estate, so treat any duration you hear as a starting assumption until your own inventory is complete. Ask for a plan that groups APIs into waves, names the dependencies for each wave, and states which items depend on your change windows and approvals.

What does the migration need from our own team?

The work needs people who can grant access and make decisions, not only people who write configuration. Plan for read access to the Azure API Management instance, including APIs, policies, products, named values and diagnostics, and the ability to export them. You also need the API owners who can confirm behavior and sign off on cutovers, an identity contact who manages the Entra ID or other identity provider configuration, and a network contact who controls DNS, certificates, firewall rules and the path from the gateway to backends. Name these people before the work starts so approvals do not stall the schedule.

Can our team do the APISIX migration without outside help?

A team can migrate a small estate on its own if it already knows APISIX, has a clear inventory of APIs and policies, and can test each route before switching traffic. The work becomes harder for large programs that depend on the Azure developer portal, use many policy fragments, or need to keep subscriptions and developer accounts intact through the move. Consider a fixed-scope engagement when the team lacks APISIX operating experience or when the cutover must meet internal security or compliance review. DeployOpen plans, implements and documents such work inside your own infrastructure, with scope and deliverables agreed in writing before work starts.

What happens to subscription keys and developer accounts during the move?

Azure API Management subscription keys do not carry over automatically to APISIX, so consumers will need new credentials or a planned re-issue. APISIX uses its own consumer and authentication model, so you must decide how each existing subscription maps to a consumer, which plugin enforces the key or token check, and how long old and new keys overlap. Developer accounts live in the Azure developer portal, which APISIX does not provide, so their migration depends on the portal you choose. Ask your provider for a written mapping of every product and subscription, a consumer communication plan, and a rollback path for each API.

Can APISIX replace the Azure API Management developer portal?

No. APISIX is a gateway and does not include a developer portal with API documentation, sign-up, self-service subscriptions or key management for consumers. You need a separate portal, such as one from Gravitee or WSO2 API Manager, or a software catalog for internal APIs, plus a process for publishing documentation. Confirm which APISIX release you will run and whether its support status meets your policy, since the APISIX downloads page does not mark any release as long-term support. Check that version support and LTS status with the project and your own support plan before you fix a release for production.

How DeployOpen scopes, runs and supports the migration to APISIX

DeployOpen plans and implements the move to self-hosted Apache APISIX inside your own cloud accounts, data centers or air-gapped networks. Each engagement starts with a written, fixed scope that covers the APIs, policies, keys and DNS cutover you agree on before work begins.

How we scope

Inventory every API, product, subscription and named value exported from Azure API Management before estimating any work
Agree in writing which policies map to APISIX plugins and which need redesign or retirement
Define the cutover order, rollback steps and the APIs that move first, with ownership named for each

How we build

Stand up the APISIX deployment in your chosen mode, with etcd or file-driven configuration, inside your own infrastructure
Convert exported policy XML into APISIX routes and plugin configuration, stored as version-controlled files
Test rate limits, JWT validation, transformations and OpenID Connect flows against the original behavior before any traffic moves

How we hand over

Deliver the route and plugin configuration, deployment runbooks and a per-API cutover record for your team
Document the mapping from each Azure policy to its APISIX equivalent, including gaps you accepted
Walk your operations and security staff through admin API access, secrets handling and the DNS switch for each API

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
Ongoing support, APISIX upgrades and continuous testing are available as a retainer after handover
Ask for a quote based on your written scope, including who operates etcd, certificates and monitoring after cutover

Migrate from Azure API Management to Apache APISIX