Apigee vs WSO2 API Manager: when each one fits
Apigee fits when a managed or hybrid commercial platform, run under Google's operating model, meets your hosting and support needs. WSO2 API Manager fits when the API control plane, gateway, developer portal and traffic manager must run inside your own network under an Apache-2.0 license. The decision turns on four questions: where the control plane must run, whether you need a built-in monetization module, how much platform operation your team can staff, and whether you want WSO2's commercial subscription for support and updates. Answer these before you request a quote, because each one changes the architecture, the license terms and the run cost.
Start with the control plane, because it decides what can stay inside your network. WSO2 API Manager can run self-hosted from extracted packages, as a managed cloud service, or on Kubernetes through the separate WSO2 API Platform for Kubernetes. Its hybrid model places on-premises gateways under a SaaS control plane, so test that split against your data residency rule before assuming it satisfies the requirement. A fully self-hosted deployment moves control plane operation to your team, which affects staffing and upgrade planning. The product is described in the WSO2 API Manager repository, and the release notes state that building version 4.7.0 requires JDK 21, which your build and runtime images must match.
Monetization and support are the two items most often missed in a cost comparison. The monetization module is excluded from the open-source license for WSO2's API platform components, so budget it as a separate decision if you charge per call or per plan. WSO2's commercial subscriptions add expert support, continuous product updates, vulnerability monitoring and the licensed distribution for commercial use. If your team can run upgrades, JDK changes, Kubernetes and traffic manager tuning, the self-managed path is workable. If it cannot, ask WSO2 in writing for the support scope, response commitments and renewal terms, and compare them with the terms your current Apigee agreement gives you. Product details are on the WSO2 API Manager page.
Which platform fits which scenario
This table matches common operating conditions to the platform that usually fits them, Apigee or WSO2 API Manager. Read each row against your own constraints, such as network boundaries, cloud estate, staffing and whether monetization is needed, and confirm the conditions with vendors before committing.
| Scenario | Better fit | Why |
|---|---|---|
| Regulated team that must keep the gateway and control plane inside its own network | WSO2 API Manager (self-hosted) | WSO2 supports on-premises deployment from extracted packages, so the gateway, Publisher and traffic manager can run entirely in your network. Confirm the air-gap steps with WSO2. |
| Team with a Google Cloud estate that wants a managed control plane | Apigee | Google operates the management plane for Apigee and hybrid setups keep the runtime in your Kubernetes. Holds only if Google-hosted management is acceptable to your data residency rules. |
| Team that needs a Publisher and Developer Portal in an Apache-2.0 product | WSO2 API Manager | The Publisher and Developer Portal ship in the Apache-2.0 repository, so no separate portal license is needed for those components. Confirm which features you need against the open-source distribution. |
| Team that wants one control plane to govern several gateways | WSO2 API Manager | WSO2 states one control plane can manage WSO2 gateways and third-party gateways including Kong, AWS, Azure and Envoy. Validate the integration depth for each gateway you run. |
| Team that needs built-in API monetization | Apigee | WSO2's Monetization module is outside the Apache-2.0 license, so monetization is a commercial add-on. Apigee includes monetization as part of its commercial product. Ask both vendors for the exact feature list in writing. |
| Team with no staff for platform operations | Apigee (managed) or a WSO2 subscription | A managed Apigee service or WSO2's managed cloud service shifts upgrades and uptime work to the vendor. Self-hosting WSO2 without support staff shifts that work to your team, so weigh subscription support first. |
How throttling and the developer portal differ in practice
WSO2 API Manager splits the work across distinct components, and the split matters when you test throttling. Its repository describes a gateway that handles routing, mediation and security, a traffic manager that handles throttling, and separate Developer Portal and Publisher web interfaces. The Publisher is where API owners define and publish APIs, and the Developer Portal is where consumers discover them, subscribe and manage applications. Because the traffic manager is a separate component from the gateway, your test plan should name each one explicitly: confirm which policies are enforced at the gateway, which are enforced by the traffic manager, and what happens to requests when the traffic manager is unavailable or slow. Ask WSO2 or check the deployment guide for the supported topology for your chosen deployment model.
On the Apigee side, check three behaviors before you compare features. First, record how quotas and spike arrest are configured on each proxy or product today, including the time windows, the counting scope (per app, per key or per product) and whether limits are enforced per message processor or across the environment. Second, confirm where your Developer Portal is hosted and who operates it, since that determines who handles app registration, API key issuance and key rotation. Third, document the approval flow for developer access and how credentials are revoked. Confirm each of these against current Google documentation and in your own Apigee environment, because the defaults and the portal options have changed over time and your organization may have customizations.
Throttling tests under real traffic matter more than any feature list. A checkbox that says a platform supports rate limiting does not tell you how it behaves at the boundary of a quota, when a spike hits a single node, or when the counting store lags. Build a test that replays representative traffic shapes from your logs, including bursts from a single key and many keys hitting one product, then compare the rejection responses, the reported counters and the latency under load for both platforms. Include the developer journey in the same test: register an application, obtain a key, subscribe to a product and confirm the quota shown in the portal matches the quota enforced at the gateway. Mismatches between the portal and the gateway are a common source of support tickets after cutover.
Capability comparison from the supplied facts
This table sets Apigee's general capability areas against WSO2 API Manager's documented features, so you can see where each product fits your API program. Apigee cells describe categories only, so confirm each one against Google's current documentation before you decide. The main takeaway is that WSO2 API Manager's licensing, control plane scope and deployment options are the points to verify closely in your own environment.
| Capability | Apigee (commercial) | WSO2 API Manager (open source) |
|---|---|---|
| Gateway | Managed or customer-run runtime that routes, secures and mediates API traffic. Confirm the runtime options with Google's current documentation. | Gateway for routing, mediation and security, included in the Apache-2.0 project. |
| Publisher and Developer Portal | API design, publishing and developer onboarding tools, with the portal in the Apigee product. Confirm portal features with Google. | Publisher and Developer Portal web interfaces included in the open-source distribution. |
| Throttling through the traffic manager | Rate limiting and quota policies configured on proxies and products. Confirm how quotas are scoped and enforced. | Traffic manager component for throttling, included in the open-source distribution. |
| REST, GraphQL and AsyncAPI support | REST proxies are the core use case. Confirm GraphQL and AsyncAPI handling with Google's current documentation. | Supports REST, GraphQL and AsyncAPI APIs, per the project repository. |
| Extension with custom authenticators, policies and workflows | Extensibility through policies and custom code. Confirm which extension points are available in your deployment type. | Custom authenticators, policies and workflows can be added, per the project repository. |
| Deployment on premises | Customer-run runtime is available through hybrid deployment. Confirm which management plane stays with Google. | Installed on premises from extracted packages, per the project repository. |
| Deployment as a managed cloud service | Google-managed SaaS. Confirm the service regions and availability terms with Google. | Fully managed SaaS option. WSO2's page cites a 99.95% SLA, which you should confirm in the contract. |
| Deployment on Kubernetes | Hybrid runtime runs on your Kubernetes cluster. Confirm supported versions with Google. | Through the separate WSO2 API Platform for Kubernetes. |
| Control plane managing third-party gateways | Managed control plane for Apigee runtimes. Confirm whether it governs non-Apigee gateways. | One control plane can manage WSO2 gateways and third-party gateways including Kong, AWS, Azure and Envoy, per WSO2. |
| Monetization | Monetization is a commercial Apigee capability. Confirm packaging and availability with Google. | The Monetization module is not under Apache-2.0, so it requires a separate commercial arrangement with WSO2. |
| Licensing | Commercial subscription with Google-managed or customer-run options. Confirm terms and tiers with Google. | Apache-2.0 for the platform. WSO2 sells subscriptions with support, updates, vulnerability monitoring and a licensed distribution for commercial use. |
Where the control plane and gateways run
WSO2 API Manager can run fully self-hosted, as a managed cloud service, on Kubernetes, or in a hybrid model with a SaaS control plane and on-premises gateways. Each option sends API payloads, logs and credentials to a different place, so the hosting choice is also a data residency and evidence decision.
Self-hosted from extracted packages
WSO2 API Manager is supported on premises from extracted packages, so the control plane, gateway, traffic manager and portals all run in your own data center or cloud accounts. Payloads, subscriber data and keys stay on infrastructure you operate. The cost is that your team patches, backs up and scales every component. Confirm the release you plan to run, which for the current line is 4.7.0 released on April 29, 2026, and that your JDK 21 build pipeline is in place.
WSO2 managed cloud service
WSO2 also operates API Manager as a managed cloud service. Operations, upgrades and availability become the vendor's responsibility under the subscription terms, while your APIs and traffic run on WSO2's hosting. Ask where the tenant is located, which regions are available, who holds access to logs, and how backups and key material are handled. Confirm these terms in writing against your residency rules before choosing this model.
Kubernetes with the WSO2 API Platform
On Kubernetes, WSO2 provides a separate WSO2 API Platform for Kubernetes rather than running the on-premises package inside a cluster. Your platform team decides how the gateway, control plane and storage are scheduled, networked and secured within your own clusters. Check how the platform is licensed and supported, how it aligns with your cluster admission and secrets policies, and whether your staff can run upgrades without vendor help.
Hybrid with a SaaS control plane
WSO2 describes a hybrid model in which the control plane runs as SaaS while gateways run on premises. API traffic then stays in your network, but configuration, metadata and some usage data reach the SaaS control plane. This is the closest comparison point to Apigee hybrid, where Google hosts the management plane. Map every data flow, including analytics events and tokens, before deciding whether the split meets your residency requirements.
Where payloads, logs and credentials go
The deployment model determines whether request and response bodies, access logs, API keys, OAuth tokens and client secrets leave your network. Self-hosted deployments keep them in your logging and secrets stores, while hybrid and managed models may send metadata or telemetry to the vendor. Ask Apigee and WSO2 for a written data flow diagram covering each of these items, and confirm which fields are masked before export.
Identity integration and audit evidence
Confirm how the Publisher, Developer Portal and gateway authenticate administrators and developers, and which external identity provider or token service they use. Audit trails for configuration changes, subscription approvals and key issuance must be retained where your assessors can sample them. DeployOpen prepares these controls and evidence for compliance assessments, but it does not issue audit reports. Independent auditors decide conformance, so agree on the evidence set with them early.
Confirm the Apigee data path
Before comparing hosting models, confirm the Apigee data path under your current contract. Establish which components run in Google-managed infrastructure, which run in your environment, where analytics and logs are stored, and which regions apply. Apigee hybrid and Apigee Edge for Private Cloud differ on this point, so the answer depends on your specific deployment and agreement. Use the answer as the baseline for the WSO2 comparison.
Where the Apache-2.0 license stops and WSO2 subscriptions begin
WSO2 states that its API Platform components are Apache-2.0 licensed except the Monetization module, and that is the boundary a team must map before it commits. The gateway, Publisher, Developer Portal, control plane and traffic manager that the WSO2 API Manager repository describes can be used, modified and self-hosted under Apache-2.0. Monetization is the exception. If your Apigee estate charges developers per call, bills by plan, or relies on revenue reporting tied to subscriptions, you cannot assume that capability ships in the open-source code. Before you scope the migration, list every monetization rule, invoice flow and usage report Apigee provides today, then confirm with WSO2 which of those, if any, the Monetization module covers and what it would cost to license. Where it does not cover them, you will build billing integration yourself, likely on top of the usage data the traffic manager and gateway already emit, and you will own its accuracy and audit trail.
WSO2 also sells commercial subscriptions for API Manager. According to its repository, these provide expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. The code is open, so the subscription buys operational assurance rather than features you cannot otherwise get. For a regulated team, the questions that matter are who responds to a production incident and within what agreed window, how security advisories reach your operations staff, and whether your intended use falls within the terms of the licensed distribution. Ask WSO2 to put the support scope, update cadence, advisory process and commercial-use terms in writing, and check whether the subscription covers the Monetization module separately. Your own staff, or an implementation partner, will still need to patch, back up and upgrade the deployment if you run it without a subscription.
Apigee's commercial packaging works differently. Google sells Apigee in tiers and deployment models, including Google-managed, hybrid and private cloud options, and the commercial value sits in the managed platform and its built-in capabilities. Comparing the two at a conceptual level, WSO2 separates the software license from the support contract, so you can run the open-source distribution and add a subscription later, while Apigee bundles more of the operating model into one commercial relationship. Packaging, feature availability and pricing change, so confirm current Apigee tiers, included features and terms directly with Google, and confirm the WSO2 subscription tiers, Monetization terms and commercial-use conditions with WSO2 before you decide. Get both answers in writing, mapped to the specific Apigee features your estate uses.
What each option costs to run over time
Apigee and WSO2 API Manager split costs differently: one is largely a vendor subscription, the other is open-source software you run with optional commercial support. The cards below separate the components so you can ask each vendor and each internal team for the right numbers before comparing totals.
Apigee licensing and usage charges
Apigee is a commercial platform, so the license and any usage or environment charges recur for as long as you use it. Ask whether charges scale with API calls, the number of environments, the number of hybrid runtime instances or add-ons such as analytics, and whether each is billed monthly or annually. Traffic growth and extra environments are the usual drivers. Confirm how the price changes if you move to hybrid or Edge for Private Cloud, because the deployment model changes what you pay for.
WSO2 subscription fees
WSO2 API Manager is Apache-2.0 licensed, so the software itself carries no license fee. A WSO2 subscription is optional and recurring, and it buys expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Decide whether your organization needs that cover before committing, and ask whether the subscription price depends on core count, node count, deployment type or the number of gateways.
Gateway and control plane infrastructure
Both options need compute, storage, load balancing and networking for the gateways, the control plane and the traffic manager. These costs recur and grow with request volume, the number of gateways and the number of environments you keep for development, test and production. WSO2 supports on-premises, Kubernetes and hybrid layouts, so the hosting choice changes the bill. Ask your platform team to size each layer separately and to price high availability and disaster recovery copies.
Implementation and custom mediation
Migration is largely one-time work: mapping API products, policies and flows, rebuilding mediation logic and wiring authenticators or workflows. Effort rises with the number of APIs that need custom mediation, with each Apigee policy that has no direct equivalent and with the number of backends and identity systems to connect. Ask for a fixed scope that lists which APIs are in and which custom extensions are included, and who owns the test evidence for each cutover.
Developer portal and monetization work
The WSO2 Developer Portal covers documentation, subscriptions and key management, but portal branding, onboarding flows and developer support processes are work your team or a partner must own. Monetization sits outside the open-source license, so if you charge developers per call, you must check whether the Monetization module is in your subscription scope and plan its build separately. Ask whether portal content migration and monetization configuration are priced as one-time items or as recurring services.
Staff for upgrades, backups and patches
Self-hosting moves patching, upgrade testing, backup restores and security response into your organization, and these are the costs most often underestimated. The work recurs with each WSO2 release, each JDK and operating system update and each audit cycle. Count the on-call hours, the test environments needed to rehearse upgrades and whether your team already runs similar Java and Kubernetes services. Ask a vendor or partner which of these tasks they will take on under a retainer.
What moving from Apigee to WSO2 API Manager involves
The sequence moves APIs, policies, developers and quotas from Apigee into WSO2 API Manager in controlled waves, so each API group is proven on the new gateway before the old traffic path is retired. The result is a tested inventory, a rebuilt portal and a cutover with a rollback path.
Inventory APIs, products, developers and quotas
Your API platform team lists every Apigee API proxy, shared flow, API product, developer, app credential and quota, then maps each product to the consumers that depend on it. Record which proxies share flows and which quotas are enforced per app, per product or per developer, because these decide how much mediation logic must be rebuilt. The step is done when every proxy and product has an owner, a consumer list and a target API group in the WSO2 Publisher. Ask your Google or Apigee contact to confirm which entities are exportable in your edition before you rely on the list.
Export proxy definitions and configuration from Apigee
Download each deployed proxy revision and its shared flow bundles, along with environment configuration, target server definitions and key value map references, using the Apigee management API or your existing tooling. Store the exports in version control with the revision number and environment in the file name. The step is done when a second engineer can open each bundle, identify its target endpoints and confirm that the exported revision matches what is deployed in production.
Map Apigee policies to WSO2 mediation and traffic manager
Translate each Apigee policy into a WSO2 equivalent, such as a mediation sequence, a throttling policy in the traffic manager, a security handler or an endpoint configuration. Mark every policy that has no direct equivalent, including JavaScript, Java callouts or custom message transforms, and decide whether it becomes a custom mediator, an authenticator, a workflow or a change to the backend. WSO2 states that custom authenticators, policies and workflows can be added, according to its repository, so confirm the extension approach against the version you plan to run. The step is done when every policy is marked as mapped, rebuilt or retired, with a named owner for each custom item. Effort depends on the number of policies and shared flows, so measure this in your own estate rather than relying on a generic estimate.
Rebuild the developer portal and app onboarding
Recreate API documentation, subscription tiers and application registration in the WSO2 Developer Portal, and define how developers request keys and how approvals are routed. Confirm that existing developer accounts, app names and key rotation expectations can be carried over, or plan a re-onboarding notice for consumers. The step is done when a test developer can discover a migrated API, register an application, obtain credentials and call the API through the new gateway in a non-production environment. Your team should also confirm which Apigee portal features your consumers actually use before rebuilding them.
Set up WSO2 environments and the control plane
Install WSO2 API Manager in your own environments, using extracted packages on premises or the Kubernetes option through the separate WSO2 API Platform for Kubernetes, and configure the control plane, gateway and traffic manager for each stage. Build from the release tag you have validated, noting that the repository states building the 4.7.0 release requires JDK 21. Connect your stage gateways to a shared control plane only where your data residency rules allow it. The step is done when promotion from development to staging is repeatable, the gateway and traffic manager report healthy, and your security team has reviewed key storage, certificates and logging for each environment.
Run parallel traffic and test throttling under load
Route a copy or a small share of read-only traffic through WSO2 while Apigee remains the production path, then compare response codes, latency, payload content and throttle decisions between the two gateways. Run load tests that reproduce peak quota consumption so you can confirm that the traffic manager blocks and releases requests as the Apigee quotas did. The step is done when response parity and throttling behavior match your agreed acceptance criteria, and every difference has a recorded cause and fix.
Cut over one API group at a time with a rollback path
Move one API group at a time by changing the DNS or gateway routing for its consumers, starting with the group that has the fewest custom policies and the lowest business impact. Keep the Apigee route and credentials active until the group has run cleanly under normal load, and document the rollback steps before each change. The step is done when each group has a signed-off cutover record, monitoring confirms steady error rates, and the Apigee route for that group has been reviewed for retirement.
Questions buyers ask before moving from Apigee to WSO2
How much does moving from Apigee to WSO2 API Manager cost?
The cost depends on the components you pay for, and no fixed figure applies to every estate. Expect a one-time part covering inventory, rebuilding policies as WSO2 mediation or custom extensions, testing, cutover and documentation, plus a recurring part covering infrastructure, the operations team, and any WSO2 subscription you choose. The main cost drivers are the number of APIs and environments, how many Apigee policies are custom or script-based, the number of developers and partner apps to migrate, and the depth of your security and compliance evidence. When you request a quote, ask for each component to be priced separately: discovery, mediation rebuild, portal setup, traffic manager configuration, testing, cutover support, and run costs. Compare that against your current Apigee charges, which are set by your contract and not by this page.
How long does an Apigee to WSO2 migration usually take?
Timing is set by the size and complexity of your API estate, not by a standard duration. The largest factors are the number of proxies and shared flows, how many custom policies need rewriting, how many consumers and quotas must be re-created in the Developer Portal, and how many environments you cut over one at a time. Teams that already run stable CI pipelines and have clean API documentation usually move faster than teams that must first establish ownership of each API. Ask any implementation partner to base the timeline on a written inventory of your proxies and policies, and to show the cutover plan for each environment before work begins.
What does our team need to provide during the migration?
A migration needs three groups of people from your side. API owners confirm which APIs are live, who consumes them, and which versions must stay available. Security reviewers approve authentication, token handling, throttling policy and any changes to data exposure. An operations owner runs the platform after go-live, including upgrades, certificate rotation, logging, backup and incident response. You should also provide access to Apigee exports, a test environment that mirrors production, and a named decision-maker who can sign off scope changes. Without these roles filled, timelines usually slip at the points where a design choice needs an owner.
Can our own team migrate to WSO2 without outside help?
Yes, a capable platform team can run the migration alone, provided it has people who know WSO2 API Manager's Publisher, gateway, traffic manager and Developer Portal, and who can rebuild Apigee mediation logic in Java or the product's extension points. Outside help usually adds value in three places: the initial inventory and mapping of Apigee policies, performance and security testing before cutover, and the runbooks and documentation that your operations team will rely on later. The decision depends on your team's current skills, its capacity during the migration window, and how much of the work it can absorb while keeping existing APIs running.
Do we need a WSO2 subscription to run API Manager in production?
WSO2 API Manager is licensed under Apache-2.0, so the open-source product can be downloaded and run without a license fee. A WSO2 subscription is a separate commercial decision. According to WSO2's repository, its subscriptions add expert support, continuous product updates, vulnerability monitoring, and access to the licensed distribution for commercial use. Teams that have in-house expertise and can monitor security advisories themselves may run without one. Teams that need contractual support, a patch cadence they can rely on, or a licensed distribution for commercial use should ask WSO2 for the terms in writing. Also confirm whether the Monetization module, which WSO2 states is outside the open-source license, is part of your requirements.
Does the Apigee Edge for Private Cloud end of life change our urgency?
Yes, if you run Apigee Edge for Private Cloud on premises, the end of life date sets a hard deadline for your planning. Apigee's documentation states that version 4.53.01, first released on August 26, 2025, reaches end of life on June 30, 2027, after which Apigee stops providing bug fixes, security updates, hotfixes or patches for that line. Continuous support requires running a version within its 18-month full support window. Ask your Apigee contact which version you are on, which upgrade path applies, and whether a bridge release or support extension is available. Build the WSO2 migration plan so that the cutover date falls well before June 30, 2027, and keep the current cluster patched until the last API has moved.
How do we handle custom Apigee policies during the move?
Start by listing every custom policy, JavaScript callout, Java callout and shared flow, then classify each one by what it does. Many policies map to WSO2 built-in mediation, throttling or security features. Others need a custom mediation extension, a custom authenticator, a workflow change, or a redesign at the backend. WSO2 API Manager can be extended with custom authenticators, policies and workflows, according to its repository, so most gaps can be closed in code. Keep a mapping table that records each Apigee policy, its WSO2 equivalent, the owner who approved it, and the test that proves the behavior matches. Policies with unclear business logic should be confirmed with the API owner before they are rebuilt.
Can the WSO2 migration be delivered as a fixed-scope engagement?
Yes, most DeployOpen engagements are fixed-scope, and the scope, deliverables and timelines are agreed in writing before work starts. For a migration, that agreement usually names the APIs and environments in scope, the Apigee policies to be rebuilt, the test and cutover criteria, the documentation to be handed over, and what happens if the inventory shows more work than expected. Ask for a written change process so that new findings are handled through a documented scope change rather than an unplanned overrun. Ongoing support, upgrades and continuous testing after go-live are available as separate retainers.
How DeployOpen helps evaluate and migrate to WSO2 API Manager
DeployOpen starts by mapping your Apigee proxies, products, developers and traffic patterns to WSO2 API Manager's publisher, developer portal, gateway and traffic manager. We then plan, build and hand over a self-hosted deployment inside your own cloud accounts, data centers or air-gapped network.
How we scope
- Inventory Apigee proxies, shared flows, API products, apps and quota settings before any design work begins.
- Agree in writing which APIs, environments, portal features and third-party gateways are in scope.
- Engagements are fixed-scope, with deliverables and timelines confirmed before work starts; a quote follows from the written scope.
How we build
- Install WSO2 API Manager on your infrastructure, noting that building the 4.7.0 release requires JDK 21.
- Rebuild mediation logic, throttling policies and developer onboarding flows, then test them against representative traffic.
- Run security testing of the gateway, APIs and portal, and document the configuration and controls used.
How we hand over
- Deliver runbooks for deployment, configuration changes, backups, upgrades and incident response for your operations team.
- Document how each Apigee policy was mapped, replaced or dropped, so reviewers can trace every decision.
- Prepare compliance readiness evidence for your assessors; independent auditors and certification bodies issue any formal reports.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Confirm with WSO2 whether a commercial subscription suits your support and vulnerability monitoring needs.
- Review licensing scope, including which features sit outside the open-source license, before go-live and at each upgrade.
