What moving from Kong Konnect to Kong Gateway OSS actually involves
If your Konnect renewal, pricing change or residency concern is pushing you toward self-hosting, the core answer is this: routes, services and open-source plugins can move to Kong Gateway OSS with decK, but the Konnect control plane, developer portal, analytics and Enterprise-only plugins do not move and must be replaced or dropped. The work usually falls to the platform or API team that already owns the gateway, since they know the upstreams, consumers and deployment pipelines. An implementation partner is most useful for scoping the cutover, deciding between DB-less and traditional mode, and hardening the self-run environment, not for the routine translation itself.
The effort is mostly inventory and testing rather than file conversion. Export the configuration with decK, then list every plugin in use and check each against the open-source feature set in the Kong Gateway README. Anything that depends on the database, such as cluster-strategy rate limiting or OAuth2, requires traditional mode with a database you operate, while DB-less mode suits teams that keep declarative files in Git. Confirm with Kong which Enterprise plugins your routes actually depend on, because those become the main risk. Also confirm the support position: the open-source edition is documented on the 3.9 line in the supplied facts, and Kong's version support policy covers only Enterprise, so you should set your own patching and upgrade cadence before go-live.
Costs shift from a subscription to components you run: compute and load balancing for the data plane, a database and its backups in traditional mode, monitoring, certificate management and the staff hours for upgrades. Ask any implementation partner for a written scope that lists the gateways, environments, plugins, the cutover approach and the acceptance tests, and ask your own team to confirm who will be on call for the self-run gateway.
Which Konnect capabilities map to Kong Gateway OSS and which need rework
This table compares each Konnect capability with its counterpart in self-run Kong Gateway OSS and marks it as clean, needs rework or gap. Read the status column first, then the notes on database-dependent plugins, which only run in traditional mode. The main takeaway is that the gateway configuration moves across with decK, while the Konnect control plane, portal and analytics must be replaced by your own tooling.
| Konnect capability | Kong Gateway OSS equivalent | Status and notes |
|---|---|---|
| Services and routes | Declarative services and routes exported with decK | Clean. Export with deck gateway dump and load the file in DB-less or traditional mode. |
| Consumers and credentials | Consumers and credential plugins such as key auth, JWT and basic auth | Needs rework. Credentials must be re-issued or migrated securely, since secrets are not portable through Konnect's UI. |
| Open-source plugins (routing, load balancing, health checking, JWT, basic auth, OAuth, ACL, transformation) | Same plugins in Kong Gateway OSS | Clean. Confirm each plugin version against the 3.9 line you deploy. |
| Rate limiting (local policy) | Rate limiting plugin with local policy | Clean. Local counters work in DB-less mode. |
| Rate limiting (cluster strategy) and OAuth2 token storage | Database-dependent plugin behavior | Needs rework. Requires traditional mode with a database. DB-less mode does not support these. |
| DB-less declarative config | DB-less mode with files kept in Git | Clean. Read-only Admin API, so changes go through version-controlled files. |
| Hybrid control plane and data plane | Hybrid mode run by your team | Needs rework. You operate the control plane, certificates and data plane connectivity yourself. |
| Konnect control plane UI | decK, Git workflows and the open-source Admin API | Gap. No hosted console. Plan for CI pipelines or a self-hosted UI. |
| Developer portal | No bundled portal in Kong Gateway OSS | Gap. Use a separate portal or catalog, such as Backstage, and migrate specs and credentials. |
| Analytics and dashboards | Logs and metrics from your own observability stack | Gap. Configure logging and metrics plugins and build dashboards in your own tools. |
| Dedicated Cloud Gateways and serverless gateways | Self-hosted data plane on your infrastructure | Needs rework. Move hosting, scaling and patching into your team's scope. |
| Enterprise plugins | Not included in the open-source edition | Gap. Confirm each plugin you use against Kong's Enterprise documentation before cutover. |
Which configuration exports cleanly with decK and what to rebuild
Routes, services and open-source plugin settings move through decK into a declarative file you can version and sync. Most of what makes a Konnect tenant operational, from portal content and users to secrets and monitoring, sits outside that file and needs its own migration plan.
Running the decK gateway dump
Run deck gateway dump against your Konnect control plane to produce a declarative YAML or JSON file of services, routes, consumers and plugin configuration. Check the file against the control plane before you trust it, because the export only covers what the decK tool reads from that control plane. Confirm the decK version you use supports your Konnect control plane and the target Kong Gateway release.
Syncing the file to open-source Kong
The same declarative file can be applied to an open-source Kong Gateway with deck gateway sync against a traditional database-backed node, or loaded into a DB-less node through its declarative configuration. Plugins that depend on a database, such as cluster-strategy rate limiting and OAuth2, need traditional mode, so confirm that mode before you rely on those settings. Test the synced configuration in a staging environment first.
Git as the home for configuration
Store the exported file in a Git repository with review, branch protection and a deploy pipeline that applies it to each environment. This replaces the Konnect UI as the place where changes are made and recorded. Decide who approves changes, how secrets are kept out of the file, and how drift is detected if someone edits a node directly.
Portal content and developer accounts
The developer portal content, API documentation pages and application registrations held in Konnect do not travel in the gateway file. Export or copy the OpenAPI specifications you keep, and plan how consumers receive new credentials. Decide whether the portal is replaced, rebuilt or dropped, and tell API consumers before the cutover date.
Analytics history and Konnect users
Usage analytics and historical request data remain in Konnect and are not part of a configuration export. Konnect organization users, teams and roles also stay behind, so you must define who administers the self-hosted gateway and under which identity provider. Ask Kong which analytics exports, if any, your current plan includes before the decommissioning date.
Certificates, secrets and monitoring hooks
TLS certificates, private keys, consumer secrets and any plugin credentials must be re-issued or moved into your own secrets store, because they are not reliably exported as plain configuration. Upstream CI/CD hooks, alert rules and monitoring integrations that were wired to Konnect also need rebuilding. Inventory each one, assign an owner and test the alerts against the new gateway before switching traffic.
Migration sequence from inventory to Konnect decommission
This sequence moves Kong routes, services and open-source plugins from Konnect to a self-run Kong Gateway OSS, proving each stage on a low-risk API before any production traffic moves and keeping Konnect available as a rollback path until the cutover is confirmed.
Inventory services, routes, plugins and consumers
Run
deck gateway dumpagainst the Konnect control plane to export services, routes, plugins, consumers and upstreams into a declarative file, and keep that file in Git. Then list every plugin in use and mark each one as open source or Enterprise-only, since only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Confirm the exact decK version your Konnect region requires. The output is a reviewed inventory that shows which APIs can move in DB-less mode and which need a database.Pilot a non-critical API in DB-less mode
Choose one internal or low-traffic API whose plugins are all open source, load its exported file into a self-run Kong Gateway OSS instance in DB-less mode, and point a test client at it. Run the same request set against Konnect and the local gateway and compare status codes, headers, rate-limit behavior and authentication results. The output is a pilot report listing every difference found and the change made to close it.
Choose DB-less or traditional mode by plugin needs
Map each remaining API to a deployment mode based on the inventory. APIs using only stateless plugins such as key authentication, JWT, ACL or local rate limiting can run DB-less with declarative files in Git and a read-only Admin API. APIs that depend on database-backed plugins need traditional mode with a PostgreSQL database that your team operates and backs up. Confirm the plugin list against Kong's deployment topologies documentation before you commit. The output is a decision record per gateway cluster that names the mode and the reason.
Run parallel traffic with a split at the load balancer
Put the new gateway behind the existing load balancer or DNS record and send a small, controlled share of live traffic to it while Konnect continues to serve the rest. Watch error rates, latency, authentication failures and upstream health on both paths, and keep decK sync running from the same Git source so configuration does not drift between them. Set the traffic share and the criteria for raising it in writing before starting. The output is a dated parallel-run log with the metrics agreed in advance.
Cut over and keep a rollback path
Move the remaining traffic to the self-run gateway in stages, following the runbook your team wrote for the change window. The runbook should name the owner of each step, the health checks that gate each stage, and the command or DNS change that returns traffic to Konnect. Leave the Konnect data plane running and unchanged until the agreed observation period ends. The output is a signed cutover record and a rollback plan that has been rehearsed at least once.
Decommission Konnect data planes and control plane access
After the observation period closes without rollback, export a final decK dump from Konnect and store it with the Git history. Remove the Konnect data plane nodes, revoke the Konnect access tokens and personal accounts, and confirm that portal, analytics and any Enterprise plugin dependencies are no longer referenced by your clients. Record what was lost with the control plane, such as the hosted analytics and developer portal, and assign owners for replacements. The output is a decommission checklist with each access path shown as closed.
DB-less or traditional mode: choosing how you run it yourself
DB-less mode runs Kong Gateway with no database. Each node loads its routes, services, consumers and plugins from declarative files, which your team can keep in Git and promote through the same review process as application code. The Admin API is read-only in this mode, so changes come from the files, not from live API calls. That suits teams that already run GitOps for their platform and want configuration history, peer review and repeatable rollouts.
- Configuration source: Declarative YAML or JSON files, typically produced by decK and stored in a repository.
- Change path: Edit the files, review them, then reload or redeploy the nodes. There is no live editing through the Admin API.
- Plugin scope: Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 are not available in this mode.
- Operations load: You manage node images, file distribution and rollout order, with no database to back up or patch.
- Isolation: Nodes do not share state, so each node must receive the same files.
Confirm with the Kong deployment topologies documentation for your exact version which plugins and features run in DB-less mode, and whether your rate limiting and authentication requirements can be met without a database.
Traditional mode stores configuration in a database, which Kong Gateway uses to share state across nodes. It is the mode to choose when you need database-dependent plugins such as cluster-strategy rate limiting and OAuth2, or when your team wants to change configuration through the Admin API while the gateway runs. The database becomes a critical component that you must size, secure, back up and upgrade alongside the gateway.
- Database dependency: A supported database must be deployed, sized and kept highly available, and it becomes part of your recovery plan.
- Plugin scope: Cluster-strategy rate limiting and OAuth2 are available in this mode.
- Admin API: Writable, so configuration changes can be made live, which requires access control and an audit trail.
- Hybrid option: Hybrid mode separates a control plane that holds the database from data plane nodes that receive configuration, which reduces the exposure of the database to the traffic path.
- Upgrades: Database migrations must be planned and tested for each version change.
Confirm the supported database engines, migration steps and hybrid setup in the Kong deployment topologies documentation for the version you plan to run.
The choice follows from the features you need and the operating model your team will support. A team that needs only routing, authentication such as JWT or key-based methods, and rate limiting that does not depend on shared state can usually start with DB-less mode. A team that needs cluster-wide rate limiting, OAuth2, or runtime changes through the Admin API should plan for traditional mode, with hybrid separation if the control plane must stay apart from the traffic path.
- Feature check: List every plugin your current Konnect configuration uses and test each one in the mode you select.
- Team skills: DB-less favors GitOps and file-based workflows, while traditional mode requires database administration.
- Recovery: DB-less recovery means redeploying files, while traditional mode requires database backup and restore.
- Connectivity: Hybrid mode requires network paths between control and data planes.
- Version pinning: The open-source edition stays on the 3.9 line, so verify each plugin against that release.
Before you commit, check the feature matrix and deployment guidance in the Kong documentation for your chosen version.
What staying on the 3.9 open-source line means for upgrades
The newest open-source Kong Gateway release line is 3.9, and the latest release in that series is 3.9.4, dated October 12, 2026 on Kong's GitHub releases page. Kong Gateway Enterprise has moved well past that line, reaching 3.16 on September 15, 2026, and its releases now ship quarterly. Kong's version support policy describes support windows only for Enterprise, so the open-source edition has no published support window. That leaves your team to decide how long a 3.9 build stays in production, when it moves to a newer line, and who is accountable when a fix is needed. Read the version support policy before you write that decision down.
Patch monitoring becomes a standing task. Watch the Kong Gateway GitHub releases for 3.9.x updates, and record which build each gateway node runs, including nodes in hybrid or DB-less topologies. Each update requires rebuilding the Docker images or OS packages you deploy for Ubuntu, RHEL, Debian or Amazon Linux, then a staging run of your declarative configuration through deck gateway sync with every plugin you use. If Kubernetes runs your gateway, check the Kong Ingress Controller version too, since it follows its own release cadence. Schedule the review, name the person who signs off, and keep the results in your change records so auditors can trace each upgrade.
Before you commit, put these questions to Kong in writing. Ask whether security fixes will be released for 3.9 after a newer open-source line appears, and if so, for how long. Ask whether an open-source fix would arrive first in Enterprise and be carried back to the community edition. Ask what the supported upgrade path from 3.9 to a later open-source release looks like, and whether any plugin or kong.yaml changes are required. Record the answers in the migration plan with a named owner. If no one on your team can absorb that patch cadence, a retainer for upgrades and patch testing from an implementation partner is an option to price against a written scope.
What usually goes wrong when moving off Konnect
Most failed moves off Konnect trace back to a few gaps: features that were quietly provided by the SaaS layer, configuration with no single source of truth, and cutovers that cannot be reversed. Each card below names one of these risks and the check to run before production traffic moves to a self-run Kong Gateway OSS.
Enterprise-only plugins found late
Teams often inventory routes and services but not the plugins attached to them. Some plugins used in Konnect configurations may belong to the Enterprise edition, and the open-source edition will reject or ignore them after cutover. Before migrating, export the full configuration with decK, list every plugin name in use, and check each one against the open-source plugin list in the Kong Gateway README and the Enterprise feature set on Kong's pricing page. Confirm replacements for any gap before the migration plan is approved.
DB-less config drift
In DB-less mode, the declarative files are the only record of gateway state, and the Admin API is read-only. If someone edits a route in the Konnect console during the transition, or applies a hotfix directly to a node, the files and the running gateway diverge. Keep the declarative files in Git, make every change a reviewed commit, and run a scheduled comparison between the repository and the live gateway so drift is caught before it becomes an outage.
Rate limits behave differently by mode
Rate limiting that counts requests across several nodes usually depends on a shared database. DB-less mode does not support the cluster-strategy rate limiting or the database-dependent OAuth2 plugin, so a policy that was enforced cluster-wide in Konnect may become per-node or unavailable. Test the limits under load in the mode you plan to run, document the expected behavior for each consumer tier, and decide whether traditional mode with its own database is required before the cutover date is set.
Lost portal and analytics visibility
The Konnect developer portal and analytics show API owners and consumers what is published, who is calling, and where errors occur. Those views do not come with the open-source gateway. Before cutover, identify which teams rely on the portal listing, usage reports or dashboards, and confirm where their replacement will come from, whether that is a separate portal, log pipeline or metrics stack. Consumers who lose their only view of API health often report problems later than they should.
Credentials not re-issued
Consumer keys, JWT secrets and OAuth client credentials stored in Konnect do not move automatically into a new gateway in a form that can be reused safely. Plan a credential inventory with each consumer owner, decide whether secrets are rotated or carried over, and schedule the re-issue so that clients switch in a defined window. Record who received each new credential and confirm that old keys are revoked once the cutover is complete.
No tested rollback path
A cutover without a rollback is a one-way move. Keep the Konnect control plane and its data plane running until the new gateway has carried production traffic for an agreed period. Define the DNS or load balancer switch that moves traffic back, rehearse it in a staging environment, and confirm that the decK export taken before cutover can restore the previous configuration. Assign one owner who can trigger the rollback without waiting for approval.
How the migration differs by estate size and starting point
A small estate with a handful of services, routes and open-source plugins is the simplest case. Routing, load balancing, health checks, key or JWT authentication and rate limiting in local mode can usually be expressed in a single declarative file that you export with decK and review by hand. Because the configuration is small, the whole exercise can often be run in a staging environment that mirrors production and then promoted through your normal change process.
- Export and review: Run
deck gateway dumpagainst the Konnect control plane, then read the resulting file end to end rather than trusting it blindly. - Choose the mode early: DB-less mode suits a small estate kept in Git, while traditional mode is needed only if you rely on database-dependent plugins.
- Check plugin parity: Confirm each plugin in use is part of the open-source edition, since Enterprise-only plugins will not carry over.
- Keep the cutover simple: Point a small number of clients at the new gateway, observe, then move the rest.
- Retire Konnect last: Keep the Konnect configuration readable until the self-hosted gateway has run cleanly for your agreed observation period.
Before starting, confirm with your own inventory that no plugin, consumer or service in use depends on a Konnect-only feature.
A large estate with many services, many consumers and a developer portal in daily use changes the work more than the gateway itself. The gateway configuration may export cleanly, but consumer credentials, application registrations, API documentation and subscription records live in the Konnect control plane and the Konnect Dev Portal, and those do not come with a decK file. Scope therefore expands to identity, documentation and consumer communication, and the sequence has to protect every consumer that depends on a credential or a published spec.
- Inventory consumers separately: List every consumer, credential type and application that authenticates through the gateway, since these are not part of a standard route export.
- Plan portal replacement: Decide what replaces the Konnect Dev Portal, such as another self-hosted portal or a catalog, and how specs and documentation will be moved.
- Stage by domain: Migrate groups of services in waves, so that owners can test their consumers without the whole estate changing at once.
- Manage credential rotation: Where consumers must receive new keys or tokens, agree the window with each owning team before cutover.
- Run both control paths in parallel: Keep Konnect in read-only use during the transition so teams can compare behavior.
Ask your team to confirm how many consumers and credentials exist and which portal features are used, because these determine the wave count and the coordination effort.
A team that already runs Kong on Kubernetes often uses the Kong Ingress Controller, which is Apache-2.0 licensed and maintained by Kong. In this setup, routes and plugins may be defined as Kubernetes resources and reconciled into the gateway, so the migration is partly a question of where the source of truth lives. Moving from Konnect means deciding whether the cluster becomes the single place where configuration is written, and confirming that the controller version, gateway version and custom resources match.
- Pick the source of truth: Decide whether configuration lives in Kubernetes manifests in Git or in declarative files, and retire the other path to avoid drift.
- Match controller and gateway versions: Check the compatibility table for the Kong Ingress Controller release you intend to run against the open-source gateway version.
- Translate custom resources: Map any Konnect-managed definitions to the controller's resources, and test each plugin binding in a non-production cluster.
- Plan the ingress cutover: Use DNS or load balancer changes or a parallel ingress class so that traffic can shift and roll back without redeploying applications.
- Review cluster ownership: Confirm which team owns the controller, its upgrades and its security configuration after the move.
Confirm the exact controller and gateway versions against the project documentation before you commit to a plan.
Organizations in regulated sectors or disconnected networks often start from a different constraint: the gateway must run with no path to Kong-hosted services. The migration scope then includes how configuration is delivered, how updates are approved and how logs and metrics are kept inside the boundary. A DB-less deployment fed from files that pass your change control is often the most direct route, but that choice depends on which plugins the estate actually uses.
- Confirm mode fit: Verify that every plugin in use runs in DB-less mode, because database-dependent plugins require traditional mode.
- Build the artifact path: Decide how configuration files and gateway packages are reviewed, signed and moved into the network.
- Plan observability inside the boundary: Identify where logs, metrics and audit records will be stored and who can read them.
- Document evidence: Keep change records and configuration history that your assessors will request.
- Test failure paths: Rehearse rollback, since no SaaS control plane will be available to help during an incident.
Check these points with your security and compliance owners before scoping, because they often change the sequence more than the technical translation does.
What drives the cost and duration of the move
This table lists the factors that change how much work it takes to leave Konnect for self-run Kong Gateway OSS, and how to keep each one manageable. Read it before asking for a quote, because the same route count can mean a short cutover or a long one depending on plugins, consumers and downstream tooling. Konnect fees are described by component only, so you can map them to your own invoice.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of services and routes | Each service and route must be exported, validated and re-tested. Large or duplicated route sets multiply review and regression work. | Run decK dump, remove stale or duplicate entries, and group routes by team before the first sync. |
| Enterprise-only plugins in use | Plugins available only in Kong Gateway Enterprise have no open-source equivalent, so each one needs a replacement, a custom plugin or a design change. | Inventory every plugin in the export and classify it as OSS, Enterprise-only or custom before scoping. |
| Consumers and credential volume | Consumers, API keys, JWT secrets and OAuth credentials must be moved or reissued, and clients may need coordinated changes. | Confirm which credential types are exportable from your export file and plan a staged rotation with client owners. |
| Need for traditional mode and database operations | Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 require traditional mode, which means you operate PostgreSQL, backups and upgrades yourself. | Choose DB-less mode where your plugins allow it, and size the database operations work only for the plugins that require it. |
| Portal and analytics replacement scope | Konnect's developer portal and analytics have no direct open-source Kong equivalent, so API documentation, app onboarding and dashboards need new tooling. | Decide early which consumers depend on the portal and whether Backstage, Gravitee or another portal will replace it. |
| CI/CD and monitoring rewiring | Pipelines that call the Konnect API or read Konnect dashboards must be repointed to decK, the Admin API and your own metrics and logging stack. | List every pipeline and alert that touches Konnect, and map each to a decK, Admin API or self-hosted monitoring equivalent. |
| Compliance evidence needs | Assessors may ask for change history, access control, backup and restore proof and vendor support status for the gateway, which Konnect previously supplied in part. | Confirm the evidence list with your auditor first, then design Git-based change records, access logs and restore tests to produce it. |
Questions teams ask before moving off Konnect
How much effort does moving off Konnect to Kong Gateway OSS take?
The effort depends mostly on how much configuration you have and how many of your plugins are Enterprise-only. A small set of services, routes and open-source plugins exports cleanly with decK and mainly needs a new runtime, pipelines and testing. Larger estates need time to review each consumer, credential and custom plugin, and to rebuild anything that relied on Konnect's portal or analytics. Ask for a written inventory of services, routes, consumers, plugins and integrations before accepting any estimate, because that inventory sets most of the work. Recurring effort after cutover is the part teams often underestimate: someone must own upgrades, certificates, backups and monitoring of the gateway.
How long does a Konnect to Kong Gateway OSS migration run?
No fixed duration applies to every estate, so treat any single number with caution. Timing is set by the number of APIs and environments, how many consumers must be moved and re-credentialed, how often your release calendar allows changes, and how much testing your clients need before cutover. Teams with strict change control usually spend more time on approvals and rollback plans than on the gateway itself. Ask any implementation partner to tie the timeline to a written scope with named deliverables, and confirm which of your environments and dependencies are included.
Can our team migrate from Konnect alone using decK and the Kong docs?
A team with solid Kubernetes or Linux operations and some API gateway experience can often export with decK, run a local Kong Gateway and validate the configuration in a test environment. The gaps usually appear around authentication plugins, rate limiting that needs a database, certificate handling and the cutover plan. Check whether your team has someone who can own the gateway after launch, not only during the project. If that skill set is thin, a fixed-scope engagement can cover planning, implementation, hardening, backup and documentation, with ongoing support available as a retainer.
What do we need to provide during the migration?
Plan on providing access and decisions rather than only documents. The usual needs are:
- Read access to the Konnect control plane and the decK export for each environment
- Named owners for each API, consumer application and upstream service
- Change windows, rollback criteria and a freeze calendar agreed with the business
- Access to your cloud accounts, clusters, DNS, certificate authority and secrets store
- Test traffic or a staging environment that resembles production
Does DB-less mode suit our Kong Gateway deployment?
DB-less mode suits teams that manage configuration as code and do not need database-dependent plugins. In DB-less mode, Kong Gateway takes its configuration from declarative files that can live in Git, and it exposes a read-only Admin API. Traditional mode is required for database-dependent plugins such as cluster-strategy rate limiting and OAuth2. Check your current plugin list against this limit before choosing a mode, and confirm with the Kong deployment topologies documentation how your chosen topology handles updates and high availability.
What happens to the Konnect developer portal and analytics?
The Konnect developer portal, the Konnect analytics views and the Konnect management console do not come with self-hosted Kong Gateway OSS, because they belong to the Kong-hosted control plane. You keep the gateway, its routes, services and open-source plugins. To replace the portal, you need a separate developer portal or catalog, and to replace analytics you need logs and metrics from your own observability stack. Export your API specifications, application registrations and documentation before you cancel anything, and confirm each replacement with its vendor or project before you commit.
How do we handle Enterprise plugins when leaving Konnect?
Start by listing every Enterprise plugin in use, then decide for each whether an open-source plugin, a custom plugin, or a change to the API design covers the need. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of the commercial Kong Gateway Enterprise offering, so a self-run deployment on the open-source edition will not include those features. Security-relevant plugins deserve a formal review, because removing them can change your authentication or rate limiting posture. Confirm the license terms for any custom plugin with your legal team.
Can we keep Konnect for some traffic during the transition?
Yes, a phased move is a common pattern, but it adds operational complexity. Two control planes mean two places to change configuration, two sets of credentials and two sets of logs to correlate. Many teams move low-risk APIs first, keep Konnect for the rest, and set a date to retire it once monitoring and rollback procedures are proven. Ask Kong for current terms on your existing contract before planning any overlap, and document which APIs run on which gateway so that incident responders know where to look.
How DeployOpen scopes and runs a Kong Gateway OSS migration
DeployOpen plans, implements, hardens, documents and supports self-hosted Kong Gateway inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. For this migration, that written scope should name the Konnect services and routes being moved, the plugins in use and which of them are Enterprise-only, the target deployment (DB-less with declarative files in Git, or traditional mode with a database), the decK export and import steps, the consumer and credential migration, and the cutover and rollback plan. Ask for each of these to appear as a named deliverable so that acceptance can be checked against it.
The scoping conversation also has to settle what the platform owns after go-live. Kong Gateway OSS stays on the 3.9 line in the open-source repository, and its version support policy applies only to Kong Gateway Enterprise, so your team needs an agreed process for patching and upgrades. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which are separate from the fixed-scope build. Decide early whether your internal team will own routine upgrades, whether a retainer will cover them, and who approves a change to a production gateway. Confirm these terms in writing with the retainer scope rather than assuming they carry over from the build.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move the number are the number of gateways and environments, the plugin and authentication configuration, the degree of integration with your identity, logging and monitoring systems, and the hardening and documentation you require. When you request a quote, ask for the one-time build fees and any recurring retainer as separate line items, and ask which items are excluded, such as infrastructure, licenses for other tools, or your own staff time. Your internal cost of running the gateway, including the hosting and on-call work, is yours to estimate and should be compared against the Konnect fees you are replacing.
