Kong Enterprise and Kong Gateway OSS share the same open-source core. Teams leave Enterprise when the licensing on top of that shared core, plus per-feature gating for RBAC, the Dev Portal, and Vitals analytics, and support-tier costs, no longer justify what they actually use. Because the gateway engine is identical, this is the lowest-effort migration in the API-management category. The work is not moving the gateway; it is replacing the licensed features layered above it.
What carries over untouched
Start with the reassuring part. Your services, routes, and the standard plugins, rate limiting, key-auth and OAuth, request and response transformers, ACL, are the same primitives on both editions. There is:
- no gateway to re-architect,
- no policy or proxy language to translate,
- no consumer model to rebuild.
Your declarative configuration for the open core applies to OSS as-is. This is why the migration can, in the best case, come close to repointing the data plane and moving on.
The three features you must replace
The effort concentrates entirely on the Enterprise-only additions. Each has an established open replacement:
- RBAC over the admin surface → GitOps. OSS does not gate the admin API by role. The open pattern is to keep all configuration in Git and control who can merge, so your source-control permissions become your access model.
- Enterprise Dev Portal → an external or open portal. OSS does not bundle the portal. You generate a developer portal from your OpenAPI specs using external or open tooling.
- Vitals analytics → Prometheus and Grafana. OSS does not include Vitals dashboards. You expose Kong metrics to Prometheus and build the views you need in Grafana.
How big this migration is equals how much you depended on these three. That is the honest sizing rule.
Auditing your config for Enterprise-only references
Before cutover, sweep your declarative configuration for anything Enterprise-specific. Standard plugins port directly, but any config that names an Enterprise-only plugin or feature will not load on OSS. Find those references and either drop them or swap in an open equivalent ahead of time, so the OSS control plane does not reject an unknown plugin mid-migration. This audit is the single most valuable preparatory step and usually short.
The GitOps shift is a habit change, not just a tool
Of the three replacements, moving from RBAC to Git-controlled configuration is the one that changes how people work, not just what runs. On Enterprise, an operator with the right role could edit the admin surface directly. On OSS with GitOps, every change becomes a reviewed merge, which is stronger for audit and rollback but slower for the quick hand-edit some teams relied on. Set the expectation before cutover: admin changes now go through pull requests, and anyone who previously depended on direct edits needs the pipeline in place first. Teams that already ran their config through Git barely notice; teams that clicked through the Enterprise UI feel this most, so surface it early.
Repointing the data plane
For the gateway itself, the mechanics are straightforward because nothing about the proxying changes. You stand up OSS nodes, or repoint the existing data plane at an OSS control plane, and move workloads over while keeping the same services, routes, and plugin config. Run OSS alongside Enterprise during the transition so you can shift traffic deliberately and roll back a single workload if something is off, rather than flipping everything at once.
A right-sized cutover sequence
- Assess your Enterprise-feature usage. List exactly where you use RBAC, the Dev Portal, and Vitals. This list is your real scope.
- Stand up the open replacements you actually need: GitOps for config control, an external portal, and a Prometheus and Grafana pipeline.
- Audit and clean the config so it references only open-core plugins and features.
- Bring up OSS in parallel and move workloads over, keeping the declarative config intact.
- Cut traffic across once observability and the portal are in place, then retire the Enterprise nodes.
If your Enterprise-feature list from step one is short, most of this collapses into steps three through five.
Knowing it is done
Because the core is identical, functional parity on the gateway is easy to confirm: the same requests route, authorize, and throttle as before. The meaningful checks are on the replaced features, that config changes still go through a controlled, reviewable path now that RBAC is gone, that consumers can still find and self-serve APIs through the new portal, and that your Grafana dashboards show the traffic Vitals used to. When those three are covered, the Enterprise nodes have nothing left to do.
The balance of this move
Kong Enterprise to Kong OSS is the cleanest migration in this category precisely because it is the same engine underneath. There is no gateway rework, only the replacement of RBAC, the Dev Portal, and Vitals with GitOps, an open portal, and Prometheus plus Grafana. The decision comes down to whether the savings on Enterprise licensing and support outweigh the effort to rebuild those three, which is small for teams that stayed close to the open core and larger for those that did not. Model that trade in the calculator above, and keep the figures illustrative until you weigh them against how much of Enterprise you truly use.