Migrate from Apigee to Kong Gateway

How do you migrate Apigee proxies to Kong Gateway without a big-bang cutover?

You migrate Apigee proxies to Kong Gateway without a big-bang cutover by running both gateways side by side, moving one API at a time, and shifting client traffic in stages while the Apigee proxy stays live as the fallback. This matters most when an Apigee contract is up for renewal, when Apigee Edge for Private Cloud reaches its June 30, 2027 end of life for version 4.53.01, or when data residency or lock-in concerns push the organization toward a self-hosted gateway. The work is usually done by the platform or API team that already owns the gateways, with an implementation partner handling mapping, plugin work and cutover runbooks. Effort depends mainly on how many proxies carry custom JavaScript, Java callouts or shared flows, and on how many consumers must be moved, so the reader should inventory those before agreeing on a timeline. Kong Gateway OSS is licensed under Apache-2.0, and its newest open-source line is 3.9 (3.9.4 is the latest release listed on GitHub). Plan for that support posture: the open-source edition has no published support window, while newer features and version support ship in Kong Gateway Enterprise. Confirm with Kong which security fixes will reach the 3.9 line before you commit to a long-running production baseline.

A practical sequence starts with a pilot: pick one low-risk, read-heavy API, rebuild its routing and policies as a Kong service and route, and run it in a DB-less or hybrid environment managed through decK files kept in Git. Use deck gateway dump to capture the Kong state you have built and diff it against your reference configuration before each sync. Route a small share of traffic to Kong at the load balancer or DNS layer, compare latency, error rates and authentication outcomes against Apigee, and keep the Apigee proxy deployable for rollback. Once a proxy behaves identically across its consumers, move the next one. Expect rate limiting and OAuth2 to need careful review, since cluster-strategy rate limiting and OAuth2 depend on a database and so require traditional mode rather than DB-less deployment. Each Apigee policy that has no direct Kong plugin needs either a custom plugin or a redesign in the upstream service, so flag those early and decide them per API. Ask your implementation partner to put the migration plan, rollback criteria and sign-off steps in writing before work starts.

Which Apigee capabilities map to Kong Gateway, and which need rework

This table compares common Apigee proxy, policy, environment and analytics capabilities with their Kong Gateway equivalents. Read each row as clean (a direct Kong concept or open-source plugin), needs rework (rebuilt as a plugin, script or declarative config), or gap (handled by another tool or a Kong Enterprise feature to confirm).

Apigee capability	Kong Gateway equivalent	Status	What to check
API proxies and base paths	Services and routes, defined in decK files or the Admin API	Clean	Map each proxy base path to a route and each target endpoint to a service upstream.
Target endpoints and load balancing	Services, upstreams and targets with health checks	Clean	Confirm health check thresholds and load balancing mode match the Apigee target server setup.
Verify API key and OAuth policies	Key-auth, JWT, basic auth and OAuth plugins	Needs rework	Confirm which OAuth2 flows you use, since OAuth2 needs traditional mode with a database.
Spike arrest and quota policies	Rate-limiting plugin	Needs rework	Cluster-wide limits depend on database-backed mode, so check your topology before cutover.
Mediation policies (assign message, JavaScript, XSL)	Request and response transformer plugins, or custom plugins in Lua or another supported language	Needs rework	Each custom JavaScript or XSL step must be rewritten and tested against the same payloads.
Shared flows and reusable policies	Reusable plugin configuration through decK templates or Git-managed files	Needs rework	Copy common settings into shared plugin definitions rather than duplicating them per route.
Environments and config promotion	Separate control planes or decK files per environment, promoted through Git	Clean	Define one decK state file per environment and gate changes through review.
Analytics and developer portal	Separate tools such as Prometheus, Grafana, or a self-hosted developer portal	Gap	Apigee analytics and portal features are not part of the open-source gateway; plan these as separate projects.

What data and integrations move, and which exports you can rely on

Moving from Apigee to Kong Gateway involves five kinds of data: proxy definitions, the running gateway configuration, consumer credentials, backend connections and the developer-side records that sit outside the gateway. Each has a different export path and a different level of confidence. Work through them in this order so that the inventory is complete before any traffic moves.

Proxy bundles as the inventory

Apigee proxy revisions are your starting inventory because they hold the flows, policies, target endpoints and shared flow references that the new gateway must reproduce. Export each deployed revision as a bundle zip before you change anything in Apigee, and store the exports in version control. Expect to translate these bundles by hand into Kong services, routes and plugins. The export steps are covered in the how-to page on exporting data from Apigee under this hub.

Admin API as a read path

In DB-less mode, Kong exposes a read-only Admin API, so you can query what the gateway actually loaded and compare service, route and plugin counts with your Apigee inventory after each sync. It does not replace the declarative files as the source of truth. Confirm which Admin API endpoints your chosen deployment topology exposes and which network paths can reach them from your CI runners. Database-dependent plugins only run in traditional mode, so check that before you settle on a topology.

Consumers and credentials to reissue

Assume that app keys, client secrets and OAuth or JWT credentials need to be reissued unless you confirm otherwise with your Apigee administrator. Kong models these as consumers and credential objects that must be created or loaded again in the target. Where stored secrets are hashed or unavailable for export, each client application will need a new secret and a scheduled cutover. Ask what each credential type can export and whether any secret can be reused before you promise developers continuity.

Upstream backends and certificates

Target endpoints, backend URLs, TLS client certificates and trust chains from Apigee must be recreated as Kong services and certificate objects. Review settings such as host headers, SNI, mutual TLS and timeouts for each target, since they do not carry across automatically. Inventory keystore and truststore entries with their expiry dates and the hosts that use them. Confirm with each backend owner that the new gateway network can reach those endpoints, and keep private keys out of Git repositories.

What decK dump and sync cover

The decK tool exports and syncs gateway configuration, including services, routes, plugins and consumers, so those files can be reviewed and kept in Git. It does not move developer accounts, portal content, app registrations or analytics history from Apigee. Plan to keep Apigee analytics available for reporting during the overlap period, and rebuild developer onboarding as a separate workstream. Check the decK documentation for the entity types supported by your Kong Gateway version.

How Apigee policies become Kong plugins and where custom plugins are needed

Most Apigee policy logic maps to Kong through plugins attached at different scopes, not through a one-to-one policy translation. Kong plugins can be enabled globally, per service, per route or per consumer, so the scoping decisions you make in an Apigee proxy's conditional flows and shared flows become decisions about where each plugin is attached. A shared flow that applies to every proxy usually becomes a plugin on the relevant services, while a conditional flow step that only runs for certain paths becomes a plugin on specific routes. Quota and spike arrest policies have the closest counterpart in Kong's rate limiting plugin, but the limits, counters and windows need to be re-stated and tested, since the rate limiting plugin's cluster-strategy option depends on a database. For OAuth and API key validation, the equivalents are Kong's OAuth2, JWT and key-auth plugins, and you should confirm with your security team which of these matches the token format and consumer model you already use. The deployment topology decides which of these plugins are available at all. In DB-less mode, Kong reads its configuration from declarative files that can live in Git and needs no database, but the documentation notes that database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are only supported in traditional mode. Before you commit to DB-less, list every Apigee policy that depends on shared state, such as quotas shared across nodes or OAuth token stores, and check it against the plugin's documented requirements. That check determines whether your gateway runs in DB-less or traditional mode, and it should be settled before you write any declarative configuration with decK. Apigee policies with no direct plugin equivalent, such as custom JavaScript, Java callouts, or specialized message transformation logic, need a custom Kong plugin written in Lua or Go, or they move to an upstream service. Plan this work as a separate inventory item with its own testing, and ask the team that owns your Apigee proxies to tag each policy as mapped, custom plugin or redesign. Treat any policy you cannot map as a risk to be signed off, not as something Kong handles by default.

What the Apigee to Kong migration sequence looks like, step by step

The sequence moves Apigee proxies into version-controlled Kong configuration in stages, so each environment is proven on Kong before Apigee traffic is removed. Every stage ends with a written output that the next stage depends on.

Inventory proxies, products, apps and policies
Your team lists every Apigee API proxy, shared flow, API product, developer app, key and target server in each environment, and records which policies each proxy uses in its request and response flows. A DeployOpen engineer can help with the audit if the scope is agreed in writing first. The output is a policy map that lists each Apigee policy, its Kong equivalent (a built-in plugin, a custom plugin or a gap to resolve), and the consumers that depend on it. The step is done when the business owners have signed off on the list of APIs in scope.
Export proxy bundles and settle the policy gaps
Export each proxy revision as a bundle so the original logic is preserved outside Apigee, then review the policy map for Apigee policies that have no direct Kong plugin, such as complex JavaScript, Java callouts or message transformations. Decide for each gap whether to rewrite it as a custom Kong plugin, move the logic into the upstream service, or accept the change with the API consumer. Confirm early which Kong features you need, because some plugins that depend on a database are only available in traditional mode, and the Enterprise features you may want are commercial. The output is a gap register with a decision and owner for each item.
Build a pilot API on Kong and store it in Git
Pick one low-risk API and define it as Kong services, routes, consumers and plugins in a declarative file. Run it on a single Kong node in DB-less mode for a simple proof, or in traditional mode if the design needs database-backed plugins. Use decK to sync the file to the node and check the result with a dump. Keep the file in a Git repository with review rules so that every change is tracked. The output is a Git repository of declarative files and a test evidence pack showing that the pilot routes, authentication and rate limits behave as the Apigee proxy did.
Run Kong in parallel with traffic splitting or mirroring
Place Kong in front of the pilot API with a traffic split or request mirroring, so a share of live calls goes through Kong while Apigee continues to serve the rest. Compare status codes, latency, headers and payloads between the two paths, and record each deviation with its cause. Confirm that analytics and logging on the Kong side capture the fields your operations team and auditors use, since Apigee's own analytics will not follow the traffic. The output is a parallel-run report with each difference classified as fixed, accepted or blocking.
Cut over one environment at a time
Move the same declarative files through development, test, staging and production in that order, with a rollback path defined for each environment before its cutover. Change DNS or the upstream routing to Kong only after the previous environment has passed its checks. Keep Apigee proxies deployed and reachable during the cutover so traffic can be returned to Apigee quickly. The output is a signed cutover record for each environment that names the change, the test evidence reviewed, the approver and the rollback steps.
Decommission Apigee after a rollback window
After production has run on Kong through an agreed rollback window, stop routing traffic to Apigee, export final configuration and audit logs for retention, and remove the Apigee runtimes, proxies and related credentials that are no longer needed. Check which obligations still apply to the exported data and logs before deleting them. Revoke developer keys and portal access that no longer have a purpose. The output is a decommission record listing what was removed, where the retained exports are stored and who approved the closure.

Which Kong deployment mode fits your Apigee setup

DB-less mode runs Kong Gateway without a database. The node reads its entire configuration from declarative files, which can live in Git and move through the same review process as application code. The Admin API is read-only, so changes go through files and a sync tool rather than through live edits on the node. This suits teams that already manage infrastructure as code and want an auditable record of every route and plugin change.

Configuration in Git: Services, routes, consumers and plugins are described in files that you review, approve and roll back like any other code.
Read-only Admin API: Nodes cannot be changed by hand, which reduces configuration drift between environments.
No database to run: You avoid operating a PostgreSQL cluster for the gateway itself.
Plugin limits: Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are not available in this mode, so Apigee policies that depend on shared state need a different design.

Check which Apigee quota and OAuth behaviors you rely on before you commit to this mode, and confirm the current plugin list in Kong's deployment topologies documentation.

What drives the cost and duration of an Apigee to Kong migration

This table lists the factors that change the effort and cost of moving Apigee proxies to Kong Gateway, with why each one matters and how to keep it under control. Read it as a checklist for a written scope, since most of the variation between two migrations comes from these drivers rather than from the gateway itself.

Driver	Why it changes effort or cost	How to keep it down
Number of proxies and shared flows	Each proxy needs its routes, upstreams, plugins and tests rebuilt, and shared flows get reused across many proxies, so one shared flow can touch many services.	Inventory every proxy and shared flow first, retire unused ones, and group proxies that share a pattern so they migrate as one batch.
Custom policies (JavaScript, Java callouts, Python)	Apigee JavaScript and Java callout logic has no direct Kong equivalent and must be rewritten as Kong custom plugins, usually in Lua, Go or another supported plugin language, which needs its own build, test and support path.	Classify each custom policy as replace with a stock plugin, move to an external service, or write a custom plugin, and only fund the last group where no other option fits.
Authentication and consumer volume	OAuth flows, API key issuance, JWT validation and app-level quotas must be recreated, and consumer records and credentials may need migration or reissue with developer communication.	Confirm which credential types are live, decide whether to reissue keys or import them, and plan a window for developers to rotate credentials.
Environments and topologies	Dev, test and production each need their own Kong configuration, and the choice between DB-less and traditional mode, or hybrid control and data planes, changes what must be run and monitored.	Standardize one declarative configuration per environment in Git with decK, and choose a topology that matches the team's operating skills before building anything.
Rate limiting and plugins needing a database	Cluster-based rate limiting and OAuth2 depend on database-backed traditional mode, which changes the infrastructure to run and the redundancy to design.	List every Apigee quota and check it against Kong's documented plugin behavior for each deployment mode before choosing the topology.
Analytics and developer portal dependencies	Apigee analytics dashboards and its integrated developer portal do not move with the proxies, so reports, documentation and app registration need separate tools and build work.	Decide early whether logs and metrics feed an existing stack, and whether the portal is replaced by a separate product or existing internal documentation.
Compliance evidence needs	Assessors may ask for change records, access logs, configuration history and proof of testing for each cutover, which adds documentation work beside the technical build.	Keep configuration in version control, record each decK sync, and agree the evidence list with your auditor before the migration starts.
Kong Enterprise licensing, if required	Some needs, such as fully self-hosted control planes with a local control plane and data plane, fall under Kong Gateway Enterprise, which carries a license cost that open-source use avoids.	Map each required feature to the open-source edition before scoping, and ask the vendor in writing which features need the commercial license.

What usually goes wrong in an Apigee to Kong migration

Most Apigee to Kong problems come from assumptions made early, before any proxy is mapped. The cards below cover the decisions and checks that prevent surprises in behavior, deployment mode, support and configuration control.

Assuming Enterprise features exist in OSS

Teams often map every Apigee policy to a Kong plugin and assume the open-source edition covers it. Some capabilities, such as the features that Kong ties to Kong Gateway Enterprise, are not part of the open-source edition. Before cutover, list each Apigee feature in use and check it against the open-source plugin list and the Enterprise feature comparison. Confirm the answer for each item with Kong rather than assuming it from the plugin names.

Missing policy behavior that changes responses

An Apigee policy can look equivalent to a Kong plugin while differing in defaults, error bodies, header handling, or the order in which steps run. These differences can change what clients receive without any visible failure. Build a replay test set from real traffic, run it against both gateways, and compare status codes, headers and response bodies field by field, including error paths.

Losing consumer keys and secrets

Apigee app credentials, API keys and OAuth client secrets do not move automatically into Kong consumers and credentials. If they are reissued, every client application must update its configuration at the same time. Export the consumer and credential inventory from Apigee, decide which credentials are migrated and which are reissued, and plan the rotation window with the owners of each consuming application before cutover.

DB-less limits discovered late

DB-less mode suits Git-managed declarative configuration, but it does not support every plugin. Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 require traditional mode. If the team designs around DB-less first and finds a needed plugin later, the topology has to change. Check the plugin list for each Apigee policy against the deployment topology documentation before choosing the mode.

Running the 3.9 OSS line without a support window

The open-source Kong Gateway repository's newest release line is 3.9, and Kong's version support policy covers only Kong Gateway Enterprise, so no published support window applies to the open-source edition. Your team owns patching, security response and upgrade planning for that line. Decide who monitors advisories, how quickly security fixes are applied, and what the upgrade path is before production traffic moves.

Unmanaged drift between Git and running config

When declarative files in Git and the running gateway diverge, nobody can be sure which configuration is live. Manual edits through the Admin API or dashboards are a common cause. Use decK to dump the running configuration regularly and diff it against the repository, restrict write access to the Admin API, and run drift checks in the deployment pipeline so that unexpected changes are caught and reverted.

How the Apigee to Kong move differs by starting point

Apigee Edge for Private Cloud is the self-run option, so you already own the runtime, the management components and the data. The deadline is the constraint. 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 also requires running a version within its 18-month full support window, so confirm with Apigee which version your estate is on before you plan the move.

Export effort: Proxy revisions, shared flows and environment configuration can be pulled from the management API as bundles, which makes this the most exportable starting point.
Cutover risk: You can run Kong Gateway beside the existing runtime and move routes one API at a time, which lowers risk if the schedule allows parallel running.
Control plane: Kong's open-source edition has no hosted control plane, so you choose between DB-less declarative files kept in Git and a self-run traditional mode with a database.
Schedule pressure: A move that must finish before June 30, 2027 leaves little room if policy mapping turns out to be large.
Support gap: Ask Apigee whether any interim patch path exists for your version before relying on it.

Confirm your exact Edge version and the list of policies in use before estimating any effort.

Questions buyers ask before moving from Apigee to Kong Gateway

What drives the cost of moving from Apigee to Kong Gateway?

The cost is driven mostly by the number of proxies, shared flows and custom policies you must rebuild, plus how many environments and clusters you run. Kong Gateway OSS itself is Apache-2.0 licensed, so the software line item is zero, but you still pay for the infrastructure that runs it, the engineers who map and test each proxy, the CI pipeline that deploys declarative configuration, and the operations staff who run the gateway afterwards. Ask any quote to split one-time work (inventory, mapping, custom plugin development, cutover testing) from recurring work (hosting, upgrades, patching, support contracts). Confirm with Kong which features you need, since fully self-hosted Kong Gateway Enterprise sits in a commercial offering according to Kong's pricing page.

How long does an Apigee to Kong Gateway migration usually take?

Duration depends on the size of the proxy estate, how many Apigee policies have no direct Kong plugin, and how much traffic validation each API needs before cutover. Teams with a small set of pass-through proxies that use authentication and rate limiting usually finish faster than teams with heavy JavaScript, Java callouts or custom shared flows. No fixed timeline applies to every estate, so ask for a written scope with a phased plan, in which each environment and API group has its own cutover criteria. Your own inventory of proxies and policies is the best input for any estimate.

Can our own team migrate from Apigee to Kong Gateway without outside help?

A team with gateway operations experience and access to Kong's documentation can usually do the work in-house, especially for a small estate. The skills that matter most are declarative configuration in Git, Kubernetes or container operations, and the ability to rebuild Apigee policy logic as Kong plugins or upstream services. Outside help is most useful for an inventory of proxies, custom plugin development, security hardening, backup design and compliance evidence. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with written deliverables.

Which Apigee features have no open-source equivalent in Kong Gateway OSS?

Apigee's managed analytics, monetization, developer portal and some advanced traffic features do not map one-to-one to the Kong Gateway OSS plugin set. The Kong Gateway README lists routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, rate limiting and transformation plugins, so those translate well. Cluster-strategy rate limiting and OAuth2 depend on a database, which means they require traditional mode rather than DB-less mode. Any Apigee policy that depends on a feature outside that list needs a custom plugin, an upstream service, or a commercial Kong feature. Confirm the current edition feature list with Kong before you decide.

Is Kong Gateway OSS enough to produce compliance evidence?

Kong Gateway OSS can provide configuration, logs and access controls that feed compliance evidence, but the gateway alone does not satisfy any framework. Evidence depends on how you store declarative configuration in Git with review history, how you restrict the Admin API, how you centralize logs, and how you document change and access processes. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make that determination, so ask your auditor early which artifacts they expect.

How should we handle the Kong Gateway 3.9 OSS line versus Enterprise releases?

The open-source repository's newest release line is 3.9, with 3.9.4 listed on October 12, 2026 in the GitHub releases, while Kong Gateway Enterprise has moved to quarterly releases and reached 3.16 on September 15, 2026. Kong's version support policy applies only to Enterprise, so the OSS edition has no published support window in the sources we reviewed. Plan an upgrade and patch process for the 3.9 line yourself, track security advisories, and test each release in a non-production environment. Decide early whether you need Enterprise features, and confirm with Kong how the two editions differ in the version you deploy.

What does our team need to provide before the migration starts?

You need an export of Apigee proxy bundles, a list of shared flows, target endpoints, policies and environment variables, and the Apigee IAM access needed to pull them. You also need named owners for each API, the target hosting environment (Kubernetes, VMs or packages on Ubuntu, RHEL, Debian or Amazon Linux), identity provider details for authentication, a CI/CD path for declarative files, and a test traffic plan. Clear decisions on DB-less or traditional mode, logging destinations and rollback windows should also be ready. Ask the implementer to confirm which of these items are needed for your scope.

How do we roll back if the Kong Gateway cutover fails?

The safest rollback keeps Apigee serving traffic until each API passes validation on Kong, so you can shift routes back by changing DNS, load balancer or ingress weights. Keep declarative Kong configuration in version control so you can restore a known-good state with decK, and keep the Apigee proxy revisions unchanged until the cutover is closed. Define rollback triggers in advance, such as error rate or latency thresholds, and rehearse the reverse path in a non-production environment. Write these steps into the runbook before the first production cutover.

What DeployOpen does in an Apigee to Kong engagement

A DeployOpen engagement for this move starts with a written scope that names the Apigee environments, proxies, shared flows, portal and traffic volumes in play, the target Kong topology, and the deliverables and timelines both sides sign before work begins. Most engagements are fixed-scope, so the decisions that drive cost, such as whether the Kong data plane runs in DB-less or traditional mode, which plugins are required, and how many environments are migrated, are settled at the start rather than discovered mid-project. Before scoping, we ask the client to export proxy bundles and list every Apigee policy in use, because that inventory is what the policy mapping work is built on.

Once scoped, the work moves through policy mapping, a Kong build in the client's own infrastructure, and decK pipelines that keep the configuration in Git. Each Apigee policy is mapped to a Kong plugin, a custom plugin, or a documented gap that the client has to accept or fund. The Kong Gateway is installed and hardened in the client's cloud account, data center or air-gapped network, and the deck gateway dump and sync workflow is wired into the client's own review and release process. Parallel-run testing then sends the same traffic through Apigee and Kong and compares responses, latency and error rates before any cutover. Handover includes runbooks, configuration documentation and the test evidence, and ongoing support, upgrades and continuous testing are available as retainers once the client owns the platform.

How DeployOpen scopes, runs and supports the Kong migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so a move from Apigee to Kong Gateway runs in your cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory of Apigee proxies, shared flows, products and environments agreed in writing before work starts
Mapping of each Apigee policy to a Kong plugin, custom plugin or documented gap, with owners named
Written list of Enterprise-only features your team needs, so licensing decisions are made before build

How we build

Kong services, routes and plugins defined as declarative files, kept in Git and synced with decK
Deployment in DB-less or hybrid mode on your chosen infrastructure, with testing against traffic samples
Custom plugins built only where a documented Apigee policy has no Kong equivalent, with tests included

How we hand over

Runbooks covering configuration changes, rollback steps and environment promotion using decK
Mapping document recording every Apigee-to-Kong decision, including gaps accepted by your team
Training sessions for your platform and API teams on operating the gateway in your environment

How we support

Fixed-scope delivery ends with handover, after which ongoing support is available as a retainer
Retainers can cover upgrades, backups, security testing and continuous testing of the gateway
Confirm with DeployOpen in the written scope which Kong edition and support window your team relies on