Open source API management

Start by inventorying what the commercial gateway actually does, because most migration failures come from policies nobody wrote down. Export every route, upstream, consumer credential, plugin or policy, transformation rule, rate limit, and custom script, and record which consumers depend on each one. Then map each item to one of three outcomes: a built-in capability in Apache APISIX or Kong Gateway (both Apache-2.0 licensed, with APISIX 3.19.0 and Kong Gateway 3.9.4 as the current releases supplied for this page), a custom plugin your team must write and maintain, or a feature that should be dropped or moved elsewhere. Treat enterprise-only features with particular care. Some commercial capabilities, such as certain analytics dashboards, advanced developer portal workflows, or vendor-specific security modules, may have no direct open-source counterpart. Confirm each one in writing with your current vendor and with the open-source project, then test it against your own traffic before you assume it is covered.

Run the new gateway in parallel before any consumer is moved. Mirror or shadow a copy of production traffic to the open-source gateway where your architecture allows it, and compare status codes, latency, header handling, authentication outcomes and rate-limit responses against the commercial gateway for the same requests. Keep the commercial gateway as the system of record during this period so that differences are visible without customer impact. Move consumers in waves, starting with internal or low-risk clients that can tolerate a short fault, and group the rest by owner and dependency rather than by alphabet. Each wave should have a named owner, a defined success check, and a change window agreed with the consumer teams. Keep DNS or routing switches reversible, and keep the commercial gateway configuration, certificates and credentials intact until every wave has run cleanly for an agreed period.

Rollback is a design decision made before the first wave, not an emergency step. For each wave, document how traffic is returned to the commercial gateway, who has authority to trigger it, and what evidence triggers it, such as error rate, authentication failures or latency beyond an agreed threshold. Test the rollback in a staging environment and time it, so the team knows its real duration. Confirm that consumer credentials, API keys and JWT or OAuth configurations work on both platforms during the overlap, because a mismatch in token claims or key formats is a common cause of silent breakage. Finally, schedule decommissioning only after the audit trail of the new gateway has been reviewed, since logs and access records from the old platform may be needed for investigations or compliance evidence after cut-over.

The gateway is one of the few places where access control evidence for API traffic can be captured in one spot, which is why it matters for audits. For a SOC 2 or ISO/IEC 27001 assessment, an auditor will typically want to see who could reach which API, how callers proved their identity, what limits applied, and who changed those settings and when. Apache APISIX and Kong can each be configured to write access logs, record authentication outcomes through their plugin chains, and keep rate limit and route definitions as configuration files or declarative resources. Before the project starts, confirm with the chosen platform's documentation which fields its access logs record by default (client identity, route, status code, upstream and timing), which plugins write to the log and which need explicit configuration, and whether configuration changes are captured in version control or only in the running state. The gap between those answers is where most audit findings come from. Three artifacts carry most of the weight. The first is the access log stream, which should be shipped off the gateway host to a central store with restricted write access so administrators cannot quietly edit it. The second is the authentication record, meaning the key, token or identity provider decision behind each request, including denials. The third is change history for routes, consumers, credentials, rate limit policies and plugin settings. If those settings are managed through Git with reviewed merges, the commit history and approval records become the change evidence. If administrators edit the Admin API or dashboard directly, the platform must log those calls, and you should test that the log entries name the operator. Retention periods are a policy decision, so ask the auditor which period they expect and set the log store to match. DeployOpen prepares these systems, controls and evidence for assessment, but independent auditors issue the assessment and any attestation. Where APIs feed AI systems, the same logs may also matter under the EU AI Act. Article 12(1) requires high-risk AI systems to technically allow for the automatic recording of events over the system's lifetime, and Article 19(1) requires providers to keep those logs for at least six months unless other law provides otherwise. Whether your system is high-risk depends on its use case, so have legal counsel confirm that classification first. If it is, the gateway can record which caller invoked which model endpoint, at what time and with what result, but it will not capture prompt content or model output unless you configure that deliberately and handle the resulting personal data under your privacy obligations. Read the EU AI Act Article 19 text alongside Article 12 to map which events you must record against what the gateway can actually see.

The most useful thing a partner can show you before signing is evidence from work they have already done, so start there. Ask which commercial gateways they have migrated to Apache APISIX or Kong, how many routes, consumers and plugins were in scope, and how they handled the cutover window. Ask for a description of how they mapped existing policies, such as key-based authentication, rate limits and transformation rules, to the target gateway's configuration, and what they found did not translate cleanly. These are questions to ask, not promised answers: a partner's reply should be specific enough that you can check it against your own estate, and a vague answer is itself a finding.

Next, ask how high availability is tested rather than how it is designed. A diagram of the etcd cluster, the gateway nodes and the load balancer is not evidence. Ask whether the partner runs node-failure, etcd-failure and network-partition tests, what the recovery steps are, who runs them, and whether the results are written down and repeated after upgrades. Ask who owns plugin code: whether custom Lua or external plugins are maintained by the partner, by your team, or left for the vendor, who reviews changes, and how upgrades to a release such as Apache APISIX 3.19.0 or Kong Gateway 3.9.4 are tested against your custom plugins before they reach production. Confirm the exact versions your environment will run, since those change.

Ask how the developer portal is supported. Find out whether the portal is a product you deploy and operate, a component the partner builds on, or a separate tool you choose, and who handles its authentication, content and onboarding workflow after go-live. On evidence, ask for a sample of what is delivered at each stage: configuration exports, test reports, runbooks, access control records and any control mapping the partner prepares, along with a clear statement that independent auditors, not the implementer, judge compliance. Finally, ask how handover works: which staff are trained, what runbooks and on-call procedures transfer, how long the partner supports the platform in parallel, and what a *knowledge transfer acceptance* looks like in the written scope. Put each answer into the statement of work so it can be held to account.