Migrate from Kong Konnect to Gravitee: what the move involves
A move from Konnect to self-hosted Gravitee API Management is feasible, but it is a platform migration, not a configuration copy. The effort is moderate and the main risks are in the new management surface, the licensing of the features you rely on, and the handover of consumers. Platform engineers usually own the deployment of the Gravitee gateway, management API backend and MongoDB store, typically on Kubernetes with the Helm chart or on Docker Compose. API owners rebuild the API catalog, plans and subscriptions, and security reviews authentication, access rules and the portal's exposure to the internet. Gravitee's Console UI, used by administrators, and its Portal UI, the catalog developers use, become the main new surfaces your teams must learn, replacing Konnect's Kong-hosted console.
Before you start, confirm which features your Konnect estate actually uses and map each one to an edition. Gravitee's documentation states that the Enterprise Edition requires a license, and several features often wanted in migrations sit in that tier, including audit trails of API consumption and activity, data masking, GeoIP filtering, Dynamic Client Registration, the Alert Engine, Redis caching and the enterprise policy pack. The Community Edition is open source under Apache-2.0 and is self-hosted, so it covers the gateway and portal basics, but you should check each Konnect plugin and portal feature against it in a written gap list. Ask Gravitee or a partner to confirm the current edition boundaries for your required features, because licensing terms decide whether the move is cost-neutral or adds a recurring subscription.
Cost in this migration has four parts: the Gravitee licence if you need Enterprise features, the infrastructure for the gateway, management backend and database, the implementation labour, and ongoing operations, including upgrades and security patching. Konnect's metered billing ends when you stop using it, but the new platform's run cost is paid by you. Request a quote that separates one-time work (export, translation, cutover and testing) from recurring items (licences, hosting, support). Ask for the version you will deploy: the Gravitee repository was tagged core_4.13.1, while the documentation covers API Management 4.12, so confirm which line your installation and documentation match before you plan upgrades.
Which Konnect capabilities map to Gravitee, and which need rework
This table maps each Konnect capability you may rely on to its nearest Gravitee equivalent and marks it clean, needs rework or gap. Read each row against your own gateway services, plugins and consumers, because parity depends on the exact plugins and configuration you run. Most core API traffic management maps cleanly, while Konnect-specific control plane features and some Enterprise-only Gravitee features need planning before cutover.
| Konnect capability | Gravitee equivalent | Status and notes |
|---|---|---|
| Gateway services and routes | APIs with entrypoints, endpoints and path mappings in the management API | Clean. Recreate each decK service and route as a Gravitee API and confirm path and host matching behavior in your environment. |
| Consumers and credentials | Applications subscribed to plans, with API keys or OAuth2 and JWT credentials | Needs rework. Consumer records do not transfer directly, so map each consumer to an application and reissue or migrate credentials. |
| Plugins and policies | Gravitee policies attached to flows and plans | Needs rework. Map each Kong plugin to a Gravitee policy and confirm exact plugin parity in Gravitee's documentation before cutover. |
| Rate limiting and quotas | Rate limit and quota policies bound to plans | Needs rework. Rewrite limits as plan rules and test counters, since behavior across multiple gateway nodes depends on your configuration. |
| Developer portal | Gravitee Portal UI, a catalog of APIs with documentation | Needs rework. Konnect Dev Portal content, specs and app credentials must be republished in the Gravitee Portal and reviewed by consumers. |
| Analytics and reporting | Gravitee analytics in the Console UI, with audit trails and Cloud Reporter on Enterprise | Gap in part. Audit trails, the Alert Engine and Cloud Reporter require a Gravitee Enterprise License; confirm the reporting you need. |
| Enterprise-only features such as data masking and Redis caching | Data masking, Redis caching and GeoIP filtering on Enterprise Edition | Needs license. These require a Gravitee Enterprise License, so budget for them only if your Konnect setup depends on them. |
| Dedicated Cloud Gateways and Konnect-managed control plane | Self-hosted gateway and management API on Kubernetes or Docker Compose with MongoDB | Gap. Kong runs the control plane and Dedicated Cloud Gateways for you, so you take on hosting, upgrades and backups yourself. |
What to export from Konnect and rebuild in Gravitee
Konnect hands you a documented export for gateway configuration, but several parts of your Konnect footprint never appear in that file. The cards separate what you can export with decK from what you must recreate, re-issue or accept as lost in Gravitee. Confirm each export format against your Konnect version before you plan the mapping work.
The decK gateway dump
The decK gateway dump is the documented export path for services, routes, consumers and plugin configuration from Konnect. It writes a declarative YAML or JSON file that becomes the input for your mapping worksheet, so every Gravitee API, plan and policy traces back to a line in that file. Run the dump against each Konnect control plane you operate, and record the decK and Konnect versions used so the file can be reproduced later. Confirm the export format for your Konnect version before you script anything against it.
Services and routes to APIs
Konnect services and routes in the declarative file map to Gravitee APIs and their entrypoints and endpoints, but the mapping is not one to one. Path matching, host rules, methods and strip-path behavior must be checked against Gravitee's model, because a route that works in Kong may need an explicit configuration in Gravitee. Build a table with one row per Konnect route and mark which Gravitee API owns it. Flag any route that depends on a Kong-specific behavior you have not verified in Gravitee.
Consumers, credentials and applications
Consumers exported by decK carry identifiers and plugin bindings, but the secrets used by clients are not something you should expect to move as-is. Treat application credentials as a re-issue task: decide whether Gravitee applications will hold new keys or OAuth clients, then coordinate rotation with each consuming team. Plan a cutover window where old and new credentials both work, and confirm with your security team how key material is handled during the transfer.
Developer portal content
The Konnect Dev Portal content is not part of the gateway dump, so pages, API specifications, guides and portal branding must be exported or rebuilt by hand from your Konnect portal. In Gravitee, the Portal UI presents a catalog of APIs with documentation, so each published API needs its specification and descriptive content recreated there. Inventory every published API and its owner before you build the catalog. Confirm with Kong how to export portal assets from your account, since that path sits outside the decK file.
Analytics history and audit records
Request analytics and usage history recorded in Konnect do not move with the gateway configuration, so Gravitee starts with its own metrics from the day it takes traffic. Decide which historical reports your finance, capacity or compliance teams need, and export them from Konnect while you still have access. Gravitee's audit trails of API consumption and activity are listed as an Enterprise Edition feature, so confirm the edition you need before you plan audit retention. Verify the export options in Konnect for your account.
Konnect RBAC and administrator access
Role assignments, teams and administrator accounts in Konnect are managed in the Kong-hosted control plane, so they do not appear in the gateway file. Document who holds which role today, then map those duties to Gravitee's Console UI roles and your own identity provider. Remove Konnect access for leavers only after the Gravitee console and portal have been tested by the owning teams. Confirm the RBAC export options available to your Konnect organization before assuming you have a complete list.
The migration sequence from inventory to decommission
This sequence moves Kong Konnect traffic to self-hosted Gravitee in controlled stages, so each service is proven on the new gateway before consumers depend on it. It ends with a documented record that Konnect data planes and access have been retired.
Inventory services, routes, plugins and consumers
Your platform or API team exports the current gateway configuration with decK and builds a register of every service, route, upstream, plugin and consumer, including which plugins run globally and which are attached to individual routes. Mark each item as a Gravitee candidate, a gap needing a replacement policy, or a candidate for retirement. The step is complete when the inventory list has an owner and a traffic volume note for every API and a short list of unresolved plugin behaviors for the pilot to test.
Map and prove a pilot API
Choose one low-risk API with a clear consumer group and map it to a Gravitee API, its plans and its policies, using the Console UI to define the entrypoints, endpoints and access controls. Your team tests authentication, rate limits, header handling and error responses against the Kong behavior recorded in the inventory. The output is a signed pilot sign-off that lists each mapped policy, each deliberate difference from Kong, and the owner who accepted those differences.
Expand the catalog and map remaining APIs
Work through the inventory in batches, publishing each API to the Gravitee catalog with its documentation and plans before any traffic moves. Because the Gravitee Portal UI lists the catalog for consumers, this is where documentation gaps surface. Keep a mapping table that links each Kong service and route to its Gravitee API and version. The batch is finished when every API in the batch has a passing test run and a mapping row.
Run both gateways in parallel
Place Gravitee in front of a share of traffic while Kong continues to serve the rest, typically by moving DNS or load balancer weights for one API at a time and watching latency, error rates and authentication failures on both paths. Confirm that logging and metrics from the Gravitee gateway reach your monitoring stack before raising its share. The output is a traffic split record that shows, for each API and date, the percentage served by each gateway and the observations that justified each change.
Cut over consumer by consumer
Move each consumer application to its Gravitee plan and credentials, starting with internal or friendly consumers, and track each move in a consumer migration tracker that records the consumer owner, old and new credential type, cutover date and rollback path. Keep the Kong route for a consumer available until its owner confirms success. Confirm that every consumer has stopped calling Kong by checking gateway logs over the agreed observation window. The tracker is complete when no Kong consumer receives traffic.
Decommission Konnect data planes and access
After the tracker shows no remaining traffic, remove Konnect data plane nodes, revoke Konnect API keys and team access, and remove any Konnect portal or analytics integrations. Before deletion, archive a final decK export and the inventory into controlled storage, and record which Konnect features were retired so the archive explains the old state. Ask Kong to confirm in writing how your account and data will be handled at termination. The step closes with a retired configuration archive and a signed decommission record.
How the move differs by starting point
If your Kong Gateway data plane nodes already run in your own infrastructure and only the control plane is Kong-hosted, the gateway traffic path is familiar and the work concentrates on the management layer. Your existing proxies keep serving requests while Gravitee APIM is stood up beside them, so you can move one API at a time instead of cutting over everything at once.
- Mapping effort: Export services, routes and consumers with decK, then map each service to a Gravitee API and each route to an entrypoint and path mapping. Plugin config becomes Gravitee policies, so review each one rather than assuming a one-to-one copy.
- Cutover path: Route a low-risk API through Gravitee in a staging environment, then shift production traffic gradually by DNS or load balancer weight, keeping Kong as the fallback until consumers confirm their keys work.
- Consumers and keys: Plan how credentials are reissued or imported into Gravitee subscriptions and plans, since consumer identifiers do not carry across automatically.
- Enterprise features: Confirm whether you need Enterprise-only policies, audit trails or Redis caching, which are gated behind a Gravitee Enterprise License.
Before you start, confirm with Gravitee which of your current policies are available in the Community Edition and which require an Enterprise license in your target version.
Teams running Konnect Dedicated Cloud Gateways have no gateway nodes of their own to reuse. Kong manages the data plane on AWS, Azure or GCP, so the migration means standing up your own gateway runtime in your infrastructure before any traffic moves. The scope of the project is larger than in the self-hosted case, and it is worth sizing the new runtime before committing to a date.
- Mapping effort: The configuration mapping is the same as for self-hosted data planes, but you also design the target topology, including Kubernetes via the Helm chart or Docker Compose with MongoDB, network paths and certificate handling.
- Cutover path: Run Gravitee in parallel with the Dedicated Cloud Gateway, duplicate traffic in a controlled window if your architecture allows it, then update upstream DNS or clients once health checks pass.
- Network and connectivity: Dedicated Cloud Gateways often sit close to your upstreams in a cloud region. Your new runtime needs equivalent latency and reachability to those services.
- Enterprise features: Ask whether the hybrid or fully self-hosted Enterprise deployment model fits your governance needs, since Gravitee documents SaaS, hybrid and self-hosted options for Enterprise customers.
Confirm the target cloud, cluster sizing and the exact Gravitee edition with your implementation team before scheduling the cutover window.
Organizations with many Kong plugins for authentication, rate limiting, transformation, logging and custom Lua or serverless logic carry the largest mapping risk. Each plugin has to be matched to a Gravitee policy, a Gravitee Enterprise capability or custom code, and some behavior may not translate exactly. Plan this as a plugin inventory project first and a configuration export second.
- Inventory: List every enabled plugin per service and route from the decK export, including global plugins, which often hide behavior that teams forget about.
- Mapping decisions: For each plugin, decide whether a built-in Gravitee policy covers it, whether an Enterprise policy pack item is needed, or whether a custom policy must be written and maintained.
- Testing: Build regression tests for authentication, rate limits and header transforms, because subtle differences in ordering and defaults surface only under real traffic.
- Enterprise features: Check Enterprise-only items such as data masking, GeoIP filtering, the Alert Engine and Redis caching, which may replace Kong plugins your teams use today.
Ask Gravitee and your implementer to confirm, plugin by plugin, which Kong features have a direct equivalent and which need custom work, rather than relying on name matches.
Teams that need a developer portal from the first day of the migration treat the portal as part of the scope rather than a later add-on. Gravitee includes a Portal UI with a catalog of APIs and documentation, so the portal can be a deliverable of the same project, though you should confirm the exact capabilities against the version you deploy. Konnect's developer portal is metered, so this group often wants to understand the replacement before cutting over.
- Content migration: Gather OpenAPI specs, guides and changelogs from the Konnect portal and decide which content is published in the Gravitee Portal at launch.
- Consumer onboarding: Define how developers request access, how applications are created and how credentials are issued in the new portal, so consumers have a path before traffic moves.
- Access control: Map existing portal visibility rules to Gravitee plans and subscriptions, and confirm who approves subscription requests.
- Enterprise features: Determine whether audit trails of API consumption or Dynamic Client Registration are required for your governance model, since these are Enterprise Edition features.
Check the portal capabilities for your target version with Gravitee before promising developers a launch date.
Some organizations cannot keep Konnect's Kong-hosted control plane in their architecture at all, either because of network isolation or data residency rules. For these teams the starting point is less about the existing data plane and more about where every Gravitee component will run. The migration sequence follows from that constraint, including how licenses and updates reach the environment.
- Deployment model: Decide between Docker Compose with MongoDB or the Helm chart on Kubernetes, and confirm which build artifacts you can mirror into the isolated network.
- Licensing: Confirm the Enterprise License needs for the features you require, and plan how license material is delivered to disconnected systems.
- Cutover path: Use the same parallel-run approach, but verify that all dependencies resolve inside your network before traffic moves.
- Auditing: Decide where logs and audit records are stored and who can review them, since this matters for regulated environments.
Confirm with your team which Gravitee components and updates can be delivered into the isolated environment and how often.
What drives cost and duration in a Konnect to Gravitee move
This table lists the factors that change the effort of moving from Konnect to self-hosted Gravitee, why each one matters, and how to keep it down. Use it to scope a fixed-scope quote and to see which inputs the quote depends on. No price or duration is stated because none is supplied for this move.
| Driver | Why it changes effort | How to keep it down |
|---|---|---|
| Number of services and routes | Each Kong service and route must be mapped to a Gravitee API with its own paths, upstreams and entrypoints, and each one needs testing after cutover. | Export with decK first, group similar routes, and retire unused services before mapping. |
| Plugin count and custom plugins | Kong plugins map to Gravitee policies unevenly, so each plugin needs a mapping decision. Custom Lua or other plugins must be rewritten or replaced by a Gravitee policy. | Inventory every plugin per route, drop unused ones, and confirm which need an Enterprise policy. |
| Consumers and applications with credentials | Keys, OAuth clients and JWT credentials must be moved or reissued, and each consuming team has to switch endpoints. | Agree a cutover window per consumer group and use overlapping keys where the gateway allows it. |
| Developer portal content volume | Specs, guides, applications and subscriptions held in Konnect's portal must be rebuilt in the Gravitee Portal UI. | Start from OpenAPI specs already in version control and archive stale pages instead of migrating them. |
| Enterprise licensing scope | Gravitee documents that the Enterprise Edition requires a license, and several features listed for it (such as Redis caching, data masking and the Alert Engine) are not in Community. Each Konnect feature you need must be checked against that split. | Map each Konnect feature to Community or Enterprise before scoping, and ask the vendor to confirm the license terms in writing. |
| Deployment target | A Kubernetes deployment with the Helm chart (EKS, GKE, AKS or OpenShift) needs cluster, ingress and storage work. Docker Compose with MongoDB is simpler to start but needs its own backup and high-availability design. | Choose one target per environment and reuse the same chart values or Compose files across dev, test and production. |
| Identity and logging integration | Connecting Gravitee to your identity provider, SIEM and monitoring stack takes separate configuration and testing, and Konnect's audit or analytics output has to be replaced. | List the identity, logging and metrics integrations early and confirm which are in scope for the fixed-scope agreement. |
What usually goes wrong and how to prevent it
Most failed Kong Konnect to Gravitee moves fail on details that look small during planning: plugin semantics, credentials, portal content, licensing and the timing of the cutover. Each card below names one risk and the check that prevents it, so the team can test them before any traffic moves.
Plugin behavior differs after mapping
A Kong plugin configuration exported with decK does not carry over as a working Gravitee policy just because a similar name exists. Ordering, scope (global, service or route), header handling and default values can change request handling without any error. Build a table that maps each plugin in the decK file to a Gravitee policy or a custom flow, then replay representative requests through both gateways and compare status codes, headers and response bodies.
Consumers moved without credential rotation
Moving consumers means moving the keys, secrets or tokens that clients use to call the API. If the same credentials are copied into Gravitee without a plan, a leaked or stale key stays valid in two places, and a rotation after cutover can break clients that were never told. Decide per application whether to reissue credentials, reuse them through a shared identity provider, or run both gateways in parallel for a fixed window, and record who owns each client's change.
Portal content left behind
The Konnect Dev Portal holds more than specs. It carries getting-started guides, application registrations, access requests and documentation pages that partners have bookmarked. Gravitee's Portal UI is a catalog of APIs with documentation, so the content must be rebuilt or imported deliberately. Inventory every published API and page in Konnect, map each to a Gravitee API entry with its plan and documentation, and have an API owner sign off before the old portal goes read-only.
Licensing surprises for Enterprise features
Gravitee API Management is Apache-2.0, but Gravitee's documentation states that the Enterprise Edition requires a license, and lists features such as data masking, GeoIP filtering, Dynamic Client Registration, the Alert Engine, Redis caching and the audit trails of API consumption. If a Konnect feature in use maps to one of these, the design depends on a paid edition. Before scoping, list every feature in use, mark those that need Enterprise, and get the license terms in writing from Gravitee.
Konnect retired before rollback is proven
Teams often switch traffic to Gravitee and then delete the Konnect control plane and its data planes once the first week looks clean. If a defect appears later, there is no working path back. Keep Konnect live and read-only until the Gravitee gateway has carried production traffic through the agreed window, rehearse a rollback by shifting traffic back, and set a written decision date for decommissioning that the owner signs.
Questions buyers ask before moving from Konnect to Gravitee
How much effort does moving from Kong Konnect to Gravitee take?
The effort depends mostly on how many services, routes, consumers and custom plugins you run in Konnect, and on how closely Kong's plugin behavior maps to Gravitee's policies. Start from a decK export of your gateway configuration, count the services and routes it contains, and list every plugin that is not a standard policy equivalent. Each custom or Enterprise-only plugin needs a design decision before any cutover work starts. Teams with a small, well-documented estate usually need less mapping work than teams with many shared plugins across environments. Ask any implementation partner to base the quote on that inventory, the number of environments, and the portal content you intend to publish.
How long does a Konnect to Gravitee migration take?
No fixed duration can be given here, because the timeline follows from the inventory, the number of environments and how much portal content must be rebuilt. The work usually runs in phases: inventory and export, a Gravitee environment built from the Helm chart or Docker Compose setup, mapping and testing of APIs and policies, consumer migration, and a staged cutover. Each phase depends on sign-off from API owners and security reviewers, so calendar time often exceeds engineering time. Ask for a schedule with named milestones in the written scope, and confirm which phases depend on your change-approval windows.
Can our team migrate from Konnect to Gravitee without outside help?
Yes, a team with Kubernetes or container operations experience and API gateway knowledge can run the migration in-house, provided it has time and clear ownership. The skills that matter most are gateway configuration, policy mapping, identity and TLS setup, and operating a MongoDB-backed deployment. Outside help is most useful for designing the target architecture, validating policy equivalence against production traffic, and building runbooks for cutover and rollback. A fixed-scope engagement lets you buy only the phases where your team lacks capacity. Compare the in-house estimate against a written scope before deciding.
Is Gravitee Community Edition enough to replace Konnect?
It depends on which features your current Konnect setup uses. Gravitee API Management is Apache-2.0 licensed and includes the gateway, management backend, Console UI and Portal UI, so core API publishing, access control and lifecycle work can be covered by the open-source code. Gravitee's documentation states that the Enterprise Edition requires a license, and lists features such as audit trails of API consumption and activity, data masking, GeoIP filtering, Redis caching, the Alert Engine, and Kafka, MQTT, RabbitMQ and JMS endpoints. Inventory every Konnect feature you rely on, then confirm with Gravitee which ones fall under the Enterprise Edition before you commit to a licensing model.
How do we run Konnect and Gravitee in parallel during the move?
The usual approach is to keep Konnect serving live traffic while Gravitee is built and tested against copies of the same configuration, then shift consumers in small groups. Route a low-risk API through Gravitee first, compare responses, latency and error rates against Konnect, and expand only after the results match. Keep DNS or load balancer rules that can point traffic back to Konnect within a short window. Consumers with hard-coded hostnames or certificate pinning need separate handling, so identify them during the inventory. Agree the rollback steps and who can trigger them in writing before the first shift.
What do API owners and security teams need to provide?
API owners must confirm the intended behavior of each service, the consumers that depend on it, the authentication scheme, and the rate limits and quotas that apply. Security reviewers must approve the identity model, the TLS and certificate design, the audit trail requirements, and any data masking rules that replace Konnect policies. Both groups should sign off on the mapping of each Konnect plugin to a Gravitee policy, because a policy that looks equivalent can enforce a different limit or log different fields. Ask any partner to list these review points in the scope so they are scheduled before cutover, not during it.
How DeployOpen scopes and runs a Konnect to Gravitee migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Konnect to Gravitee move, that means the engagement covers the Gravitee gateway, the management API backend, the Console UI for administrators, the Portal UI for consumers, the database behind them, and the Kubernetes or Docker Compose deployment you choose. DeployOpen does not run your traffic on its own infrastructure, and the platform stays under your administrative control after handover.
Most engagements are fixed-scope. Before work starts, the written scope names the Konnect organizations, control planes and services in play, the decK exports to be taken, the mapping of Kong services, routes and plugins to Gravitee APIs, plans and policies, the consumer migration approach, and the acceptance criteria for each deliverable. The written scope also sets the timeline and the points where your team signs off. Ask for these items to be listed explicitly, and check which Gravitee features each plugin depends on, since some capabilities are in the Enterprise Edition and require a license that you or Gravitee must provide.
DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that drive it are the number of APIs and plugins, the number of consumers and applications, the deployment target, the integration points with identity and logging, and whether you need ongoing support. Ongoing support, upgrades and continuous testing are available as retainers after the initial migration, which suits teams that want Gravitee patched and upgraded on a regular schedule. DeployOpen does not hold vendor partner status with Gravitee or Kong, so confirm licensing terms directly with the vendors.
