Open-source alternative to IBM DataPower API Gateway: the short answer
If your API Connect estate routes live traffic through DataPower appliances or DataPower containers, the main self-hosted replacements are Apache APISIX and Kong Gateway OSS. Either one moves the runtime off IBM hardware and licensing, and in most estates the real work is mapping existing security, rate limiting and transformation policies to the new gateway and cutting traffic over in stages, not rebuilding the platform. Renewal dates, licensing terms and lock-in concerns are the usual trigger, so start by listing which DataPower services, domains and assemblies carry production traffic and which consumers depend on them. The gateway is only one module of API Connect. Its management plane, including the developer portal, product and plan catalog, consumer organizations and analytics, is separate and may stay where it is while the runtime moves, or it may move to a self-hosted control plane at the same time. Decide that split early, because it changes how credentials, subscriptions and API definitions are re-issued. Confirm with IBM which API Connect components your contract covers and which you can run independently of the gateway. Check support windows before you choose a version. Apache APISIX 3.19.0 is the newest release cited for this comparison and is not marked as long-term support, so plan your upgrade cadence around that. The open-source Kong edition has no published support window, while Kong's version support policy covers only Kong Gateway Enterprise. Ask each vendor, in writing, which line you should pin to, how long it receives security fixes and what your own patching obligations become.
Which DataPower capabilities map to APISIX and Kong Gateway OSS
This table maps the main DataPower gateway functions to Apache APISIX and Kong Gateway OSS, with a coverage column for each. Read the coverage column first: where it says confirm with vendor, the supplied facts do not settle the question and the answer should come from the vendor or a proof of concept in your environment. The main takeaway is that routing, authentication and rate limiting map well, while GatewayScript, XSLT and appliance-level features need dedicated design work.
| DataPower capability | Apache APISIX | Kong Gateway OSS | Coverage |
|---|---|---|---|
| API security and authentication | Built-in authentication plugins and openid-connect plugin for Keycloak, Entra ID, Okta and similar providers, supporting PKCE and token introspection | JWT, basic auth, OAuth and ACL plugins in the README; confirm which OAuth2 flows are needed | Mapped; confirm flow coverage in a proof of concept |
| Rate limiting | Traffic control plugins for per-consumer and per-route limits, with configuration held in etcd | Rate limiting plugin works in DB-less mode with local policy only; cluster-strategy limits need traditional mode with a database | Gap for Kong cluster-wide limits; confirm with vendor |
| Transformation and mediation | Request and response rewrite plugins; custom logic in Lua, Java, Go, Python or WebAssembly | Transformation plugins cover common header and body edits; custom logic needs a custom plugin | Partial; XSLT and GatewayScript equivalents need custom plugin work |
| TLS and certificates | TLS termination and SNI support for HTTPS; confirm certificate lifecycle tooling and HSM integration | TLS termination through declarative config; confirm certificate rotation and HSM integration | Confirm with each vendor and your security team |
| Logging and analytics hooks | Observability plugins for logs and metrics; confirm export targets against your SIEM | Logging plugins for common sinks; confirm export targets and analytics depth | Confirm integration with existing SIEM and analytics |
| Routing and load balancing | Dynamic routing with hot reload of routes and plugins without restarts | Routing, load balancing and health checking in the README; DB-less config kept in Git | Mapped |
| Kubernetes deployment | APISIX Ingress Controller, with a documented release line for 2026 | Kong Ingress Controller under Apache-2.0, installed with Helm or manifests | Mapped; confirm version pinning for your cluster |
| FIPS and appliance-level features | Not a DataPower appliance equivalent; confirm FIPS validation and hardware options with the vendor | Not a DataPower appliance equivalent; confirm FIPS validation with Kong and your build | Confirm with vendor and assessor |
Apache APISIX or Kong Gateway OSS: when each fits
Apache APISIX is an Apache-2.0 licensed gateway and Kubernetes ingress controller built on NGINX and etcd. Its configuration lives in etcd, so routes and plugins change at runtime without a restart. That suits teams that need frequent dynamic changes across many services and are prepared to run an etcd cluster as a stateful dependency. The documentation describes three deployment modes: traditional (data and control plane together), decoupled (separate data and control planes sharing one etcd cluster) and standalone (no etcd, configuration read from a YAML or JSON file or the Admin API).
- Plugin coverage: More than 100 built-in plugins cover authentication, security, traffic control, observability and AI gateway functions. Map each DataPower policy to a named plugin before you commit.
- Identity: The openid-connect plugin works with Keycloak, Auth0, Microsoft Entra ID, Google and Okta, and supports authorization code, client credentials, token introspection and PKCE flows.
- Custom logic: Plugins can be written in Lua, or through plugin runners in Java, Go and Python, or as WebAssembly. Match the language to the skills you already have.
- Operations: Plan for etcd backup, quorum and upgrades in traditional or decoupled mode. Standalone mode removes etcd but gives up runtime Admin API changes as the main workflow.
- Support: The downloads page does not mark any release as long-term support, so confirm your upgrade cadence and patch ownership in writing.
Check which DataPower custom logic must be ported and whether each piece has a plugin or a runner in your chosen language.
Kong Gateway is Apache-2.0 licensed and describes itself as an API, LLM and MCP gateway extended through plugins. Its DB-less mode needs no database and reads declarative configuration files that can be kept in Git, which fits teams that want code review and rollback for every route change. The Kong Ingress Controller, also Apache-2.0, covers Kubernetes, and decK exports and syncs declarative configuration with open-source and Enterprise Kong Gateway.
- DB-less and decK: Keep configuration in Git and apply it with decK. The Admin API is read-only in this mode.
- Hybrid mode: Separate control and data planes are supported, but the open-source line has constraints you must test.
- Release line: The newest open-source release line on GitHub is 3.9, with 3.9.4 published October 12, 2026. Kong's version support policy covers only Enterprise, so no support window is published for OSS.
- Database-dependent plugins: Cluster-strategy rate limiting and OAuth2 need traditional mode with a database. Confirm this against your rate limiting and token policies.
- Enterprise boundary: Fully self-hosted gateways with a local control plane and data plane are part of Kong Gateway Enterprise, and Kong Gateway 3.10 removed the unlicensed free mode from Enterprise. Ask Kong which features you need that sit only in Enterprise.
Confirm the exact plugin set, the support model for the 3.9 line and the Enterprise features your policies depend on before design.
The choice turns on where configuration should live and who edits it. etcd gives APISIX fast runtime changes but adds a stateful cluster to operate. Kong's DB-less mode avoids a database and fits Git-driven change control, but it limits some features and changes happen through file sync rather than live edits. Plugin language fit matters too: a Lua-literate team will find APISIX natural, while a team with Go or Java services may prefer the plugin runner route. Ask both vendors to map your top ten DataPower policies to their plugins.
- Change model: Live Admin API changes favor APISIX. Git-reviewed files favor Kong DB-less.
- Operations load: etcd backup and quorum for APISIX traditional or decoupled mode; database operations for Kong traditional mode.
- Feature gaps: Test rate limiting, OAuth2 and transformation policies against your real consumer traffic.
- Commercial edge: Kong's commercial line begins where self-hosted control planes start; APISIX's open-source build is the full gateway.
- Skills: Match plugin language to your team.
Run a proof of concept with your three most complex DataPower policies on each candidate before you choose.
Two other open-source gateways are worth a short look if neither APISIX nor Kong fits your model. Each has a licensing boundary you should read before adopting. Both are relevant when you also want a developer portal or a full API management control plane, not just a gateway.
- Tyk Gateway: Licensed under MPL-2.0 except code in the ee folder, which is commercial. The management control plane, dashboard GUI and developer portal come with Tyk Self-Managed or Tyk Cloud under a commercial license.
- Gravitee API Management: Apache-2.0 licensed with a gateway, management backend, console UI and developer portal. Some features require a Gravitee Enterprise License.
- Portal needs: If consumers need a self-hosted portal, check whether it is in the open-source build or the licensed tier.
- Feature parity: Map each DataPower feature against the open-source build, not the marketing list.
- Ask for: The exact list of features under each license before you shortlist.
Confirm which features your consumers depend on, such as the portal and analytics, are available under the license you plan to run.
How to move policies and consumers off DataPower without an outage
This sequence moves APIs, policies and consumer credentials from DataPower-backed API Connect to a self-hosted gateway in stages, so each step can be checked and rolled back before the appliance is retired.
Inventory APIs, products and plans
The API platform owner exports a list of every API, product, plan, consumer organization and application from API Connect, along with the gateway each one is published to. Include which APIs use JWT, OAuth, client certificates or basic auth, and which carry rate limits or quotas. Confirm the list against the live catalog, not only the design documents. The step is done when every production API has a row with its owner, traffic pattern and security requirements, and the team has signed off the list.
Export OpenAPI definitions and gateway artifacts
The API engineers export the OpenAPI definition for each API and keep the assembly policies, gateway scripts and property settings as separate source files. Store these in version control with the owner and date recorded. Check that the exported definitions match what the DataPower gateway actually serves by comparing sample requests and responses. The step is done when each API has a versioned definition and a copy of its gateway logic that a reviewer can read without access to the appliance.
Map each policy to a plugin or custom code
For each assembly policy and gateway script, the architects decide whether the target gateway covers it with a built-in plugin, needs configuration, or requires custom code. Authentication, rate limiting and header transformation usually map to plugins, while XSLT, complex message transformations and custom script logic may need rewriting. Record any behavior with no equivalent as a gap with an owner. Confirm each mapping against the target gateway's documentation for the exact version you will run. The step is done when every policy has a target and every gap has a decision.
Build target routes as declarative config
The platform engineers create routes, upstreams, consumers and plugins in the target gateway using standalone or declarative files stored in Git, such as the file-driven mode of the chosen gateway, rather than building them by hand in a console. Each change goes through review, and the deployment pipeline applies the same files to test and production. Confirm the deployment modes and admin interfaces your chosen gateway offers for production. The step is done when a test environment built only from the repository answers the same requests as the DataPower path.
Run parallel traffic with canary or DNS cutover
The operations team sends a small share of traffic to the new gateway through a weighted canary at the load balancer or a DNS change for low-risk APIs, while the DataPower path stays live. Compare status codes, latency, error rates and authentication outcomes between both paths using the monitoring stack in place. Increase the share in steps, and keep the old route ready to receive all traffic. The step is done when each API has served full production traffic through the new gateway with no unexplained differences in its metrics.
Keep consumer credentials and certificates valid
The security team confirms that existing client IDs, secrets, JWT signing keys, client certificates and their trust chains work on the new gateway before any consumer is moved. Where the token issuer or certificate authority stays the same, consumers need no change. Where credentials are stored in API Connect's consumer records, export or re-issue them under a controlled process and notify consumers in advance. Check the certificate expiry dates and renewal owners. The step is done when a test call from each consumer type succeeds on the target gateway.
Hold a rollback window before decommissioning
The owners keep the DataPower route and its configuration intact for an agreed rollback period, with a documented procedure to return traffic in one change. Agree the length of that window in writing with the business owners, since no duration is set by this guide. Monitor for consumer-reported issues and for errors that only appear under load or at month-end. The step is done when the window closes with no open rollback triggers and the decision is recorded.
Decommission the appliance and archive evidence
After the rollback window closes, the platform team removes the DataPower routes, revokes unused certificates and keys, and archives the exported definitions, mapping decisions, test results and cutover records. Confirm with your compliance owner which records must be retained and for how long, and whether any change record is needed for an assessment. The step is done when the appliance no longer serves production traffic and the archive can be retrieved by an auditor or reviewer.
Running the new gateway beside API Connect during the transition
A DataPower-to-open-source move rarely happens in one cutover. API Connect often stays as the management plane while traffic shifts gateway by gateway, so the two gateways must agree on routes, identity, and telemetry for the period they run side by side. The cards below name the risk at each seam and the check to run before shifting traffic.
Management plane stays the source
While API Connect remains the publisher and catalog, every change made in the new gateway can drift from what the portal advertises. Decide which system owns each API definition and product plan for the whole transition, and record that decision in writing. Check that a route published in API Connect resolves to the same upstream and policy set on both gateways before any consumer is pointed at the new one.
One hostname, two gateways
Running DataPower and the new gateway behind one hostname lets you move consumers without changing their endpoints. Use weighted routing at the load balancer or DNS layer, starting with a small share of non-critical traffic. Confirm that headers, TLS termination, and client certificate handling match on both paths, because a difference there tends to surface only for a subset of consumers.
Syncing definitions with decK
Kong's decK tool exports configuration with deck gateway dump and syncs declarative files to open-source Kong Gateway, so definitions can live in Git. Map each assembly policy to a route, service, or plugin, then diff the exported file against what API Connect publishes. Scripted syncs should run from the same pipeline every time, so a manual edit on one gateway does not go unnoticed.
Consistent analytics and logging
API Connect analytics and DataPower log targets feed dashboards that consumers and auditors may already rely on. During coexistence, both gateways should emit fields with the same meaning, such as API name, consumer identifier, status, and latency, so trends do not break at the cutover. Confirm that log retention and access controls on the new pipeline match the policy that applies to the existing logs.
Identity integration across both paths
Clients authenticating with OAuth tokens or API keys must get the same result from either gateway. Verify that the new gateway validates tokens against the same issuer, audience, and signing keys, and that JWT claims needed for authorization are present. Test revocation and key rotation on both paths, since a token that is accepted by DataPower but rejected by the new gateway will look like a consumer outage.
Rate limits and quotas in step
Rate limits enforced by DataPower and by the new gateway can differ in counting window, scope, and whether counters are shared across nodes. If both gateways enforce a limit during coexistence, a consumer may hit one and not the other. Document the limit that applies to each consumer during the transition, and test a burst against both paths before shifting that consumer's traffic.
How appliance and container sizing changes the run cost
The run cost of a DataPower replacement depends less on the gateway software than on what sits under it and around it. On the DataPower side, check whether your estate pays for appliance hardware, DataPower software licenses on your own virtual or container hosts, or an API Connect subscription that bundles gateways, and what renews each year. On the open-source side, the recurring costs are the compute that runs the gateway nodes, the Kubernetes or VM platform they sit on, etcd or the database that holds configuration, and monitoring and log storage. Ask the vendor or your account team to split the current annual figure into these lines, so the comparison is between like components rather than between one invoice and a server bill.
Sizing drives most of the variable cost. Gateway nodes are usually scaled by request throughput, payload size, TLS termination, and how many plugins or policies run per request, so a replacement sized by request counts from a load test will differ from the appliance count you have today. Plan the test against your own traffic profile and record results per node. One-time costs include policy mapping from assembly and DataPower services into APISIX or Kong configuration, test automation, parallel running during cutover, and training. Recurring costs include node capacity, platform upkeep, certificate and secret rotation, upgrades, and any support subscription you choose. Shared etcd or database clusters that serve several environments change the arithmetic, so state whether each environment gets its own.
When you request a written quote from DeployOpen or any implementation partner, ask for the scope split by one-time work and recurring operations, with the assumed traffic profile, node count per environment, and the Kubernetes or VM platform named. Ask which parts are fixed-scope and which are retainers for upgrades and testing. Confirm with Apache APISIX or Kong the license and support terms for the edition you plan to run, including whether the Kong pricing page features you need, such as self-hosted control planes, sit in a commercial tier. Ask for an exit estimate too, covering what it costs to return to the current platform if the pilot fails, so the business case reflects reversibility.
Questions buyers ask before replacing DataPower
Can our team replace DataPower without outside help?
Yes, if you already have engineers who run NGINX, Kubernetes or similar infrastructure and can own gateway configuration as code. The deciding factors are how many APIs and policies you run, how much custom assembly logic sits in DataPower, and whether your team can cover security review, testing and on-call during cutover. Many organizations use outside help for the parts they have not done before, such as policy mapping or hardening. DeployOpen plans, implements, hardens, documents and supports self-hosted gateways in your own environment under a fixed-scope written agreement, and offers retainers for ongoing upgrades. Start with an inventory of skills and of every policy in use, then decide which parts to staff internally.
How long does a gateway migration take and what drives it?
The duration depends mostly on scope, not on the gateway product itself. The main drivers are the number of APIs and environments, the number of policies that need custom mapping, the number of consumers that must move or be notified, and how much testing your security and API owners require before cutover. Teams that run DataPower in several domains or with many gateway scripts usually need more time for validation than teams with a small set of standard policies. No duration can be fixed until the inventory is complete. Ask for a timeline in the written scope that lists each phase, the owners who sign off and the testing criteria, and check it against your change calendar.
What does the migration cost and which components are paid for?
Costs fall into four groups: software licenses, infrastructure, staff effort and implementation services. Apache APISIX and the Kong Gateway open-source edition are licensed under Apache-2.0, so their software carries no license fee. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane belong to the commercial Kong Gateway Enterprise offering, so confirm which edition you need before you size anything. Infrastructure, staff time, testing, and any implementation or retainer work recur or are one-time depending on the plan. Ask any vendor or partner for a quote that separates one-time work (mapping, testing, cutover) from recurring work (hosting, upgrades, on-call support).
Does Kong OSS or APISIX cover our rate limiting and OAuth2 needs?
Both cover the common cases, but the details decide it. The Kong Gateway README lists rate limiting, JWT, basic auth, OAuth and ACL plugins. In Kong's DB-less mode, database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are not available, so those features require traditional mode with a database. APISIX has more than 100 built-in plugins for authentication, security and traffic control, and its openid-connect plugin supports authorization code, client credentials, token introspection and PKCE flows with providers such as Keycloak, Microsoft Entra ID and Okta. Map each DataPower policy to a named plugin, then test rate limits and token flows against your real identity provider. Confirm any gap before you commit.
Will existing API consumers need new credentials?
It depends on where the credentials were issued. If API Connect issued consumer keys or secrets from its own consumer catalog, those values usually have to be re-issued or mapped to the new gateway. If consumers obtain tokens from an external identity provider, you may be able to keep the same clients and only change the gateway that validates the tokens. Plan an overlap period where old and new paths both work, and confirm with each consumer team how they store and rotate credentials. Also check whether any consumer depends on DataPower-specific response headers or error formats. Your inventory of consumers and their authentication methods is the input that answers this question.
Is there a support window for the open-source editions?
Not a published one for the open-source editions, so you need to plan for that. Kong's version support policy applies only to Kong Gateway Enterprise. The newest open-source Kong Gateway line on GitHub is 3.9, with releases 3.9.0 on December 13, 2024, 3.9.1 on June 4, 2025 and 3.9.4 on October 12, 2026, while Enterprise reached 3.16 on September 15, 2026. The APISIX downloads page lists 3.19.0 from September 28, 2026 and does not mark any release as long-term support. Check each project's current policy before you choose a version, and budget for upgrades either in-house or under a retainer. Kong's version support policy is the place to start.
What does the work need from our staff and other teams?
Expect demand from four groups: platform engineers who run the gateway hosts, Kubernetes or VMs; security and identity teams who approve authentication and certificate handling; network teams who manage routing and firewall rules; and API owners who validate behavior. Data-plane choices shape the load. APISIX in traditional or decoupled mode depends on an etcd cluster, Kong in traditional mode depends on a database, and DB-less Kong keeps configuration in declarative files that can live in Git. Also assign someone to own change control, backups and on-call. Ask your partner to name the roles the engagement assumes you will fill before work starts.
Where DataPower migrations usually stall
Most DataPower replacements slow down on the same handful of issues, and they tend to surface late, after the routes already work. Each card below names one risk, what to check in your own estate, and the mitigation to plan for before cutover.
Undocumented gateway scripts
DataPower services often carry GatewayScript or XSLT logic that nobody has documented since the original build. Before migration, inventory every script, map what it reads and writes, and list the calls it makes to backends. Treat each script as a requirement to reproduce in APISIX or Kong plugins, or to retire on purpose with the owner's sign-off. Illustrative: a header rewrite buried in a transform that drops a field consumers depend on.
Certificate and key handling
DataPower keeps TLS certificates, keys and crypto profiles in its own certificate store, often shared across domains. Gateway replacements expect those assets to be loaded through their own configuration, so a missing intermediate chain or an unexpected key format can block cutover. Confirm where each key lives, who holds the private material, how rotation is done today, and how the new gateway will load and renew each certificate.
Consumer credential re-issuance
Moving gateways rarely keeps existing API keys, client secrets or OAuth clients intact unless the migration plans for it. Consumers may need new credentials, updated endpoints or changed token issuers, and each change has to be coordinated with application owners. Build an inventory of consumer applications, decide whether credentials are migrated or re-issued, and schedule a dual-run window so no integration breaks silently.
Database-dependent plugins in Kong DB-less mode
Kong Gateway in DB-less mode reads declarative files and has no database, but some plugins, such as cluster-strategy rate limiting and OAuth2, need traditional mode. If your DataPower policies depend on shared rate counters or token storage, the topology choice changes the architecture and the operating burden. Confirm which policies need shared state before choosing between DB-less and traditional deployment.
Skills gaps in Lua and etcd operations
APISIX custom plugins are written in Lua, or in Java, Go and Python through plugin runners, and APISIX uses etcd as its configuration store. Teams that know DataPower's XML and GatewayScript may have no one who can debug a Lua plugin or operate an etcd cluster. Plan training or hire for those skills, or prefer built-in plugins where they meet the requirement. Ask the vendor or partner who will own these components after go-live.
Unclear support model ownership
Open-source gateways are supported by community projects, while enterprise editions and subscriptions are sold separately, so ownership of incidents and patches is easy to leave vague. Kong's version support policy covers only Kong Gateway Enterprise, so the open-source edition has no published support window. Write down who triages security fixes, who applies upgrades, and which subscription, if any, covers each gateway version in production.
When keeping DataPower or upgrading API Connect is the better call
Keeping DataPower in place is often the right interim call when the support runway is short. A move to a self-hosted gateway needs a full cutover, consumer re-onboarding and new security evidence, and that work may not finish before your API Connect release loses support. Confirm the end-of-support date for your exact API Connect and DataPower firmware versions in writing with IBM, then compare it with your change freeze windows. If the date arrives first, run the supported upgrade as an interim step and migrate in waves afterward. Check the patch commitment of your target too: the APISIX downloads page does not mark any release as long-term support, and Kong's version support policy covers only Kong Gateway Enterprise, so ask for the open-source support terms before you set a date.
Certified appliance requirements are the second reason to pause. Where DataPower forms part of a hardened or validated configuration that your auditor has already accepted, replacing it with software on containers or virtual machines changes the control evidence, the system boundary and possibly the assessment scope. Confirm with your auditor before any build starts whether a software gateway is an acceptable substitute, which hardening baseline applies to the image and host, and how cryptographic module validation is shown for TLS termination. DeployOpen prepares systems, controls and evidence for an assessment, but the independent auditor or certification body decides what is accepted. If the answer is no for some flows, keeping the appliance for those regulated paths while moving lower-risk APIs first is a workable split.
How DeployOpen scopes and delivers a DataPower replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure, so a DataPower replacement is handled as a fixed-scope engagement. We start with the written scope, then build and test the gateway in your environment before handing it over with documentation your team can run.
How we scope
- We inventory the DataPower services, domains, policies and consumers that your API Connect estate depends on today.
- The written scope names which gateway option is in play, such as Apache APISIX or Kong Gateway, and which policies are in or out.
- Deliverables, timelines and responsibilities are agreed in writing before any build work starts, and the quote follows from that scope.
How we build
- We map each security, rate limiting and transformation policy to the target gateway's plugins or configuration, and record every gap.
- We deploy the gateway in your cloud account, data center or air-gapped network, sized to the traffic profile agreed in the scope.
- We test routing, authentication, throttling and error behavior against representative consumer traffic before any cutover is approved.
How we hand over
- You receive configuration kept as code, with the policy mapping, deployment steps and known gaps documented for your team.
- We walk your platform and security staff through operations, including backup, upgrades and certificate rotation for the chosen gateway.
- Compliance evidence, such as configuration records and test results, is prepared for your assessors, who issue any audit reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Security testing of the new gateway and its APIs can be scoped separately, including authentication and access control checks.
- Ask us to confirm the gateway version support window and upgrade path against the vendor's current published policy before you sign.
