Kong Konnect vs WSO2 API Manager: when each fits
Konnect fits teams that are content with a Kong-hosted control plane and want to keep operating their gateways without moving the management layer. WSO2 API Manager fits teams that need the control plane, Publisher, Developer Portal and traffic manager to run inside their own environment. A renewal or a residency requirement usually makes that second case concrete, because the question becomes where the management plane and its metadata live, not only where the gateways run. Three questions decide the choice: whether your Kong data planes must stay in place, who will operate the control plane day to day, and whether you need a commercial WSO2 subscription to support production use.
The first question is the most practical. WSO2's repository states that one control plane can manage WSO2 gateways and third-party gateways including Kong, so existing Kong data planes can remain while the management layer changes. Kong Gateway OSS, the Apache-2.0 edition, is available on the 3.9 line and supports DB-less and traditional modes, but it does not include the Konnect control plane or portal. Confirm with your Kong account team and the version support policy which Kong components you actually run today, including any Enterprise plugins that depend on Konnect. Those plugins will not carry over to an open-source data plane.
On licensing, WSO2 API Manager is Apache-2.0 licensed, so the code is free to use and modify. What a commercial subscription adds is expert support, continuous product updates, vulnerability monitoring and access to a licensed distribution for commercial use. Ask WSO2 which of these your compliance and vendor-risk process requires, and ask for the subscription scope in writing. Ask your operations team whether they can run the Publisher, the Developer Portal and the traffic manager themselves, and plan the subscription decision around that answer. Kong Gateway OSS 3.9 is also Apache-2.0, so the open-source route carries no license fee of its own, but it carries no published support window either.
Which platform fits which scenario
This table maps common buyer scenarios for moving off Kong Konnect to the option that fits best, with the reason tied to supplied product facts. Read each row against your own constraints, such as whether you must keep Kong data planes, whether you need a bundled developer portal, or whether your platform runs on Kubernetes. Where a scenario depends on details we have not verified, the cell says what to confirm.
| Scenario | Better fit | Reason |
|---|---|---|
| Keep Kong data planes but drop Konnect | Self-run Kong Gateway OSS with decK | Kong Gateway OSS is Apache-2.0 and supports DB-less and traditional modes, and decK syncs declarative files to open-source Kong Gateway. Konnect's control plane, portal and analytics would no longer be available, so confirm which Enterprise plugins you rely on. |
| Replace Kong and Konnect with one self-run control plane | WSO2 API Manager | WSO2's control plane can manage WSO2 gateways and third-party gateways including Kong, so existing Kong data planes can be brought under one management layer. Confirm the integration path for your Kong version with WSO2. |
| Need a bundled Developer Portal and Publisher | WSO2 API Manager | The repository describes Developer Portal and Publisher web interfaces as part of the product under Apache-2.0. Kong's open-source edition does not include a developer portal, so a portal would have to be built or sourced separately. |
| Need a managed SaaS control plane | Kong Konnect (retain) | Konnect runs the control plane for you, and WSO2 offers a fully managed SaaS option with a 99.95% SLA according to WSO2's API Manager page. Compare the terms, regions and data handling for each before deciding. |
| Need to keep all management on premises or in an air-gapped network | WSO2 API Manager | WSO2 supports on-premises deployment from extracted packages, and its control plane is self-hosted. Konnect's Kong-hosted control plane does not fit disconnected networks, so confirm that the self-hosted WSO2 build meets your offline install steps. |
| Running on Kubernetes | Depends on the gateway: Kong Ingress Controller or WSO2 API Platform for Kubernetes | Kong Ingress Controller is Apache-2.0 and suits Kong data planes on Kubernetes. WSO2 provides a separate WSO2 API Platform for Kubernetes, so test which approach matches your cluster and traffic model before committing. |
| Need the WSO2 subscription for support and updates | WSO2 API Manager with a commercial subscription | WSO2 sells subscriptions with expert support, continuous updates, vulnerability monitoring and a licensed distribution for commercial use. Choose this when your team needs vendor support on top of the Apache-2.0 code, and ask WSO2 for the exact terms in writing. |
| Illustrative: small team with one Kong cluster and no portal | Self-run Kong Gateway OSS | A team with a single cluster, no external developer audience and a GitOps workflow can keep declarative configuration in Git and skip a separate control plane. This is an illustrative case, not a recommendation for every team. |
Where the control plane runs and who holds the data
Kong Konnect and WSO2 API Manager both offer a managed control plane, but they place the data plane and the configuration store in different locations. The four options below show where your API traffic, policies and identity records can sit, and what each choice means for data residency and audit evidence.
Konnect's Kong-managed control plane
Konnect keeps the control plane, the management console and the portal on Kong's SaaS platform, so gateway configuration and usage metadata leave your network. Data plane nodes can still be self-hosted, which keeps request payloads inside your environment. Confirm with Kong which metadata is sent to the control plane, in which regions it is stored, and how it is handled if you need a fully disconnected network.
Konnect data plane placement options
Konnect data planes can be self-hosted, run as serverless gateways, or run as Dedicated Cloud Gateways that Kong operates on AWS, Azure or GCP. Each placement changes who operates the nodes, which cloud accounts hold the logs and where traffic terminates. A Dedicated Cloud Gateway means a third party runs your traffic path, so review its location, access controls and data handling terms before you select it.
WSO2 on-premises and hybrid control planes
WSO2 API Manager can run fully on premises from extracted packages, or as a hybrid deployment where the control plane is hosted by WSO2 and gateways stay on your premises. In the hybrid model, your gateways still send operational data to the SaaS control plane, so confirm exactly which metadata, logs and analytics leave your network. A fully self-hosted deployment keeps every component under your own administration.
WSO2 fully managed SaaS and its SLA
WSO2's fully managed SaaS option carries a 99.95% SLA, which you should compare with the availability terms in your Kong Konnect contract. Ask WSO2 where the managed control plane and any analytics stores are hosted, who holds administrative access, and how tenant data is separated. Written availability terms, data processing terms and sub-processor lists should be requested before the decision, not after.
Identity, keys and access boundaries
Whichever platform you choose, decide where administrator identities, API keys, OAuth clients and signing keys are stored. A SaaS control plane usually needs its own administrator accounts and single sign-on configuration, which adds a trust relationship to manage. Map which roles can publish APIs, rotate credentials and view traffic, and confirm whether the vendor offers customer-managed keys or single sign-on integration with your identity provider.
Compliance evidence and vendor attestations
A vendor's architecture diagram does not prove your compliance. Neither Kong nor WSO2 certifications are implied by this comparison, and any attestation covering your deployment must come from an independent auditor or certification body. Ask each vendor for its current audit reports and scope, then confirm that the services in use are covered, and build your own control evidence for the parts you operate.
Keeping Kong data planes or replacing both
This option keeps your existing Kong Gateway data planes and replaces only the Konnect control plane. WSO2 API Manager's control plane can manage third-party gateways, including Kong, so the gateways keep routing traffic while WSO2 handles publishing, subscriptions, the Developer Portal and throttling policy. The open-source Kong Gateway line you can run yourself is 3.9.x, while Kong Gateway Enterprise moves to quarterly releases, so plan the upgrade path for the gateways you keep.
- Gateway version: Confirm that your Kong data planes run a release the WSO2 integration supports, and check the Kong Gateway changelog before you pick a target line.
- Configuration source: Export services, routes and plugins with decK so the declarative files, not the Konnect console, become the source of truth.
- Plugins: Map Konnect-only plugins and features to open-source equivalents, since some capabilities tied to Enterprise or Konnect will not carry over.
- Traffic policy: Decide which throttling and subscription rules live in WSO2's traffic manager and which stay in the Kong gateway configuration, to avoid double enforcement.
- Team skills: Your platform team must operate Kong upgrades and WSO2 control plane upgrades on separate schedules.
Before committing, confirm with WSO2 which Kong versions and features its third-party gateway integration covers in your target release.
This option moves traffic to WSO2 gateways and retires the Kong data planes as well as Konnect. WSO2 API Manager includes a gateway for routing, mediation and security, a traffic manager for throttling, and the Publisher and Developer Portal, all under Apache-2.0 for the core platform. The work is larger because every route, plugin and consumer must be translated, but you end up with one vendor-neutral stack and one upgrade cadence.
- Deployment model: WSO2 supports on-premises installs from extracted packages, a managed cloud service, and Kubernetes through the separate WSO2 API Platform for Kubernetes.
- Build requirement: Building API Manager 4.7.0 from source requires JDK 21, so confirm your build pipeline supports it.
- Plugin translation: Rewrite Kong plugin behavior as WSO2 policies, authenticators or mediation sequences, and test each one against your current traffic.
- Commercial scope: Decide whether you need WSO2 subscriptions for expert support, continuous updates, vulnerability monitoring and the licensed distribution for commercial use, and confirm which WSO2 modules you would buy.
- Parallel running: Run both stacks side by side during cutover so you can roll back a route without touching Konnect.
Ask WSO2 to confirm which of your current plugins have direct equivalents before you estimate the translation effort.
This option keeps Konnect as the control plane and data planes, and treats the open-source options as a fallback rather than a migration. Konnect data planes can be self-hosted, run as serverless gateways, or run as Dedicated Cloud Gateways fully managed by Kong on AWS, Azure or GCP. You keep the Kong-hosted console and its vendor-maintained release cadence, and your team's work stays on configuration, not platform operation.
- Control plane location: Konnect's control plane is Kong-managed SaaS, so confirm that it satisfies your hosting, residency and connectivity rules.
- Data plane choice: Self-hosted data planes keep traffic inside your network even though the control plane is external.
- Cost driver: Konnect pricing follows its plan and metered items, so model growth in services, requests and published APIs before renewal.
- Exit readiness: Keep decK exports current so a later move to open-source Kong or WSO2 starts from a complete configuration.
- Support boundary: Confirm which incidents Kong supports under your plan and which fall to your own team.
Request the current Konnect plan terms and the data plane deployment options in writing before you decide, since these determine whether this path meets your requirements.
How the traffic manager and Developer Portal change your workflow
The biggest workflow change is where rate limits and API publication are defined. In WSO2 API Manager, the traffic manager handles throttling as a control plane function, so policies are set alongside the Publisher, where API owners define an API's lifecycle, versions and subscription tiers, and the Developer Portal, where consumers discover APIs and subscribe to them. Konnect splits this work differently: rate limits are attached to gateway services and routes in the Kong-hosted control plane, and its developer portal and analytics are metered items billed against published APIs and usage. Before you plan the move, list which teams change throttling policy, which teams publish to developers outside your organization, and whether those developers need self-service onboarding. Confirm current Konnect portal and analytics entitlements in your contract, since those are the parts that disappear when you stop paying for them.
If you keep Kong data planes, rate limiting moves into plugins. The Kong Gateway open-source edition provides a rate limiting plugin, but its cluster-strategy mode and the OAuth2 plugin depend on a database, so they only run in traditional mode. DB-less mode, which suits GitOps workflows driven by declarative files exported with decK, cannot use them. Test your current limits in a staging environment that matches the topology you intend to run, and confirm which plugins your Konnect configuration uses before assuming they carry over. Limits that depend on a shared counter across nodes need traditional mode and a database you operate yourself.
The Developer Portal gain is real only under certain conditions. It matters most when you publish APIs to external partners or customers who need self-service registration, documentation, application keys and subscription approval, because WSO2 bundles those flows with the Publisher and does not need a separate portal product. If your consumers are internal and small in number, a Git-based catalog with generated documentation may serve them with less operating effort. Ask your team to list the onboarding steps a new consumer takes today, then check which of them the WSO2 Developer Portal covers out of the box and which need custom work. Verify those details against the WSO2 API Manager documentation before you commit.
What each option costs to run
Running Kong Konnect against WSO2 API Manager is less about a single price than about which components you pay for, who bills each one, and which ones recur. The cards below separate subscription and metering from infrastructure, upgrades, support and internal engineering time, so you can build a like-for-like quote request.
Konnect subscription and usage metering
Konnect is a recurring SaaS subscription in which Kong's control plane is billed alongside the usage it meters. Ask Kong to itemize which dimensions are metered for your traffic, such as gateway services, requests, developer portals and published APIs, and whether your data plane runs self-hosted, serverless or as a Dedicated Cloud Gateway, because each choice carries different charges. Confirm current terms directly with Kong, since its pricing page is the place to start.
WSO2 commercial subscription
WSO2 API Manager is Apache-2.0 licensed, but a commercial subscription is the recurring item that buys expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use. Ask WSO2 which tier covers your deployment model, whether it is self-hosted, hybrid with a SaaS control plane or fully managed, and how many environments and gateways it counts. Request the current terms in writing before comparing them with Konnect.
Infrastructure for control plane and gateways
Infrastructure is recurring and falls on your side in the self-hosted path, whichever product you pick. WSO2 needs compute for its control plane, gateway, traffic manager and Developer Portal, plus a database and Kubernetes capacity if you use that deployment. Kong Gateway in DB-less mode needs no database, while traditional mode does, so the database line changes with the topology you choose. Size each environment for production, staging and disaster recovery, and price all of them.
Implementation and migration work
Implementation is largely one-time: installing the platform, rebuilding APIs, policies and the portal, and cutting over traffic. Its size depends on how many APIs, custom authenticators, workflows and Kong plugins you need to recreate, and whether you keep your Kong data planes as the gateway layer. Ask any implementation partner for a fixed-scope written plan that lists deliverables and acceptance tests, and reuse exported Kong configuration where possible.
Upgrades, testing and vulnerability response
Upgrades recur on both paths, but the work differs. On WSO2 you receive continuous updates and vulnerability monitoring under the subscription, while you still schedule and test them. On Kong Gateway OSS the open-source line is the 3.9 series, and Kong's version support policy covers only Enterprise, so you must plan your own patching and testing cadence and confirm how long your chosen release line will receive fixes.
Internal engineering time
Engineering time is the cost most often left out of comparisons. Running a self-hosted gateway means someone owns configuration, certificates, monitoring, incident response, backups and access control. Estimate the on-call and platform hours you will commit, and consider whether your team already runs Kubernetes and a database, because WSO2 and self-run Kong both reuse those skills. Treat this as a recurring cost in your model, not a one-time setup task.
What moving to WSO2 API Manager involves
The sequence moves Kong routes, services, plugins and consumers into a WSO2 control plane in a planned order, with Kong data planes kept or retired as a deliberate decision. Effort depends on how many services and custom policies you run, so confirm both before you commit to a timeline.
Inventory Konnect services, routes, plugins and consumers
Your platform or API team lists every Konnect control plane, gateway service, route, plugin, consumer and developer portal asset in use, and notes which plugins are open source and which belong to Enterprise. Konnect metadata, certificates and upstream dependencies go on the same list. The step is done when every API has a named owner and a row in the inventory, and the team agrees which items are in scope for the first wave.
Export gateway configuration with decK
An engineer runs decK against the Konnect control plane to produce a declarative file of services, routes, plugins and consumers, then stores it in version control. The export is checked by diffing it against the live inventory, because some settings or secrets may not appear in the dump. The step closes when the team can regenerate the same file from the repository and nothing is missing from the inventory.
Decide whether Kong data planes stay
The architecture owner chooses whether existing Kong data planes continue to serve traffic behind WSO2, or whether WSO2 gateways replace them. WSO2 can manage third-party gateways including Kong, so a staged option is available, but Kong's open-source edition and Enterprise features differ in what they support. The decision is recorded with the reasons, the security owner signs off on the gateway boundary, and the result feeds the deployment design.
Stand up the WSO2 control plane and gateways
The platform team installs WSO2 API Manager from the extracted packages on premises, or deploys the separate WSO2 API Platform for Kubernetes if the estate runs on Kubernetes, and builds the release with JDK 21 as the repository specifies. Database, identity, TLS and traffic manager settings are configured in a non-production environment first. The step is complete when the Publisher, Developer Portal and gateway health checks pass in that environment.
Map APIs into the Publisher
Each Kong service is recreated as a WSO2 API in the Publisher, with its REST, GraphQL or AsyncAPI definition, endpoints, resources and throttling tiers taken from the inventory. The API owner reviews every mapping against the exported file, and any Kong route that does not translate cleanly is logged as an exception. The step closes when every in-scope API is published to the non-production gateway and each exception has an owner.
Rebuild plugins as WSO2 policies
Each Kong plugin is matched to a WSO2 mediation policy, security control or traffic manager rule, and any gap is either accepted, implemented as a custom policy or authenticator, or removed by decision. Custom policies are written, tested and reviewed like other code. This is usually the largest effort item, so it scales with the number of custom plugins. The step is done when a security reviewer confirms every plugin has an equivalent or an approved exception.
Move the portal, applications and credentials
Developer Portal content, subscriber applications, API keys and OAuth clients are migrated or reissued, and consumers are invited to re-subscribe where credentials cannot be carried over. Secrets move through your secrets manager rather than spreadsheets. The step is complete when test consumers can discover the APIs, subscribe and call them through WSO2 with the expected throttling.
Run parallel traffic and cut over
Traffic is split between Konnect-backed routes and WSO2 routes at the load balancer or DNS layer, with metrics compared for errors, latency and throttling behavior. Each wave of APIs moves only after its rollback path is tested. The cutover is done when all in-scope traffic runs through WSO2, rollback has been rehearsed, and Konnect can be retired on a date the business approves. Confirm the WSO2 support subscription terms before this step.
Questions buyers ask before switching from Konnect
What does moving off Konnect to WSO2 API Manager cost in effort, and who does the work?
The effort is mostly one-time and comes from three areas: inventorying your APIs, policies and plugins, rebuilding them in the WSO2 Publisher, and re-pointing consumers. Software licensing is a separate line. WSO2 API Manager is Apache-2.0 licensed, so the core product carries no license fee, but a WSO2 subscription is an optional recurring cost for support, continuous updates and the licensed distribution for commercial use. Engineers from your team, your platform staff and any implementation partner you hire are paid for their time. Ask any quote to split one-time migration work, infrastructure, and recurring subscription and support costs, and to state which Kong plugins map one-to-one and which need custom work.
How long does a migration from Konnect to WSO2 API Manager take?
Duration depends on the number of APIs, how many Konnect plugins and portal customizations you rely on, how many consumers must be moved, and how much change control your organization requires. Teams with few services and simple authentication typically finish faster than those with many plugins, custom Lua or external identity integration. No timeline figure applies to every environment, so ask for a written schedule tied to a defined scope. Plan parallel running of Kong and WSO2 in staging before any cutover, since consumer credentials and traffic routing usually cause the most delay.
Can an internal team migrate from Konnect to WSO2 API Manager alone?
An internal team can do it if it already runs Kubernetes or VM-based gateways, has someone who understands API lifecycle and OAuth2 flows, and can staff a test environment. Gaps usually appear in WSO2 operations: the Publisher and Developer Portal, the traffic manager, key management and deployment on Kubernetes, which WSO2 offers through a separate API Platform for Kubernetes. A WSO2 subscription can supply vendor support for those areas. DeployOpen can plan, implement, integrate, harden and document a self-hosted deployment under a fixed-scope agreement, or support your team through a retainer. Confirm in writing which parts your staff will own after handover.
Can our existing Kong data planes stay in place if we move to WSO2?
Yes, WSO2 states that one control plane can manage its own gateways and third-party gateways, including Kong, so your Kong data planes can remain in service while WSO2 takes over management. This is the most common reason teams keep Kong. Confirm that the Kong version you run is supported with the WSO2 release you choose, and test the integration path in staging. Note that Kong Gateway 3.9 is the open-source line, and if your data planes are Enterprise, licensing for them stays with Kong regardless of the control plane you choose.
What does a WSO2 API Manager subscription include?
A WSO2 subscription provides expert support, continuous product updates, vulnerability monitoring and access to the licensed distribution for commercial use, according to WSO2's repository. The software itself is Apache-2.0 licensed, so you can build and run it without the subscription, but you then carry patching, security monitoring and support internally. Ask WSO2 for the support hours, response targets, supported versions and the exact terms for commercial use before you sign. Also ask whether your deployment model, self-hosted, hybrid or managed SaaS with its published availability target, changes the subscription terms.
Does Konnect configuration export cleanly with decK for a WSO2 migration?
decK exports Kong configuration with the gateway dump command and produces declarative files in YAML or JSON. Those files cleanly capture services, routes, consumers and plugins for Kong, but they are not a native import format for WSO2 API Manager. Your team or the implementation partner will translate them into WSO2 APIs, resources, policies and subscriptions, and review each plugin for an equivalent. Keep the decK export as the source of truth for the migration, record which settings have no direct match, and run the same test suite against both gateways before cutting over.
What operational work does WSO2 add compared with Konnect?
Konnect runs the control plane for you, while a self-hosted WSO2 deployment makes your team responsible for the control plane, gateways, the database, certificates, upgrades and backups. Plan for upgrades against release notes and for WSO2 API Manager's build requirements, such as JDK 21 for the 4.7.0 release. Monitoring of the publisher, traffic manager and gateways needs to be set up in your own observability stack. Ask any implementer to document these responsibilities, the upgrade procedure, and the backup and restore tests before go-live.
How DeployOpen helps evaluate and implement WSO2 API Manager
DeployOpen can plan, implement and run a self-hosted WSO2 API Manager evaluation or production deployment inside your own cloud accounts, data centers or disconnected networks, with the scope, deliverables and timeline agreed in writing before work starts. The first decision is which deployment model fits your constraints: on-premises from extracted packages, on Kubernetes through the separate WSO2 API Platform for Kubernetes, or a hybrid layout with a control plane and on-premises gateways. Confirm with WSO2 which of these it supports for your target environment and whether your gateways will include third-party gateways such as Kong, since that determines how the control plane is laid out.
Once the topology is chosen, the implementation work covers the Publisher and Developer Portal, the gateway, the traffic manager's throttling policies, the custom authenticators, policies and workflows you need, and the integration with your identity provider and logging stack. DeployOpen can also harden the installation, set up backup and restore for the control plane's data, plan upgrades against each WSO2 release, and document the runbooks your operations team will use. Because WSO2 API Manager 4.7.0 requires JDK 21 to build from source, ask for the build and runtime Java versions to be written into the deployment standard so that later patching does not break the pipeline.
Security testing of the APIs and the gateway is available as a separate fixed-scope piece, and it is worth scoping early so findings can be fixed before cutover. DeployOpen also prepares systems, configuration records and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; your independent auditor or certification body does that work. Quotes follow from the written scope, and DeployOpen does not publish a price list. To compare proposals, ask each provider to itemize planning, implementation, integration, hardening, testing, documentation and any recurring support or upgrade retainer, and to state which of these you would pay for once and which you would pay for each year.
