Which API management platform fits your estate
Azure API Management fits Azure-centric teams that want a managed service, while WSO2 API Manager fits teams that must host the full stack themselves. If your estate is mostly Azure, your APIs sit behind Azure networking and identity, and your operators prefer Microsoft to run the control plane, the managed model is the natural starting point. If your renewal, a residency rule or an air-gapped network requires the gateway, control plane, developer portal and publisher inside your own data centers, WSO2 API Manager is the product to evaluate, since its Apache-2.0 code can be deployed from extracted packages or on Kubernetes.
The decision turns on three questions. First, where must traffic and management data live, and does the regulator or your data classification allow a SaaS control plane at all? Second, which portal and policy features your consumers need: sign-up, subscriptions and keys for partners, and the mediation and throttling rules your internal teams depend on. Third, who will operate the platform after go-live, including upgrades, certificates, backups and on-call. List every API by consumer type and count the policies each one uses before comparing products, because that list drives most of the effort.
Keep the comparison neutral on licensing. WSO2 API Manager is Apache-2.0 licensed, yet WSO2 also sells commercial subscriptions that bundle expert support, continuous product updates, vulnerability monitoring and access to a licensed distribution for commercial use. Ask WSO2 which of these your use case requires, and ask Microsoft which Azure API Management tier and networking features your deployment needs. Compare total cost by component: software or subscription, infrastructure you run, staff time and migration, rather than by the license line alone.
Scenarios where each option is the better fit
This table maps common enterprise situations to the platform that usually fits them better, along with the condition that tips the decision. Read each row against your own estate, identity stack and operating capacity, since several conditions often apply at once.
| Scenario | Better fit | Condition that makes it so |
|---|---|---|
| Azure-only estate with no on-premises requirement | Azure API Management | Your APIs, identity and monitoring already sit in Azure, and you want a managed control plane and portal without running servers. |
| Air-gapped or sovereign deployment | WSO2 API Manager | You must run the gateway, control plane and developer portal inside your own data centers or isolated networks with no outbound dependency on a vendor-hosted service. |
| Many partner developers needing a self-run portal | WSO2 API Manager | You want to host the Developer Portal, sign-up, subscriptions and applications under your own domain and data governance, and you have staff to administer it. |
| Multi-cloud or mixed gateway estate | WSO2 API Manager | You need one control plane to manage WSO2 gateways alongside third-party gateways such as Kong, AWS, Azure or Envoy, as stated in WSO2's platform description. |
| Small team with no platform engineers | Azure API Management | You lack capacity to patch, scale and back up gateway infrastructure, and a managed service with tiers matched to your traffic fits your operating model better. |
| Heavy reliance on Azure-native policies and Entra ID | Azure API Management | Your policy XML, named values and authentication already follow Azure conventions, so moving them has a high rework cost. |
| Need for custom authenticators, policies and workflows | WSO2 API Manager | Your business logic requires code-level extension of authentication, policy or approval flows, which the repository says the product supports. |
| Support and licensing under your own contracts | WSO2 API Manager | You prefer an Apache-2.0 core with a separately purchased subscription for support and updates, and you want to confirm the terms of the licensed distribution for commercial use with WSO2. |
Deployment choices: Azure-managed, hybrid or fully self-hosted
Azure API Management runs as a managed service in Microsoft's cloud. Microsoft operates the management plane, the gateway infrastructure, the developer portal hosting and the underlying patching, while your team configures APIs, products, policies and subscriptions through Azure. Azure API Management also offers a self-hosted gateway option, which keeps request processing in your own environment, but its documentation describes the connection to Azure that the gateway still needs, so confirm that dependency for your tier.
- Control plane: Azure hosts the management API, configuration and analytics for the service.
- Gateway: Default gateways run in Azure regions, and traffic reaches them through Azure networking.
- Self-hosted gateway: Confirm in Microsoft's documentation which tiers include it and what outbound connectivity it requires.
- Developer portal: Hosted by the service unless you set up a custom deployment that your team maintains.
- Operations: Microsoft handles service availability and platform upgrades under its own service terms.
Before you rely on this model, ask Microsoft in writing where each component runs, which data leaves your network, and which regions host your configuration and logs.
WSO2 describes a hybrid model in which the control plane is hosted as SaaS while gateways run on premises or in your own cloud accounts. API traffic stays in your environment and passes through your gateways, but the management layer, including the publisher and developer portal, depends on WSO2's hosted service. This split suits teams that want local traffic handling without operating the control plane themselves.
- Gateways: Run in your data center or cloud accounts, so request payloads stay local.
- Control plane: Hosted by WSO2, so configuration metadata and portal operations sit outside your network.
- Dependency: Gateway operation during a control plane outage depends on how WSO2 implements the link, which you should test.
- Responsibilities: Your team operates gateways while WSO2 operates the hosted control plane under its terms.
- Data review: Check which metadata, logs and analytics leave the environment in this model.
Confirm the exact data flows and failover behavior with WSO2 before you commit, and get the uptime commitment for the hosted control plane in writing.
In the fully self-hosted model, your team installs WSO2 API Manager from extracted packages on your own servers, or on Kubernetes using WSO2's separate API Platform for Kubernetes. The gateway, control plane, traffic manager, publisher and developer portal all run inside your network, which is the model that best fits air-gapped or strict residency requirements. Your organization then owns upgrades, backups, high availability and incident response.
- All components: Gateway, control plane, publisher, developer portal and traffic manager run in your infrastructure.
- Installation: Use extracted packages on premises or the Kubernetes option, which is a separate product from the core package.
- Build requirement: The repository notes that building WSO2 API Manager 4.7.0 requires JDK 21.
- Support: Community use is free under Apache-2.0, while WSO2's paid subscription adds expert support, continuous updates and vulnerability monitoring.
- Operations: Your platform team owns patching, scaling, certificates and disaster recovery.
Ask WSO2 which subscription tier covers your deployment model and which components are included in the licensed distribution for commercial use.
WSO2 also offers API Manager as a fully managed SaaS service, where WSO2 hosts and operates the platform. Your team manages APIs, applications and portal content, while WSO2 handles infrastructure and availability. WSO2's API Manager page describes a 99.95% SLA for this fully managed deployment, which is the commitment to review in the contract.
- Hosting: WSO2 runs the platform, so your data sits in WSO2's environment under its terms.
- Availability: The published 99.95% SLA applies to the fully managed service, so read its exclusions and credit terms.
- Operations: WSO2 handles upgrades and infrastructure, reducing internal platform work.
- Data residency: Ask where the service runs, which regions hold backups and which subprocessors touch your data.
- Exit path: Confirm how you export APIs, policies and developer accounts if you later move to self-hosting.
Request the service description and SLA document from WSO2 and check them against your residency and audit obligations before you choose this model.
What data control means for regulated API programs
For regulated API programs, the choice between Azure API Management and WSO2 API Manager is partly a question of where traffic, logs, credentials and control planes sit. The cards below cover the decisions and checks that connect data location with audit evidence, identity and vendor dependency.
Where API traffic and logs live
Gateway logs often contain request paths, client identifiers and sometimes payload fragments, so their storage location matters as much as the traffic itself. In Azure API Management, confirm which Azure region hosts the instance, where diagnostic logs and analytics are sent, and how long they persist. With WSO2 API Manager, you choose where the gateway and its analytics stack run, so map each log sink to a data classification and confirm retention and access controls in your own environment.
Where developer accounts and keys live
Developer accounts, subscription keys and application credentials are the most sensitive records in a developer portal. Ask where each store is held, whether keys are hashed or retrievable, and who can export them. Azure API Management keeps these records in the managed service, so migration requires a planned re-issuance of credentials. WSO2 API Manager stores them in the database you operate, which makes backup, encryption and deletion procedures your responsibility.
Identity integration with the directory
Regulated programs usually need developer and administrator sign-in to follow the organization's directory, including conditional access and joiner-mover-leaver removal. Azure API Management integrates natively with Microsoft Entra ID. For WSO2 API Manager, confirm the supported identity protocols against your directory, test group-to-role mapping, and document how deprovisioning reaches the portal and publisher consoles.
Compliance evidence the team must produce
Auditors will ask for access reviews, change records, configuration baselines and proof of log retention for the API layer. Your team has to generate this evidence from the platform itself. DeployOpen can prepare controls and evidence for a compliance assessment, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, so agree the evidence list with them before the migration starts.
Air-gapped feasibility
A fully disconnected network cannot rely on a SaaS control plane or on cloud-side telemetry. Azure API Management is a managed Azure service, so an air-gapped requirement generally pushes you toward a self-hosted gateway or a different product. WSO2 API Manager supports on-premises installation from extracted packages, which makes it a candidate for disconnected networks. Confirm package delivery, offline update procedures and licensing terms for your environment with WSO2 before committing.
Vendor dependency on the control plane
The control plane decides who can publish, subscribe and change policy, so its availability and exit path shape your risk. Ask what happens to published APIs and policies if the managed service is unavailable, and how configuration can be exported. WSO2 documents a model where one control plane manages WSO2 gateways and third-party gateways, which reduces lock-in at the gateway layer. Test that export and re-import work with your own APIs before you rely on either path.
How licensing and support differ in practice
WSO2 API Manager is Apache-2.0 licensed, so the core gateway, publisher, developer portal and traffic manager can be downloaded, run and modified without a license fee. What you pay WSO2 for is a commercial subscription, which the company sells for on-prem deployments. That subscription covers expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. The Monetization module is the exception: WSO2 states that its API Platform components are Apache-2.0 except Monetization, so if you plan to charge for API access, confirm its license terms separately before you design around it. Ask WSO2 which features your subscription tier includes, how long security patches are guaranteed for each release line, and whether the subscription covers the third-party gateways you intend to manage.
Azure API Management works differently. You pay Microsoft for a managed service on a tier basis, and the tier determines capacity, features such as multi-region deployment and the self-hosted gateway, and the availability commitment. Operations, patching and infrastructure sit with Microsoft, and the service-level agreement applies to the managed service. With WSO2, the license and the support contract are separate from the infrastructure you run, so your team or a partner carries patching, scaling and availability for the self-hosted deployment. Neither model is cheaper by default. The practical question is who is accountable for uptime and security fixes, and whether that accountability matches your internal staffing.
Before you commit to either path, confirm current Azure API Management tier terms, including what each tier includes and how it is billed, directly with Microsoft's pricing and SLA documentation. Ask WSO2 for the written subscription terms, support hours, response targets and update policy for the edition you need. Record the answers in your migration plan, and check them again at renewal, since both vendors change packaging over time.
What each option costs to own, by component
Azure API Management and WSO2 API Manager both bill for different things, so the total cost depends on which components you pay for, how often they recur, and who runs them. Use the cards below to build a like-for-like comparison before you request quotes.
Azure tier and unit charges
Azure API Management is billed by service tier, and the tier you need is usually set by features such as multi-region deployment, the self-hosted gateway, virtual network integration and capacity units. These charges recur every month for each instance and each environment you run. Ask Microsoft's pricing calculator to model your actual tier, unit count and regions, and confirm which features each tier includes today, because tier contents change over time.
WSO2 subscription and support
WSO2 API Manager is licensed under Apache-2.0, so the software itself has no license fee. The recurring cost comes from a commercial subscription if you want expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Ask WSO2 which subscription level covers your production, staging and disaster recovery clusters, and whether support covers your gateway and traffic manager components.
Control plane and gateway infrastructure
A self-hosted WSO2 deployment runs its own control plane, gateways, traffic manager and database. Each of these needs compute, storage, load balancing and backups in your cloud account or data center, and this cost recurs for as long as the platform runs. Compare this with Azure, where Microsoft operates the management plane for you. Ask your team to size each component separately, including the database and the nodes needed for high availability.
Networking and data transfer
Azure charges for networking that surrounds the service, including outbound data transfer, private connectivity and any virtual network setup you need for backend access. Traffic that stays inside your own network carries different costs when you self-host, because you pay for your own load balancers, egress and inter-zone traffic. Ask for a traffic estimate per API and per region, and confirm which Azure networking charges apply to your chosen tier.
Environments and region duplication
Every environment you need for development, testing, staging, production and disaster recovery adds to the cost of both platforms. On Azure this often means paying for separate instances and tiers per environment or region. On WSO2 it means provisioning extra clusters and databases, and a subscription that covers each one. Ask each vendor to quote the environments you actually run, not a single production instance.
Upgrades, migration and the internal team
Migration is a one-time cost covering API export, policy mapping, developer portal rebuilding, credential reissue and testing. Ongoing staff time covers upgrades, patching, monitoring, on-call and capacity planning, which Microsoft handles on Azure but your team handles on WSO2. Ask for a written scope that separates migration work from run work, and estimate the platform engineers who will own the cluster after cutover. DeployOpen scopes these items in writing before work starts.
What a move from Azure API Management involves
The sequence moves your API inventory, products, developer accounts and credentials onto WSO2 API Manager in an order that keeps consumers working while you shift traffic one API at a time.
Inventory APIs, products and consumers
Your platform or API team lists every API, product, subscription tier, named value and consumer application in the current Azure API Management instance, and marks which ones are internal, partner-facing or public. Azure API Management's own export tooling and the APIOps approach described in the export guide help build this list. The step is done when each API has an owner, a traffic profile and a target WSO2 environment recorded in a shared inventory that security and operations have reviewed.
Import OpenAPI definitions into the Publisher
Export the OpenAPI definitions for each API and import them into the WSO2 API Manager Publisher, which supports REST, GraphQL and AsyncAPI definitions. Check that paths, schemas, security schemes and examples survive the import, because Azure API Management often holds behavior in policy XML rather than in the definition itself. The step is done when each imported API renders correctly in the Publisher and a test consumer can see its documentation.
Rebuild products as API products and tiers
Recreate each Azure API Management product as a WSO2 API product, then define subscription tiers that match the throttling limits your consumers currently rely on. The traffic manager handles throttling in WSO2, so tier limits need to be checked against the original rate-limit policies, not copied blindly. The step is done when every product maps to a documented API product and tier, and an owner has signed off on any limit that changed.
Migrate developer accounts and applications
Move developer accounts and consumer applications into the WSO2 Developer Portal, mapping each Azure API Management subscriber to a WSO2 user and each subscription to an application with the right API product. Confirm how identity is handled, whether accounts are re-created, federated to your existing identity provider or invited to set new passwords, because Azure Entra ID integration does not carry over automatically. The step is done when a sample of developers can sign in and see the applications and subscriptions they had before.
Map policies to mediation and traffic controls
Translate each inbound, backend and outbound policy into WSO2 gateway mediation, authentication and traffic manager settings, or into custom extensions where no built-in equivalent exists. Typical policies to review include JWT validation, rate and quota limits, header transformations and backend routing, and each one should be tested against sample requests. Confirm with WSO2 which features your chosen edition covers. The step is done when every policy in the inventory has a mapped equivalent, a documented gap, or a named owner for a custom extension.
Re-issue credentials and run parallel traffic
Issue new keys and tokens from WSO2 and run the old Azure API Management and new WSO2 gateways side by side for the APIs in the first wave. Use staging consumers to confirm that authentication, throttling and error responses match expectations, and track errors in both environments. Azure subscription keys cannot be assumed to work in WSO2, so consumers must be told which credential to use. The step is done when test consumers succeed against WSO2 and the operations team has agreed on rollback criteria.
Cut over DNS one API at a time
Move each API's public hostname or route to the WSO2 gateway in small waves, starting with low-risk internal APIs and ending with high-volume partner APIs. Keep the Azure API Management route available until the new route has carried production traffic without incident and consumers have confirmed their credentials work. The step is done when every API in the inventory serves traffic from WSO2, the old Azure routes are retired on a recorded date, and the inventory reflects the final state.
Questions buyers ask before switching API management
What does it cost to run WSO2 API Manager compared with Azure API Management?
Azure API Management is billed by service tier and units, so most of the recurring bill is set by Microsoft's price for the tier you pick. Running WSO2 API Manager on your own infrastructure moves the spend to compute, storage, networking, database operations, and the people who run the platform. WSO2 also sells commercial subscriptions that add expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use, so you should confirm whether your organization needs that subscription or can run the Apache-2.0 product under its own support model. Ask WSO2 for the subscription terms in writing, and ask your team to model cluster sizing, high availability and on-call coverage before comparing totals.
How long does a migration from Azure API Management to WSO2 take?
The duration depends mainly on how many APIs you have, how many policies each one uses, and how many consumers hold subscriptions and applications. A program with a small set of APIs and simple rate limits moves much faster than one with dozens of products, custom policy fragments, named values tied to backends, and partners that must rotate credentials. Plan in phases: export your configuration, import OpenAPI definitions, re-create products as API products and subscription tiers, test each API on a staging gateway, then switch DNS API by API. Ask any implementation partner for a timeline that is tied to a written inventory of your APIs and policies, not a generic estimate.
Can our own team migrate to WSO2 without outside help?
A capable platform team can run a migration in-house, but it needs skills across several areas: Java and the WSO2 deployment model (the repository notes that building API Manager 4.7.0 requires JDK 21), Kubernetes or VM operations, TLS and identity configuration, and OpenAPI and API design. Your team also needs experience with policy translation, since Azure policy XML does not map one to one onto WSO2 mediation. Many organizations split the work: internal staff own the APIs, business rules and consumer communication, while an outside team handles the platform build, hardening and cutover. Decide early which of these skills you have today and which you must hire or contract.
Does WSO2 API Manager work with gateways hosted in Azure?
WSO2 states that one control plane can manage WSO2 gateways together with third-party gateways, and it names Kong, AWS, Azure and Envoy among them. This means you can keep a gateway running in an Azure environment while the control plane stays under your own management. Confirm the exact integration for each gateway type, the version you need, and how policies, throttling and analytics behave across mixed gateways, because a third-party gateway may not expose every feature the WSO2 control plane offers. Also check whether WSO2 supports a hybrid model, with a SaaS control plane and on-premises gateways, if that fits your sovereignty requirements.
What happens to developer accounts, subscriptions and API keys during the move?
Developer accounts, applications and subscription keys do not move automatically from Azure API Management to WSO2 API Manager, so each one needs a deliberate plan. The usual approach is to export subscriptions and developer details, map each Azure product to a WSO2 subscription tier, and then either re-issue credentials or migrate applications under a controlled cutover window. Some consumers will need to change their endpoint, key header or token configuration, so give them advance notice and a test environment. Ask your team to confirm how password hashes, OAuth clients and secrets can be carried over, since some data may need to be re-entered by the consumer.
Can the WSO2 Developer Portal replace the Azure developer portal?
The WSO2 Developer Portal covers the core job of a developer portal: API documentation, sign-up, application creation, subscriptions and key management, all served alongside the Publisher. Whether it fully replaces your current portal depends on the customizations you use, such as custom branding, content pages, self-service workflows, and single sign-on with your identity provider. Review each feature your partners rely on and test it against the WSO2 portal before deciding. The WSO2 repository notes that the product can be extended with custom authenticators, policies and workflows, which may cover gaps but adds development and maintenance work.
What should an implementation partner's scope include for this migration?
A written scope should list the deliverables in concrete terms: an inventory of APIs, policies, products, named values and diagnostics exported from Azure; a target architecture covering gateway placement, high availability, identity and TLS; the import and policy translation work; a test plan with consumer validation; the cutover and rollback steps; and documentation for operators. Ask for the handling of secrets, developer portal content and developer communications, plus a plan for backup and upgrades after go-live. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables and timelines before work starts. Ongoing support and upgrades are available as retainers.
How to decide and what to validate in a pilot
Run the pilot on one partner-facing API that already has real consumers, and take it end to end: import the OpenAPI definition into the WSO2 API Manager Publisher, publish it as an API product, let a partner developer onboard through the Developer Portal, subscribe, obtain credentials, and call the API through the gateway. Then do the same path in Azure API Management, using the same backend and the same test client. Time each step and record every manual action. The gap in manual steps often matters more to your operations team than the feature checklist, because it shows how much of the onboarding flow you will have to script and maintain yourself.
Test policy parity with specific cases rather than general claims. For rate limits, confirm that a quota or burst limit set per subscription tier throttles at the same threshold in both platforms, and check where the counter lives when you run more than one gateway node. For JWT validation, use tokens from your actual identity provider, including expired tokens, wrong audiences, and tokens missing the scopes your partner tiers depend on. Also validate how claims are passed to the backend, since header mapping differences tend to break partner integrations quietly. Confirm the current behavior of each feature in the WSO2 release you plan to run, including the JDK 21 requirement for building 4.7.0, and in Azure's own policy reference for your tier, because feature availability varies by tier and changes over time.
Finish with identity and operations, the areas most likely to cause a production delay. Test how each platform federates with your directory for publisher and admin roles, and whether partner accounts can be managed without giving them access to the Publisher. Then write and rehearse the runbooks: certificate rotation, gateway node restart, key revocation for a compromised partner, upgrade of the WSO2 release, and restore of the control plane database. Ask WSO2 for the support scope and upgrade process in writing, and confirm your own staffing to run it. Those answers, along with the pilot timings, form the basis for a decision you can defend to finance and to the partners who will be affected.
