Migrate from Kong Konnect to Apache APISIX

Traditional mode runs the data plane and control plane together on the same nodes, with etcd as the configuration store. Client traffic arrives on port 9080 and the Admin API listens on port 9180, so the team gets dynamic updates through the Admin API and a single deployment to maintain. This is the closest match to the way Konnect hides the control plane behind a console, but the control plane is now yours to run.

• Replacement for Konnect: Admin API calls and the dashboard replace the Konnect control plane, and you own every backup of etcd.
• Operations: One deployment unit, but gateway nodes need etcd connectivity and Admin API access is a sensitive surface.
• Scaling: Adding gateway capacity also adds control plane load, so capacity planning covers both.
• Air-gapped use: Works inside a disconnected network if the Admin API and etcd are reachable only from internal administrators.
• Network exposure: Port 9180 should never face client networks.

Confirm with the platform team whether they accept etcd and Admin API operations on the same nodes as public traffic.",

Decoupled mode separates the data plane from the control plane, and both share one etcd cluster. Gateways in each zone or environment handle traffic while a smaller set of control plane nodes handles Admin API changes. This split suits organizations that want gateways close to applications without exposing the administrative interface where traffic lands.

• Replacement for Konnect: The control plane runs in your environment as a dedicated tier, which maps more closely to the separation Konnect offers between its console and self-hosted data planes.
• Operations: Two node roles to patch and monitor, plus one shared etcd cluster whose health affects every gateway.
• Scaling: Data plane nodes scale independently of the Admin API tier.
• Air-gapped use: The etcd cluster and both planes must stay inside the disconnected network, and etcd becomes the single point of configuration truth.
• Access control: Restrict Admin API access to the control plane network only.

Confirm the etcd sizing, backup schedule and failover runbook with your database and platform teams before choosing this mode.

Standalone mode runs without etcd. APISIX reads routes, upstreams and plugins from conf/apisix.yaml or conf/apisix.json, checks the file for changes every second, and hot-reloads without restarting. Configuration becomes a versioned file that can be reviewed in a pull request, which fits teams that already manage declarative configuration in Git.

• Replacement for Konnect: Git and CI replace the Konnect console as the source of change, so there is no runtime management UI in this mode.
• Operations: Fewer moving parts, since no etcd cluster needs care, but each gateway holds its own copy of the file.
• Dashboard fit: Confirm whether the APISIX dashboard works with your chosen mode, because it depends on the Admin API.
• Air-gapped use: Often the simplest option for disconnected networks, since nothing outside the host is required at runtime.
• Rollout: Distributing the same file to every node needs a tested process.

Confirm with the team that a file-driven workflow matches how they approve and audit configuration changes.

The right mode depends on who changes configuration, how many environments exist, and whether the network can reach an etcd cluster. A small team with a few services may find standalone easiest, while a platform team serving many applications may need the dynamic Admin API that traditional or decoupled mode provides. The choice is also reversible in part, but moving between modes changes where configuration lives, so plan it before translating decK exports.

• Change frequency: Frequent self-service changes favor an Admin API; reviewed releases favor files.
• Environments: Count development, staging and production clusters and how each one is configured.
• Network posture: Disconnected networks narrow the choice toward standalone or a fully internal etcd.
• Team skills: Confirm who can operate etcd and who owns Git-based change.
• Plugin needs: Verify that the plugins you require behave identically in your chosen mode.

Confirm the final mode in writing before the translation work starts, so the team does not rebuild configuration later.

A small estate usually has a handful of services, a few routes per service and a short list of plugins, most of them authentication, rate limiting and request transformation. Here the translation work is bounded and the cutover can be tested end to end in a single non-production environment. The main effort goes into reviewing the exported configuration by hand, since there are few objects to check and each one matters.

• Translation is short: a decK export with a few dozen objects can be mapped to APISIX routes, upstreams, consumers and plugins by one engineer in a short working session, with a reviewer checking the result.
• Plugin mapping is the main decision: confirm for each Kong plugin whether APISIX provides a built-in equivalent, since APISIX offers more than 100 built-in plugins, and record any gap.
• Operations stay simple: a single APISIX node in traditional or standalone mode may be enough for the traffic, which keeps the number of moving parts low.
• Konnect UI is replaced by hand: with few consumers and routes, a runbook and the APISIX dashboard can cover what the Konnect console showed.
• Cutover is one step: a DNS or load balancer switch with a short rollback window is often practical.

Before you start, confirm that every plugin in use has an APISIX equivalent and that no Konnect-only feature is quietly carrying traffic.

A large estate spreads many services, consumers and plugin configurations across regions, teams and environments. The translation itself grows, but the bigger change is in operations: each region needs its own APISIX data plane, its own etcd cluster in traditional or decoupled mode, and a process for keeping configuration consistent. The Konnect control plane used to handle this centrally, so you now have to design that role yourself.

• Control plane design becomes a decision: choose between traditional, decoupled and standalone modes per region, and plan how etcd clusters are sized, backed up and monitored.
• Configuration pipelines are needed: keep the APISIX configuration in version control and apply it through automation rather than by hand in each region.
• Cutover is staged: move one region or one low-risk API group at a time, with traffic shifted gradually and a rollback path for each step.
• Plugin and identity wiring multiplies: the openid-connect plugin must be configured against your identity providers in every region that uses it.
• Ownership of the platform moves to your teams: define who on-call handles gateway incidents that Konnect previously absorbed.

Ask your team which regions and traffic classes are the most sensitive, and whether any region must stay on Kong until the others are proven.

Kong documents Dedicated Cloud Gateways as fully managed data planes on AWS, Azure or GCP. If you run on these, Kong operates the gateway infrastructure as well as the control plane, so the move to APISIX means taking over both the data plane and the control plane. This adds work that a self-hosted Kong data plane user would not face, because the runtime itself is new to your environment.

• Infrastructure is new to you: you must provision compute, load balancing, TLS certificate handling and scaling in your own cloud accounts or data centers.
• Network paths change: traffic that reached a Kong-managed gateway now reaches your APISIX nodes, so review firewall rules, private connectivity and DNS.
• Capacity needs to be measured: Kong's managed sizing does not transfer, so load test APISIX against your real traffic profile before cutover.
• Monitoring and logs are rebuilt: metrics and access logs that Kong's managed service exposed must be recreated with your own observability stack.
• Vendor-side features stop: confirm which managed-service behaviors you relied on, such as scaling and patching, and assign owners for them.

Ask Kong which Dedicated Cloud Gateway settings you use today, so your target design covers each of them.

A team that already runs self-hosted Kong data planes has the most familiar starting point. The gateway runtime, the traffic patterns and the operational habits are known, and the decK export maps closely to the configuration in use. The steps that shrink are infrastructure and testing, while the steps that grow are the cross-check against APISIX semantics, because Kong and APISIX differ in how they name and structure routes, upstreams and plugins.

• Infrastructure can be reused: the hosts, network paths and certificates used for Kong may carry over, though APISIX has its own ports, such as 9080 for client traffic and 9180 for the Admin API.
• Translation is the main task: map Kong services and routes to APISIX routes and upstreams, and confirm plugin ordering and configuration fields one by one.
• Parallel running is practical: run APISIX alongside Kong with the same traffic mirrored or split, and compare responses and logs.
• Operational tooling needs changes: scripts and dashboards that call the Kong Admin API must be rewritten for the APISIX Admin API.
• Retirement is a separate decision: keep Kong available until the rollback window closes.

Check whether your current Kong data planes use DB-less or traditional mode, because that choice shapes how you export and reproduce the configuration.